阿嬷情书 ·业务序列图-202606更新《软件方法》第4章

原创于 2026-06-29 11:04:46 发布 · 置顶 · 209 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#产品经理 #UML #架构师

软件方法书专栏收录该内容

107 篇文章

订阅专栏

DDD领域驱动设计批评文集

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

《软件方法》各章合集

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

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 生命线头部的实例是系统

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

★参考第2章的图2-7，生命线头部的文本，冒号左侧对应“系统”实例的“名称”属性值（可留空），冒号右侧的文本（例如图4-7的“财务主管”、“SCS”）对应“系统规格”的“名称”属性值。

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

（1）错例：生命线上出现系统的部件

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

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

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

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

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

（2）错例：生命线上出现组织

图4-11中，只有“担保公司”一个业务工人，没有其他业务工人或业务实体。

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

这种情况很有可能是把整个要研究的组织（在这里是“担保公司”）当作一个业务工人给搬上来了，之前画的业务用例图有可能如图4-12：

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

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

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

（3）错例：生命线上出现非智能的信息载体

如图4-13，建模人员把“申请单”的实例放到了生命线上。这样的事情在“申请单”为纸质时更容易发生，因为此时申请单的信息放在建模人员看得见摸得着的介质上。这可能也是Jacobson的书以及RUP把类似这些当成业务实体的原因。

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

申请单只是信息项，最多能作为消息参数传递，如图4-14所示。

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

可能有的读者纳闷：我怎么记得看过这样的书，里面的序列图生命线上出现订单、申请单对象？

这可以发生在分析工作流。如果在分析工作流用面向对象方法学去构思目标系统的内部结构和行为，就会得到订单、申请单等假想的对象。然后，我们尽可能把逻辑封装在这些对象对应的类中，这样看起来对象就有了生命，能承担责任。

如果市民使用某个非人信息系统来填申请单，该系统的分析序列图可能会如图4-15。在“市民→提交申请”用例中，系统会创建“申请单”对象，在“科员→审批申请”用例中，“申请单”对象可能会收到“审批”的消息。

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

如果在分析工作流不采用面向对象方法学来构思系统的内部，那就没有订单、申请单这些类了，但不影响业务建模工作流使用面向对象方法学的产出结果。

4.1.2.3 应该出现哪些系统

在工作或生活的流程中，我们所使用的非人系统，远远比我们意识到的多。

我们以上面的图4-10为例。“运营部”请求“销售支持”处理客户资料时，有可能是通过即时通讯软件（例如微信）联系的，而使用即时通讯软件时，可能要用到第三方输入法（例如搜狗输入法）；同理，“销售支持”使用“CRM系统”记录客户资料时，除了“CRM系统”之外，可能要用到浏览器、第三方输入法。

★以上只考虑了应用级别的系统，还未考虑数据库管理系统、操作系统等基础设施。

那么，可不可以考虑把图4-10的序列图画成图4-16这样？

图4-16 把更多的非人信息系统放入序列图

一般不会像图4-16这样画，理由当然不能仅仅说“直觉”。考虑的出发点应该是领域。

此处建模的是销售部的分派客户流程，从“销售-客户”领域的视角来看，可以判断“搜狗输入法”、“微信”和“销售-客户”领域没有特定关系。

一方面，如果其他领域的另一个组织也使用“搜狗输入法”和“微信”。当建模人员建模该组织的流程时，如果把“搜狗输入法”和“微信”放入序列图，应该可以观察到它们所参与的流程片段和图4-16并无区别。

另一方面，“运营部”使用邮件、QQ、微信、钉钉还是飞书给“销售支持”发资料，从“销售-客户”这个领域的视角看，没有区别。

因此，一开始可以不考虑“搜狗输入法”和“微信”等系统。

（严格来说，“搜狗输入法”和“微信”是系统规格。为了兼容读者的阅读习惯，在不影响方法学模型严谨性时，本书的叙述也采用“系统”的说法。）

如果只把和“销售-客户”领域特定相关的系统放入序列图，经过观察找不到能满足愿景的改进方案，或者得到的改进方案难以实现，这时可以考虑把另一个相对更“基础”的领域的系统加进来（例如“通信”领域的“微信”），观察是否可以在这个领域寻找改进点。如果还不行，还可以再加入更更“基础”的领域的系统（例如“搜狗输入法”）。

这样的情况虽然稀少，但也不是不会发生。

还是以图4-10为例，如果愿景是“减少客户的平均等待时间”，经过仔细观察发现，导致时间拖长的罪魁祸首是：

有部分运营人员、销售支持和销售专员普通话说得不好，拼音输入也用得不好，喜欢用潮汕话沟通，导致各个环节都出现信息传递错误以及需要反复确认，最终导致时间拖长。偏偏这些人还是公司老板的亲戚，不能替换。

此时，在流程中引入潮汕话即时翻译机或潮汕话智能输入法，也许就可以满足愿景。

（★此处以潮汕话为例，是跟风最近的热门电影《给阿嬷的情书》。读者也可以自行替换为粤语、吴语等其他方言或壮语、藏语等少数民族语言）

这个时候，改进所发生的领域已经和“销售-客户”没有特定关系。

发生这样的情况，可能意味着之前所定位的目标组织是错误的，需要重做第2章的建模。

当然，即使该组织有可能不是目标组织，不妨碍开发组织在有相应能力的情况下顺便帮它做改进，或者在没有相应能力的情况下为它推荐更合适的其他开发组织。

这里务必要谨慎，不要轻易以为自己发现了一片蓝海“潮汕话翻译机或潮汕话输入法”。

当初建模人员思考开发组织的能力时，如果没有列出这些能力，可能意味着建模人员当时认为开发组织的这些能力并没有竞争优势，那就不是什么蓝海了。

就像一位内分泌科医生，遇到一位心慌、手抖、出汗、体重下降的患者。医生一开始以为患者是甲亢，打算把他纳入自己写论文的病例。进一步检查，却不支持甲亢，症状主要与长期焦虑有关。这个病例就不再是内分泌科医生擅长解决的典型病例，内分泌科医生可能会推荐患者去看心理医生。