UML在数据算法工程中的企业级应用实践

前

前 言

这期穆晨要安利的UML是门“技术的技术”，它既能帮研发梳理技术架构，又能辅助产品了解系统运作。因此不论您是数据算法同学还是项目里其他角色，都不妨学习了解下：）

本篇实践性较强，建议读者预先准备好建模工具Visual Paradigm以获得最佳学习效果。

注1：UML，即Unified Modeling Language；

注2：Paradigm兼容Winodws/Linux/MAC。

0. what is U-M-L？

—— “唐僧版”简介

先请读者思考个略突兀的问题：什么是“计算机科学技术”？它到底是做什么的？您能给出一句话，甚至一个词的概括吗？

穆晨以为，一句话概括就是“对客观事实进行多层虚拟，然后基于虚拟结果分析当前与未来状态，再依据这些状态推动资源的平衡”；而一个词概括，那便是“平衡”。

仔细想想，技术本质而论，编程语言、数据建模、算法训练，不都是在“虚拟”客观实体与事务么？产品本质而言，淘宝某东推动供销平衡，滴滴曹操推动车辆平衡，美团饿了么推动美食平衡，也可都统统视为推动“资源平衡”。

在我们开展“虚拟”以实现“平衡”的过程中，针对如何组织类抽象业务，如何布局表模拟事实等问题，专家们设计出一种图形化语言——UML，它能形象规范地组织呈现出我们的“虚拟逻辑”。

注：UML支持大约12种图形，本文仅讨论数据算法工程师及PD/PM用得最多的6种。

1. 用例图

—— 专业说明书

用例图用于表述软件系统具备哪些功能。它包含两种实体（参与者/用例）与四种关系（关联/包含/扩展/泛化），是一种入门级的UML图。

其中，参与者表示交互对象，如用户、管理员；用例则表示系统模块，如数据汇总、算法训练等模块。同时，Paradigm还额外提供System组件，一定程度提高了扩展性。

对四种关系的理解，是掌握用例图的关键。“关联”用于连接参与者与用例；“包含”用于拆分子用例；“扩展”用于增加功能点；“泛化”表示继承，子用例可调用父级用例属性。

下图展现了一款“智能分析平台”的功能体系，穆晨在绘制时尽量涵盖了此类图的全部要素。

注：用例图在PD与客户沟通时常常用得到，如需更美观/酷炫，将之交给美工同事优化即可。

2. 时序图

—— 行为时间约束

时序图是一种强调消息时序的交互图。它的组件主要分为生命对象（边界/控制等）、消息（同步/异步等）、组合框（循环/条件等）三大类。

首先来看生命对象组件。顾名思义，生命对象就是带有生命线的对象。在时序图中，根据分工职责的不同，生命对象可分为一般、边界、实体、控制等四种。一般生命对象不具备特殊属性，而后三者则可完全对应到JAVA的M-V-C来理解。

再看消息组件。该组件能呈现多种不同类型的消息，如同步消息、异步消息、自关联消息、不可中断消息等等。需重点区分的是同步与异步消息，前者在发送消息后会坐等反馈，后者则将继续做自己的事。

最后是组合框组件。这种组件存在的意义是约束部分消息的发送规则。比如是循环发送，还是条件发送、并行发送等。

如下的时序图，展示了一个小型数据企业中不同团队的沟通协作关系。通常公司越大，分工也会越细，但图中的几种基本实体和关系大都会有。

3. 活动图

—— 活动行为空间

活动图是一种比时序图更广义的UML图形，它不考虑对象生命周期，不突出消息时序，而更侧重表述对象的自身特性以及对象与对象间的关系。

基于上述定义，活动图组件类型较多，对应的功能也很丰富，有行为、活动、泳道/组合框、启示/终止结点等等。但大都较好理解，大家多试几次就清楚了。

首先来看看两类常被混淆的结点组件：交叉/汇合结点与分支/合并结点。前两节点可视作并发闸门，多条控制流会同时输入/输出；后两结点则用做判断与控制流汇总，不同控制流将各自通过。

第二类容易让新手费解的组件是区域组件，通常指“中断区域”和“扩展区域”。前者框定可中断活动集，并抛出异常；后者则表示以有序数组为输入/输出的活动集，并可根据活动集运转方式标记为并行/迭代/流式。

最后是两种比较特殊的活动：事件等待与事件接收。这两类组件都不需要控制流，可独立触发启动新活动。

下面是穆晨绘制的一个数据项目实施活动图。可以看出在企业级数据项目中，由于现实业务与数据的复杂性，需引入不少环节来保证项目质量。

4. 状态机

—— 对象状态空间

状态机由某个对象的所有状态和连接这些状态的转换组成，适用于描述大型系统或复杂算法里定义复杂、经常“变态”的对象，在很多项目架构文档或学术论文里都看得到。

经典状态机中，最核心的两类组件是“状态”和“转移”。前者是对象生命周期的一个形态，可在其中标示进入/激活/离开状态时的行为；后者则是状态间的路径，可配置触发/监护/影响三类元素，为状态切换设置约束条件。

此外，若要更深理解并绘制更专业的状态机，还需掌握好三类特殊组件：“伪状态”、“深/浅历史状态”，以及“复合状态”。对于梳理一些复杂对象来说，区分清这几个概念非常有必要。

“伪状态”是瞬时状态，用于描述转换过程的细节，开始/结束/选择/合并等都可以归为这类状态。要特别留意的是入口/出口伪状态，这两状态通常作为复合状态的边界。此外“连接伪状态”也特别常用，它把多个转移汇集到一起。“深/浅历史状态”也是伪状态节点的一种，它表示状态机被中断重启后，是否恢复上次/历史的信息。

“复合状态”指包含嵌套状态机的状态，如果复合状态里存在多个并发子状态机，则又称为“正交复合状态”。这种状态下，要离开超状态只能是所有子状态机同时完成汇聚，或者某子状态机通过出口伪状态切换出去。

下图为笔者设计的一个“智能数据引擎”状态图，其中数据集承担对象角色。我们通过数据预处理，特征算法工程等环节，让它从无序到智能不断衍变，最终服务与产品与用户。

5. 类图

—— OOP具现化

对大部分程序员来讲，这类图应该早已轻车熟路了，它直观呈现了用类/对象去虚拟业务的逻辑。一定程度来说，它引入的UML概念比大多数高级语言本身更能反映面向对象（OOP）的本质。

类图将类间关系归纳为几大经典类型：泛化、实现、关联、聚合、组合、依赖。有这六种关系，再结合高级语言中的类和对象，便能形象地虚拟出各类实际场景并提供业务支撑。

其中，“关联”表示类间普通关系，表示可相互感知；“泛化”可理解为全继承，子类亦可新增函数/改造父类函数；“实现”是接口与类的关系；“聚合”是一种特殊关联，表示整体与部分；“依赖”表示一个类的实现需另一个类协助。当多种关系同时存在时，便以更强关系为准。

笔者编程水平不高，就不献丑了。从UML官网扒了张图供大家参考。

6. 数据建模图

—— 建模大统一

最后压轴出场的，是笔者最爱——数据建模图。严格来说它并不属于UML图，可既然Visual Paradigm提供了这么好用的组件，为何不试试呢，^_^？

Paradigm提供支持的是E-R建模。比起UI类设计工具，它颜值可能差一丢，但专业性要强太多了：全面支持数据表、主外键/非空/唯一性约束、陈氏E-R关联法等数据因素的呈现。此外，随着E-R与维度建模趋同化，双方数据人员完全可通用该工具。

不过，数仓在应用层与数据库建模的区别还是蛮大的。前者面向分析口径，后者面向业务口径。分析口径中，大部分表需根据不同分析需求建模，各数据模型相对精简；业务口径中则只需一套建模，但总体结构复杂。

这里穆晨随手画了个工业系统的分析小模型，用于分析不同员工擅长诊断的问题类型。为此，它需汇聚数仓中间层的维度事实表，并关联线上业务系统补充明细信息。

说明：对开发速度要求高，迭代也快的数据系统，不单要采用Kimball数仓架构，且DW层必须做抽象化设计。当分析需求粒度很细时，再从线上系统取数。如此方能更大程度提升DW层表复用度，实现数据的敏捷开发。

结 语

除本文介绍的几种，UML还支持部署图、组件图、通信图等等。类型很多，但UML的“初心”从未变过，那就是为专业技术虚拟客观事实提供更形象的表述形式。

题外：时至年末，穆晨计划读几本书，因此技术类文章将暂停更新一段时间。

笔 者 介 绍

笔名穆晨，任职于某互联网金融公司，从事数据科学领域相关的应用研究。工作之余，酷爱阅览各类书籍，聊以自乐。