第4章业务建模之业务序列图（一）-UML基础-火龙果软件工程

捐助

第4章业务建模之业务序列图（一）

火龙果软件发布于 2014-09-12

次浏览

上一章我们得到了待改进组织的业务用例图，本章我们将讨论业务建模中最繁重的工作——描述业务用例的实现，即业务流程，然后改进它，推导出待开发系统的用例。

4.1 描述业务流程的手段

描述业务用例的实现，即业务流程，有几种可选的做法：

【选择一】文本

例如针对财务部“员工→报销”用例的实现，书写业务用例规约如下：

1. 员工把报销单交给财务主管

2. 财务主管确认报销单已经过员工领导审批

3. 财务主管审批报销单

4. 财务主管将审批好的报销单返还给员工

5. 员工把报销单交给会计

6. 会计复核报销单

7. 会计记录报销单

8. 会计把报销单交给出纳

9. 出纳付款

扩展：

2a. 报销单未经员工领导审批：

……

文本的缺点是不够生动，而业务建模注重生动，所以不推荐在描述业务流程时使用文本的方式，而是使用图形。不过，描述系统用例（需求）的时候，推荐使用文本，因为此时更注重精确。

用图形描述业务流程，有两种UML元素可以选择：活动图和序列图。

【选择二】活动图

活动图，更准确地说是活动图的“山寨版”——流程图，应该是在开发人员中使用频率最高的图形了。

流程图最开始用于在编码之前表达代码逻辑，也就是所谓“详细设计”。在软件规模较小、编程语言表达能力较弱的年代，这样做是情有可原的。随着软件越来越复杂，编程语言表达能力也越来越强，针对某一小段代码画流程图变得没有必要，而且如果类某个操作的代码复杂到要画一张流程图来说明，恐怕这个操作已经有问题了。

遗憾的是，现在流程图依然成为开发团队仅有的几种“设计”手段之一（这里的“设计”加了引号，您还记得是为什么吧？不记得的话，请复习前面的内容）。也许和高校的软件开发类教材以及教师的知识严重落后于时代步伐有点关系？这个问题本书不深入探讨。

如果流程图用来表示组织内部各系统（岗位）之间的协作，即业务流程，那就变成了业务流程图，接近于活动图。活动图可以看作是流程图的扩展，添加了分区（Partition，即UML1.x中的泳道）、分叉（Fork）、结合（Join）等元素，UML2.x进一步增加了Petri网的元素，表达能力更加丰富。

上面的报销业务流程用活动图可以表示如下：

图4-1 用活动图描述业务流程

【选择三】序列图

序列图用面向对象的思想描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。这个做法应该起源于1995年Ivar Jacobson的“The Object Advantage”一书，， 1997年Ivar Jacobson又出的UML版的“Software Reuse”，其中也有描述。

上面的报销业务流程用序列图可以表示如下：

图4-2 用序列图描述业务流程

我刚开始为开发团队提供服务的前几年，讲授描述业务流程的技能时选择的是活动图，2005年10月以后，改成了序列图，所以本书主要采用序列图来描述业务流程。做出这个选择基于以下几点理由：

（1）活动图只关注人，序列图把人当作系统。

软件开发的目的就是要改进当前的现实，可能是引进一个新系统，也可能是升级现有的系统。信息化发展到今天，待改进的当前现实中不只有人肉系统（即业务工人），还有大量的非人系统（即业务实体），这些非人系统封装了许多最开始位于人肉系统中的逻辑。将来和新系统交互的系统（也就是新系统的执行者），有可能只有一部分是人，另外一部分是非人系统。互联网的发展，更是使得许多商业或政府组织用来和大众打交道的接口系统不再是人肉系统，而是电脑系统。

图4-3 组织用来和大众打交道的“第一刀”越来越多由非人系统承担

使用活动图描述业务流程时，开发人员往往只注意人或部门的活动，忽略了非人系统的责任。待改进的现实中，会计记录报销单和出纳记录付款信息都需要用到现有的电脑系统SCS，活动图图4-1未能表达出来，序列图图4-2表达出来了。虽然活动图可以稍作变通，将非人系统也单列为分区，但我见过的绝大多数活动图，分区的抬头只是描述人或部门。

（2）活动图表示动作，序列图强迫思考动作背后的目的。

对比图4-4和图4-5：

图4-4 活动图表示动作

图4-5 序列图强迫思考背后的目的

图4-5不但表达了非人系统的责任，同时也清晰地揭示出来营业员这个岗位对外暴露的责任是：受理申请，这也是市民对于营业员的期望。期望和承诺，是用例和对象技术的关键思想。使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。

（3）活动图更“灵活”，序列图更不“灵活”。

不少人认为活动图胜过序列图的地方是它灵活，我开始也是这么认为，但现在我的观点是：这种灵活是一把双刃剑。活动图很灵活，它的控制流箭头可以指向任何地方，就像编码原始时代的Goto语句，所以活动图很容易画。不过，“很容易画”的活动图，也比较容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。

图4-6 活动图的灵活是把双刃剑

序列图通过alt、loop等结构化控制片断来描述业务流程，强迫开发人员用这种方式去思考。对于现状确实乱七八糟的流程，描述起来相对要困难，需要按照场景分开画很多张序列图来表达，但这也揭示了业务流程的糟糕现状。

另外我认为，软件开发中的业务建模更应该像讲故事，通过故事来思考待开发系统的位置，证明待开发系统确实能为组织带来好处。挑选需要改进的具体场景一个一个画序列图，比在一张图上把各种可能性和分支都罗列出来还是要好一些。

必须要承认，用活动图或类似活动图的手段（如BPMN）来建模业务流程是主流，而且已有的参考资料和模型积累也非序列图可比。本书选择了序列图来做业务建模，最主要原因还是“把人和电脑系统一样看待”。如果您使用其他方法来做业务建模已经做得很好，而且能解决这个问题，就没有必要切换到序列图。

这里展开说一个问题：多，不代表有价值。经常有开发人员问我，“潘老师，UML用得好的团队多不多？”我只能回答“不多”。于是提问者就释然了，哦，用得好的不多，看起来这个东西用处不大，我不学也没关系的。

围棋下得好的、足球踢得好的、脑外科手术做得好的、长得漂亮的女性…都不多，但是一旦突破门槛进入这个圈子，就会有很大的竞争优势。就拿编码来说，可能读者觉得会编码的人挺多的，周围的人大多都会，其实会编码的人占全国人口比例也很少很少，编码编得好的就更少了，但不能推导出“编码没用”的结论。相反，正是因为编码有门槛，所以大多数程序员尽管买不起房，衣食无忧是做得到的。

活动图或山寨活动图也不是最流行的，前文说过了，更流行的是随意而画的“草图”。“草图”也不是最流行的，最流行的应该是什么都懒得画，把脓包一遮了之。

UML提供了交互概述图（Interaction Overview diagram），采用活动图的形式将各个场景的序列图串起来，相当于结合了活动图和序列图的特点。本书的模型也展示了交互概述图的用法。

在介绍绘制业务序列图的要点之前，我们先来看一些有趣的序列图，体验一下这种建模技术所带来的“严肃的创造力”。

图4-7 改进前的餐馆

图4-8 改进后的餐馆

图4-9 改进前的下载

图4-10 改进后的下载

图4-11 改进前的QQ泡妞

图4-12 改进后的QQ泡妞

4.2 业务序列图要点

4.2.1 消息代表责任分配而不是数据流动

图4-13 消息的含义是责任流不是数据流

这是最常犯也是最根本的序列图错误了。A指向B的消息，代表“A请求B做某事”，或者“A调用B做某事的服务”，做某事是B的一个责任。图4-13中，指向营业员的消息映射了营业员类的一个责任。（UML的定义中，消息有许多花样，在讲到分析设计的时候再介绍，这里说的是最常见的代表调用的消息）

在序列图中，焦点是对象之间的责任和协作，数据流是作为消息的输入输出参数存在的。建模人员在画序列图时，不仅要看到数据的流动，还要找出背后的责任。数据流很多时候是双向的，但责任封装在A这里，就不需要封装在B那里。

图4-14 消息的命名

图4-14中，业务人员指向科长和仓库管理员的消息代表了他们对业务人员提供的服务。如果业务人员传递借用单给仓库管理员没有特定的目的，可以用“处理借用单”来命名。另外，消息名称中不用带“请求”二字，消息箭头就已经有请求的意思。

在建模工具中，需要人工映射消息成为类的操作，然后就可以在各张序列图中反复使用了。图4-15是EA的界面，点击“Operations”按钮映射操作：

图4-15 EA中把消息映射为操作

4.2.2 聚焦于系统之间的协作

图4-16 系统内部的组件露出来了

业务建模研究的焦点是组织，所以业务序列图上对象的最小单位是人肉或非人系统。图4-16是错误的，CRM系统内部的一个组件“客户表”露了出来。既然“客户表”可以露出来，销售支持的大脑、心脏、手指要不要露出来呢？毕竟是大脑指挥，心脏提供能量，用手指录入的。又如下图：

图4-17 表达了过细的交互步骤

销售支持在使用CRM系统记录客户资料的时候，有可能有多次交互，但在业务序列图中没有必要画出来，只需要在销售支持和CRM系统之间画一个“记录客户资料”就够了。

这里引出建模的一个基本原则：抽象级别一致。开发人员在建模和讨论问题时，经常是想到哪画到哪，打哪指哪，抽象级别和研究对象一会跳到这里，一会跳到那里。你跟他讲业务流程，他跟你说系统；你跟他说系统，他跟你谈类；你跟他谈类，他跟你讲业务流程……

图4-18是一张分析类图，这张图是合理的。

图4-18 购物系统的分析类图

建模人员突然来了兴趣，给订单周围加了一些东西，如图4-19。

图4-19 各种抽象级别混合起来了

订单有订单管理来辅助，商品、会员难道就没有吗？订单有状态，商品、会员难道就没有吗？把订单改成阿猫，待结账改成阿狗，实现状态机和对象管理的套路会变化吗？图4-19涉及到了几方面的知识：（1）购物领域各个类之间的关系；（2）订单有哪些状态；（3）实现时如何管理实体对象；（4）如何实现状态机。

人脑的容量是有限的，过早把各种领域的知识混杂，人脑需要处理的逻辑就会从M+N+O+P增加到M*N*O*P。正确的做法是将不同的知识分开表达，（2）放在订单类的状态机图中，（3）和（4）不需要画图，只需要用典型的代码案例表达所选择的实现套路，而实现套路经过选定以后就是有规律的，程序员经过分析模型加典型用例代码案例的训练，就可以举一反三，按图施工。

4.2.3 只画核心域相关的系统

图4-20 老太婆上街买个菜也不简单

现在的世界到处充满了（非人）智能系统，如图4-20，一个老太婆上街买个菜，都有可能和许多智能系统打交道，这就带来一个问题，是不是所有的智能系统都要成为我们业务流程中的业务实体？

图4-21 Word要不要画出来？

如图4-21，工作人员制作文档，还是工作人员用Word制作文档？一个智能系统要不要成为序列图上出现的业务实体，判断的标准是：它是否核心域内的系统。如果要改进的是采购的流程，不需要出现Word；如果要改进的就是制作文档的流程，可以出现Word。

核心域/非核心域的概念，在后面的工作流中还会不断提到，此处先不详细讨论。有时很难判断也没关系，您想过这个问题，就已经比没想过要好了！可以先画出来，然后如果发现它跟改进的流程无关（就像工作人员用Word、用WPS、用纸笔来制作文档，不影响采购流程的改进结果），再把它删掉。

4.2.4 把时间看作特殊的业务实体

业务序列图中，我们可以把时间看作特殊的业务实体。时间就像上帝造好的，挂在天上的一个大钟，向全世界各种系统发送时间消息。这样，就和后面需求工作流中映射系统用例的时间执行者一致了，同时也帮助理清什么情况下使用时间执行者的问题。

图 4-22 把时间当作一个系统

注意：时间和定时器不是一个概念。时间是外系统，定时器是其他系统用来和时间打交道的边界类。世界上只有一个时间系统，但有无数的定时器。

4.3 【业务建模步骤1-3】：现状业务序列图

了解绘制业务序列图的一些要点后，我们开始来绘制改进前的、也就是现状的业务序列图。

现状就是：假如今天要引进您的系统的组织的业务流程发生，拿着摄像机去拍摄，会拍到什么？把拍到的场景如实绘制成业务序列图。在场景中，出场的也许全部都是人肉系统；也许除了人肉还有许多非人系统，唯独没有您要开发的系统；也许已经有了您的系统的1.0版本，正在等待2.0版本的改进……总之，现状就是现状。

说起来这么简单的事情，其实做到也很不容易。下面列出一些常见的错误：

4.3.1 错误：把“现状”误解为“纯手工”

许多建模人员画的业务流程中，只有人，没有非人系统。前文已经阐述过，人只是系统的一种，现在这个时代的业务流程中，非人系统承担的责任越来越大，以后我们要开发的新系统，很可能只有一些接口是和人肉系统打交道，另外一些接口是和非人系统打交道。

业务流程中全是人，那是二十多年前的“现状”，那是先锋、安易、用友等应用软件先驱刚刚起步的年代。基于二十多年前的现状来改进，得到的系统岂不是要和二十年前的软件一样？这样的软件怎么能卖得出去？新系统的需求通过研究业务现状，再结合愿景推导得到。如果描述的业务现状是虚假的现状，在上面得到需求就如同在流沙之上构建大厦，让人担心了。

举一个生活中的例子，三十年前人们走亲访友，带一包米、一只鸡、一筒饼干上门是非常得体而且受欢迎的，现在大家都过上了小康生活，您再带这些礼物去，在对方看来未必是什么好东西。您开发的系统就像送给客户的礼物。

这种错误，在使用活动图描述业务流程时比较普遍，序列图把人当作系统，有助于克服这一点。有一种误解是：认为人做的事情就是本质，电脑做的不是。其实应该把人看作系统。

4.3.2 错误：把“现状”误解为“规范”

建模人员在建模业务流程时，照搬组织制定的规范，没有去观察实际工作中人们是如何做的，或者即使观察到了人们实际没有按照规范做，却依然按照规范建模。这样做，得到的业务流程是不真实的。上有政策，下有对策，人们在工作时往往会想出一些巧妙的方法，来规避不合理或对自己有损的规范，这些方法中的合理部分就值得计算机系统学习。如果视而不见，也就丧失了许多有价值的改进机会。

4.3.3 错误：以待开发系统为中心拼凑流程

图4-23 以待开发系统为中心拼凑流程

如图4-23，建模人员没有去调研并按照业务流程的进展来画图，而是想象了自己认为系统应该有的一些功能，把这些功能拼凑起来就变成“业务流程”了。

业务建模时，心中的摄像机应该一路跟随实现业务用例的流程去拍摄，把拍到的故事如实画出来，各个系统只是流程中的一个零件。建模人员常犯的错误就是把自己要开发的系统看得比天还大，把摄像机固定在自己要开发的系统的旁边。

业务建模就是要从业务流程中找到待开发系统的位置，证明您的系统如果有这些功能，对实现业务用例是有帮助的。这样，这个系统就能卖得出去。如果已经认定了系统有这些功能，直接画系统用例图不就完了吗，还装模作样做业务建模干什么呢？

1. 以下说法不正确的是

A) 抽象级别一致是建模的重要原则

B) 因为软件总是要修改的，所以要善于分离软件涉及的各种知识，降低修改的成本

C) 因为软件总是要修改的，所以不用设计，赶紧编码是硬道理

D) 序列图上的箭头代表责任分配

2. 描述业务用例的实现——业务流程适合用的UML图有（本题可多选）

A) 活动图

B) 用例图

C) 序列图

D) 状态机图

E) 流程图

F) 依赖图

3. 关于在业务建模中使用活动图和序列图，以下说法正确的是（本题可多选）

A) 当前开发人员做业务建模时，序列图使用最多，所以《软件方法》书中以序列图为主。

B) 序列图表示动作，活动图强迫思考动作背后的目的

C) 活动图背后是面向过程的思想，序列图背后是面向对象的思想

D) 活动图的“灵活”是优点也是缺点

4. 以下序列图存在错误的地方有

5. 以下书店系统的类图中有不少错误，最要不得的错误是：

A) Catalog和cBinaryTree之间的关系

B) Catalog和Book之间的关系

C) Book和Item之间的关系

D) Item和Order之间的关系

4.4 案例

前面说过，现状就是现状，就是马上拿起摄像机跟随业务流程拍摄得到的现状。但是为了展示更多的“改进点”，我们把时间拨回到2005年的“蛮荒时代”。

在2002－2004年间，UMLChina的业务主要以上门为客户提供内训为主。虽然也有自己举办的公开课，但收费比较贵，人数不是很多。2005年4月，UMLChina开始举办不以盈利为目的的“非盈利公开课”，每人2天仅收400元（现在这个公开课依然举办，不过费用变为800元）。学员蜂拥而至，最多的一期达到100多人。人数的增加带来了工作量的增加，挤压了其他工作的时间，迫切需要在业务中引进专门的信息系统来减少工作量。所以，我们先要对“参加公开课”中认为值得改进的流程建模，想办法从中间寻找能用计算机系统来改进的改进点。

“参加公开课”用例的部分业务序列图如下：