[软件方法]业务序列图的工具操作

会员服务 ·

[软件方法]业务序列图的工具操作

2017 年 7 月 26 日 UMLChina 潘加宇

第4章业务建模之业务序列图

我像是一颗棋子，来去全不由自己

《棋子》；词：潘丽玉，曲：杨明煌，唱：王靖雯；1994

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

4.1 描述业务流程的手段

描述业务流程的可选手段有文本、活动图和序列图，下面先比较一下它们的优劣。

4.4.1 文本

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

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

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

3. 财务主管审批报销单

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

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

6. 会计复核报销单

7. 会计记录报销单

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

9. 出纳付款

扩展：

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

……

文本的缺点是不够生动，所以在描述业务流程时很少使用文本的方式。不过，描述系统用例（即系统需求）的流程时，文本是常用的，因为此时更注重精确，而且还要表达业务规则、性能等目前尚未被UML标准覆盖的内容。

4.1.2 活动图

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

活动图的前身流程图，应该是在开发人员中使用频率最高的图形了。流程图最早出现于1921年[Gilbreth 1921]，用于机械工程领域。在Goldstine和von Neumann将其引入计算机领域之后，流程图变得流行起来，主要用于在编写文本源代码之前表达跳转逻辑。不过，随着编程语言表达能力也越来越强，针对简单的分支、循环逻辑画一张图很多情况下已经变得没有必要。

活动图在流程图的基础上添加了分区（Partition，即UML1.x中的泳道）、分叉（Fork）、结合（Join）等元素，UML2.x进一步增加了Petri网的元素，表达能力更加丰富。

如果活动图用来表示组织内部的业务流程，那就是业务流程图。上面的报销业务流程用活动图可以表示如下：

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

4.1.3 序列图

UML2.x序列图的符号标识来自ITU（国际电信联盟）制定的消息序列图（MSC）标准[ITU-T Z.120]。Ivar Jacobson在“The Object Advantage”一书[Jacobson 1995]中将序列图用于描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。1997年Ivar Jacobson又出了UML版的“Software Reuse”[Jacobson 1997]，其中也有描述。

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

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

4.1.4 序列图和活动图比较

本书所授方法采用序列图来描述业务流程。做出这个选择基于以下几点理由：

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

使用活动图描述业务流程时，建模人员往往只注意人或部门的活动，忽略了非人智能系统的责任。上一章已经提到，现在的业务流程中已经有很多领域逻辑是封装在业务实体而不是业务工人中。如果忽略非人智能系统，很多重要信息就丢掉了。

例如，图4-1的活动图未能表达出会计记录报销单和出纳记录付款信息都需要用到现有的电脑系统SCS这个事实，而图4-2的序列图表达出来了。虽然活动图可以稍作变通，将非人系统也单列为分区，但我见过的绝大多数活动图，分区的抬头只是描述人或部门。

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

对比图4-3和图4-4：

图4-3 活动图表示动作

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

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

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

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

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

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

图4-6 带有结构块的序列图

本书选择用序列图来做业务建模，最主要原因还是理由（1）——把人脑系统和电脑系统平等看待。如果您使用活动图或其他方法做业务建模已经做得很好，而且能解决这个问题，就不一定要切换到序列图。毕竟在目前已有的业务流程建模资料中，活动图或类似活动图的手段（如BPMN）占绝大多数，积累了比序列图多得多的参考资料和模型。

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

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

会用活动图（或者再退一步，会用流程图）来建模业务流程的人已经算是少的了，更多的是随意而画的“草图”，更多的应该是什么都不会画或者懒得画，把脓包一遮了之。

UML提供了交互概述图（Interaction Overview diagram），采用活动图的形式将各个场景的序列图串起来，相当于结合了活动图和序列图的特点，如图4-7。不过，用序列图也可以把其他序列图串起来，所以交互概述图不是必要的。

4-7 交互概述图

4.2 业务序列图要点

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

我给图4-2的业务序列图加了一些注解，如图4-8所示。

图4-8 业务序列图主要元素

序列图最重要的要点是消息的含义。A指向B的消息，代表“A请求B做某事”，或者“A调用B做某事的服务”，做某事是B的一个责任。例如，图4-8中，指向财务主管的消息“审批报销单”映射了财务主管的“审批报销单”责任。注意，消息名称中不用带“请求”二字，消息箭头已经有请求的意思。

在序列图中，数据流仅仅作为消息的输入输出参数存在。如果不了解这一点，就容易把消息的方向当成数据流动的方向，不但消息名称没写对，还会出现成对的消息，如图4-9所示。

图4-9 错把消息当成数据流

4.2.2 抽象级别是系统之间的协作

业务建模的研究对象是组织，出现在业务序列图生命线上的对象，其最小颗粒是系统，包括人和非人系统。如果建模人员不把这一点时刻记在心中，打哪指哪，抽象级别随着兴之所至跳跃，就会使业务序列图中混入不该有的内容。

图4-10的业务序列图中，CRM系统的一个组件“客户表”露了出来，因为建模人员突然想到客户资料应该保存在数据库的“客户”表中。其实这个抽象级别不关心CRM系统中是不是使用关系数据库保存数据以及数据库中是不是有一个表叫“客户”。如果真的要考虑系统内部组件这个抽象级别，“分配销售专员”操作也会影响一些表，怎么不画出来？销售支持使用CRM系统记录资料时，大脑指挥，心脏提供能量，手指录入，大脑、心脏、手指怎么没画出来？因为当时的“灵感”没顾及，所以选择性忽略了。

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

另外一种抽象级别跳跃错误如图4-11。要表达销售支持使用CRM系统记录客户资料，只需要在销售支持和CRM系统之间画一条消息“记录客户资料”就够了，这是这两个系统之间协作的目的。不过建模人员刚好想到记录客户资料的过程会有多次交互，于是把这些交互步骤画了出来。

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

其实，图的左侧运营部和销售支持打交道时也可能有多次交互，如果按照图4-11右侧销售支持和CRM系统之间的交互的画法画出来，则如图4-12所示，为什么选择性忽略这部分交互呢？

图4-12 运营部和销售支持的协作也有多次交互

上面说的两种错误是把需求和分析的工作流的工作带入了业务建模。图4-10中提到的系统内部的组件，应该在分析和设计工作流中描述；图4-11中提到的交互步骤，应该在需求工作流中描述。

过早把不同抽象级别的知识混杂，大脑需要处理的逻辑就会从M+N+O+P增加到M*N*O*P。正确的做法是分开表达，这一点本书第8章还会进一步阐述。

还有一种抽象级别错误是：业务序列图的内容和业务用例图差不多。如图4-13，上部是担保公司的业务用例图，而下部的业务序列图直接把担保公司作为一个业务工人画出来了，根本没有剖析出担保公司内部各种人和非人智能系统之间的协作。出现这样的画法，原因很可能是建模人员根本不了解组织内部有哪些岗位，各自承担什么责任，只好把整个组织囫囵当成一个系统画出来。

图4-13 目标组织作为整体出现在业务序列图中

最后要提到的抽象级别错误是：把不具备任何智能的物体放到了业务序列图的生命线上。如图4-14所示。

图4-14 无智能的申请单被错误当成了业务实体

申请单只是一张纸，不具备智能，最多能作为消息参数传递，如图4-15所示。

图4-15 申请单只能作为消息参数

可能有的读者纳闷，我怎么记得看过的书里经常有序列图上出现订单、申请单对象？那是分析序列图。我们用对象的思想去构思我们所开发的系统的内部结构和行为，就得到了订单、申请单等假想的有生命的对象。如图4-16所示。

图4-16 分析序列图生命线上可以有申请单对象

4.2.3 只画核心域相关的系统

业务流程中涉及到的非人智能系统，远远比我们意识到的多，业务序列图上只能表现出其中一部分。例如，图4-11中，运营部请求销售支持处理客户资料时，有可能是通过微信联系的，那么，微信需不需要作为一个业务实体出现在业务序列图中？

大致的判断标准是：如果是核心域相关的系统，应该出现在业务序列图中，如果不是，可以不出现。如图4-17，工作人员制作文档，还是工作人员用Word制作文档？如果描述的是采购的流程，可能左侧就可以，如果描述的是制作文档相关的流程，可能应该画成右侧。具体问题还需要具体分析，所以以上用词是“大致”、“可能”。

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

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

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

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

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

注意：时间和定时器不是一个概念。时间是外系统，定时器是其他系统用来和时间打交道的边界类，如图4-19所示。世界上只有一个时间系统，但有无数的定时器。有的建模人员在识别系统用例时说“执行者是定时器”，这样说是错的，执行者是时间。

图4-19 时间和定时器的区别

4.2.5 为业务对象分配合适的责任

分配给业务对象的责任必须是该对象有能力承担的。在这一点上，我们平时的说话是含糊的，很容易造成误导。例如，“工作人员用Word写标书”这样的说法好像可以接受，但是如果按照说话的文字不假思索画出图4-20，就看出责任分配好像不对。

图4-20 不恰当的责任分配

Word无法承担写标书的责任，这个软件系统里应该没有任何一句代码提到“标书”的概念，只有“文档”、“段落”、“字体”等概念。当前编辑的文档到底是标书还是黄色小说，工作人员的大脑才知道，应该改为图4-21所示。

图4-21 恰当的责任分配

再对比一下图4-22和4-23中分别用算盘和计算器计算时的责任分工。严格来说，算盘不是智能系统，但为了比较，暂且把它放到生命线上。

图4-22 人用算盘计算

图4-23 人用计算器计算

4.3 【步骤】现状业务序列图

假如现在目标组织的业务流程发生，您亲临现场，把观察到的场景如实绘制成业务序列图，就得到了现状业务序列图。

这里最重要的要点就是“如实”。尽力描绘出真实的现状，接下来在此基础上改进，才有可能得到最符合现状需要的改进方案。在凭空想象的现状上改进，得到的必定是假的改进方案、假的系统需求。

黑格尔有一句经常被误解为“存在即合理”的名言——“凡是合乎理性的东西都是现实的；凡是现实的东西都是合乎理性的。”[黑 1820]现状之所以存在，必定有其存在的原因，毕竟大家都不傻！一定要在尊重现实背后的理性的前提下再去改变，贸然改变很可能得不到好结果。

鲁迅曾经长叹“即使搬动一张桌子，改装一个火炉，几乎也要血；”[鲁 1927]，但是从另一个角度想一想，桌子为什么摆在那里？火炉为什么是这个样子？不应该思考一下吗？

尽力描绘出真实的现状，说起来非常简单，做到却极其困难。为了克服困难，建模人员甚至应当在心里暗暗发誓来约束自己：如果不尽力去靠近真相，天打雷劈！

下面列出一些描述现状时经常犯的错误。

4.3.1 错误：把想象中的改进当成现状

现状真的就是现状的意思，意思绝不含糊。很多时候明明已经敲黑板强调了：

——今天是哪一年几月几号？

——****年*月*号

——好，把你的序列图名称的最后加上今天的日子，然后想想如果今天发生这个业务流程，会是什么样的？

即使如此，有的建模人员依然义无反顾地直接画出想象中改进以后的场景，而且自己还没有“是不是画错了”的感觉，被指出来后才恍然大悟。

背后的原因很可能是根本没有深入到组织流程中去做观察和访谈，对现状没有认识，只好想像一个改进后的场景来应付。

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

待引进系统就像给客户准备的一个礼物。三十年前人们走亲访友，带一包米、一只鸡、一筒饼干作为礼物是非常得体而且受欢迎的，现在大家武装到了牙齿，你还带这些礼物去，对方都不知道怎么说你好呢。

有的建模人员以为人做的事情才是本质的，所以他画的业务流程中，只有人，没有非人系统。业务流程中全是人，那是二十多年前的“现状”，那是先锋、安易、用友等应用软件先驱刚刚起步的年代。基于二十多年前的现状来改进，得到的系统岂不是要和二十年多前的软件一样？这样的软件怎么能适应现在的需要？

如图4-24所示，目标组织于2000年成立，在2010年之前，业务流程主要由人完成。2010年，引进一个软件系统，2014年，又引进一个软件系统，然后A开发团队从2014年开始介入目标组织的信息化工作。2016年，目标组织引进A开发团队开发的软件系统a1，后来，又引进了A开发团队开发的另一个软件系统a2。

图4-24 不同视角看到的组织流程变迁

真正的现状就是图中最下一行的场景。而把“现状”误解为“纯手工”，说的就是把2000年的情况当成现状。

4.3.3 错误：把“现状”误解为“本开发团队未参与之前”

还有一种有趣的错误。A开发团队里的建模人员把图4-24中2014年的情况当成现状，因为在2014年，A团队开始介入，所积累的业务流程资料是从2014年开始的，所以建模人员认为2014年是目标组织的起点——又犯了从自己角度看问题的错误。在A团队看来，只变了两次（0-1-2），在目标组织看来，变了23次（0-1-2……23）。

用第2章提到的“智子法”可以避免这样的错误，A团队的人全部完蛋了，系统是路上捡来的，哪里还有A团队什么事。

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

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

4.3.5 错误：“我是创新，没有现状！”

互联网创业公司的开发人员很容易犯这个错误，动不动就说“我做的是互联网创新，没有现状！"

第2章已经说过，老大的大脑就是战场，敌人已经挤得满满当当。老大的时间和金钱是有限的，要让老大赏脸接纳某个系统，必定要动现状某个地方的蛋糕。老大不会因为“好新鲜，没见过这样的东西”就欣然接纳，这个“新”东西必须表现出比现状的某个方面好才行。

创新没什么了不起和神秘的，所有需求工作都是创新。有的时候，创业者号称“创新”的东西，只是创业者自己没做过，觉得“新”而已，客户早就见过了。如果是这样，创业者找块豆腐撞死算了。

4.3.6 错误：“我做产品，没有现状！”

非定制系统的开发团队经常拿这句话做借口。A公司的流程和B公司的流程有差异，中国的流程和外国的流程有差异，画谁的现状好呢？

如果理解了第2章的内容，知道“做需求时把产品当项目做”的道理，就不会困惑了。“现状”指目标组织的现状，是具体而且有最佳答案的。

本书不提供练习题答案，请扫码或访问http://www.umlchina.com/book/quiz4_1.htm完成在线测试，做到全对，自然就知道答案了。

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

 A) 活动图

 B) 用例图

 C) 序列图

 D) 状态机图

 E) 流程图

 F) 依赖图

2. 以下序列图中消息正确的是：

 A)

 B)

 C)

 D)

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

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

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

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

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

4. 在业务流程中有这么一步：助理使用QQ邮箱系统将计划书发给经理。如果QQ邮箱系统在业务流程中有重要的地位，不得忽略，那么以下序列图责任分配合理的是：

 A)

 B)

 C)

 D)

5. 以下序列图存在错误的地方有（本题可多选）

 A) ①

 B) ②

 C) ③

 D) ④

 E) ⑤

 F) ⑥

6. 想做一款男女约会神器，提高上垒的成功率。建模人员在描述现状业务流程时犯难了，现状到底是写情书、酒吧勾搭还是用陌陌约？以下做法正确的是：

 A) 每种现状都描述，分别改进

 B) 因为是做产品，基本没有现状，不用描述现状业务流程

 C) 先定位目标人群和老大，再描述现状

 D) 写情书是最本质的，应该描述写情书

4.4 案例-现状业务序列图

根据愿景“减少助理在组织公开课时的工作量”，初步判断最值得改进的流程片段是发布公开课通知的片段，如图4-25所示。

图4-25 发布公开课通知的流程片段

4.5 工具操作-现状业务序列图

【步骤1】在UMLChina的业务用例图上右击参加公开课用例，从快捷菜单选择New Child Diagram|Add Diagram。

图4-26 添加图

【步骤2】在New Diagram对话框中，将Name改为发通知201706，在左侧的Select From列表选择UML Behavioral，在右侧的Diagram Types选择Sequence，单击OK按钮。

图4-27 空白序列图

【步骤3】双击业务建模|业务对象包下的业务对象类图。单击工具箱中的，单击类图空白处，在弹出的Class属性框，设置Name为助理，Stereotype选择business worker（如果列表中没有选项，则直接输入文本），单击确定。同上操作添加一个类，名称为时间，Stereotype为business entity。