业务序列图要点（1） -202606更新《软件方法》第4章

DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

4.1 建模步骤A-4 组织的现状流程

4.1.1 业务工人和业务实体

……

从替换零件的观点来看，软件开发的目标系统就是一个业务实体，它的目的是替换组织流程中原有的业务工人或业务实体，也就是（2）和（3）。

这样，探索目标系统需求的思路就出来了：

*观察组织的现状流程并使用UML序列图来建模流程；

*思考如果把目标系统作为一个新的业务实体引入组织流程，流程可以怎么改进，建模所期望达到的改进后的组织流程；

*在改进后的组织流程上，把目标系统为其他业务工人或业务实体提供的服务（或者说其他业务工人或业务实体指向目标系统的消息）映射为目标系统的用例。

以餐馆为研究对象，以上所说的观察、建模、改进、映射如图4-6所示。

图4-6 观察、建模、改进、映射

业务工人和业务实体是组织内可以替换的零件，不是组织的价值，因此，在前面建模业务用例时，不需要识别业务工人和业务实体。接下来，建模业务用例的实现即组织流程时，如果用UML序列图表达组织流程，才开始出现业务工人和业务实体。

在建模工具中，我们可以把业务工人和业务实体作为类（Class）的一个构造型，放在名为“业务对象”的包里。如果您使用的工具没有<<Business Worker>>和<<Business Entity>>构造型，可以自己造，或者干脆不要构造型直接用类表示。

4.1.2 业务序列图

用面向对象的思想来建模组织和系统，背后的思想是一样的：类之间通过协作实现用例。

组织内的业务工人和业务实体协作完成组织的用例（业务用例）；系统内的边界类、控制类、实体类协作完成系统的用例。如果用UML序列图来表示，表示前者的序列图叫业务序列图，表示后者的序列图叫分析序列图。

图4-7展示了一张业务序列图： 

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

4.1.2.1 消息的含义

序列图最重要的要点是消息的含义。A指向B的消息，代表“A请求B做某事”，或者“A调用B做某事的服务”，“做某事”是B的一个责任。

图4-7中，指向财务主管的消息“审批报销单”映射了财务主管的“审批报销单”责任。注意，消息箭头已经有请求的意思，消息名称中不用画蛇添足加上“请求”二字。

注意，如果“请求*****”本身就是该对象的责任，那么消息名称里有“请求*****”是正常的。这样的现象常出现在很多扮演中介（或网关、代理、门面）角色的系统中。如图4-8，AI大模型统一路由的责任确实就只是“请求大模型*****”，并不做后面的具体事情。

图4-8 消息（责任）里有“请求*****”的例子

在序列图中，数据流仅仅作为消息的输入或输出参数存在，例如图4-7中的“报销单”。

如果不了解这一点，就容易把消息的方向当成数据流动的方向，不但消息名称没写对，还会出现成对的消息，如图4-9所示。

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

4.1.2.2 合理的抽象级别

（1）生命线上的对象是系统

业务序列图表达组织内各个系统之间的交互。出现在业务序列图生命线上的对象，其合适的颗粒大小就是系统，包括人脑系统（业务工人）和非人系统（业务实体），比系统大或者比系统小都是不合适的。

如果建模人员不把这一点时刻记在心中，打哪指哪，抽象级别随着兴之所至跳跃，就会使业务序列图中混入不该有的内容。

图4-10的业务序列图中，CRM系统的一个组件“客户表”露了出来，但目前的抽象级别并不关心CRM系统中是不是使用关系数据库保存数据以及数据库中是不是有一个表叫“客户”。

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

出现这样的问题，原因往往还是前文所说的建模人员的“灵机一动”。因为缺乏严谨的方法学指导，突然想到什么，就视作珍宝，迫不及待地堆砌在图中。

★伪创新圈子类似现象尤其多。

这样的错误往往表现为“选择性”，建模人员能“灵机一动”想到的，就拼命炫耀，“灵感”没顾及的，选择性忽略。

图4-10中，如果真的要考虑系统内部组件这个抽象级别，“分配销售专员”操作也会影响一些表，怎么不画出来？“销售支持”也有内部组件的，当他使用“CRM系统”记录资料时，他的大脑负责指挥，他的心脏提供能量，他的手指负责录入。大脑、心脏、手指怎么没画出来？

图4-10的错例是生命线上的对象比系统小，图4-11则是生命线上的对象比系统大。

图4-11 把担保公司整个放进序列图

图4-11中，只有“担保公司”一个业务工人，没有其他业务工人或业务实体。这种情况很有可能是把整个要研究的组织当作一个业务工人给搬上来了，之前画的业务用例图有可能如图4-12：

图4-12 担保公司的用例图

和图4-12相比，图4-11添加了用例的交互步骤，但这是不够的，因为它没有剖析出担保公司内部各个人脑系统和非人系统之间的协作。

当然，图4-11作为一个中间产物存在是可以的。如果建模人员暂时不了解组织内部有哪些人脑系统和非人系统以及各自承担什么责任，也可以如图4-11先把整个组织囫囵当成一个系统画出来，先理清和外部组织的交互，然后在调研过程中进一步细化组织内部。