您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
   
 
     
   
 订阅
  捐助
UML在数据算法工程中的企业级应用实践
 
作者:穆晨
301 次浏览     评价:  
 2019-10-9
 
编辑推荐:
本文深入研究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的“初心”从未变过,那就是为专业技术虚拟客观事实提供更形象的表述形式。

   
301 次浏览     评价: 订阅 捐助
 
相关文章

UML概览
UML图解:用例图(Use case diagram )
UML图解:活动图(activity diagram )
UML图解:类图(class diagram )
 
相关文档

UML统一建模语言参考手册
网上商城UML图
UML建模示例:JPetStor
UML序列图编写规范
 
相关课程

UML与面向对象分析设计
UML + 嵌入式系统分析设计
业务建模与业务分析
基于UML和EA进行系统分析设计