第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-10中提到的系统内部的组件，应该在分析和设计工作流中描述；图4-11中提到的交互步骤，应该在需求工作流中描述。
过早把不同抽象级别的知识混杂，大脑需要处理的逻辑就会从M+N+O+P增加到M*N*O*P。正确的做法是分开表达，这一点本书第8章还会进一步阐述。
4.2.3 只画核心域相关的系统
业务流程中涉及到的非人智能系统，远远比我们意识到的多，业务序列图上只能表现出其中一部分。例如，图4-11中，运营部请求销售支持处理客户资料时，有可能是通过微信联系的，那么，微信需不需要作为一个业务实体出现在业务序列图中？
大致的判断标准是：如果是核心域相关的系统，应该出现在业务序列图中，如果不是，可以不出现。如图4-13，工作人员制作文档，还是工作人员用Word制作文档？如果描述的是采购的流程，可能左侧就可以，如果描述的是制作文档相关的流程，可能应该画成右侧。具体问题还需要具体分析，所以以上用词是“大致”、“可能”。
图4-13 Word要不要画出来？
核心域/非核心域的概念，在后面的工作流中还会不断提到，此处先不详细讨论。有时很难判断也没关系，您想过这个问题，就已经比没想过要好了！可以先画出来，然后如果发现它跟改进无关，再把它删掉。例如图4-13先画出Word，后来发现工作人员用Word还是WPS制作文档，不影响采购流程的改进结果，再把它删掉。
4.2.4 把时间看作特殊的业务实体
业务序列图中，我们把时间看作特殊的业务实体。时间就像上帝造好挂在天上的一个大钟，向全世界各种系统发送时间消息。这样，就和后面需求工作流中映射系统用例的时间执行者一致了，同时也帮助理清什么情况下使用时间执行者的问题。
图4-14 把时间当作一个系统
注意：时间和定时器不是一个概念。时间是外系统，定时器是其他系统用来和时间打交道的边界类。世界上只有一个时间系统，但有无数的定时器。有的建模人员在识别系统用例时说“执行者是定时器”，这样说是错的，执行者是时间。
图4-15 时间和定时器的区别