[答疑]业务序列图的虚线、实线和没有线

​​DDD领域驱动设计批评-文集-点击查看>>​​

大熊 2022-3-25 11:42

在学习您的课件。人事系统没有消息到主管，员工有，意思是不是直接找人？按照您说的箭头的意思是请求帮忙，备案的箭头是不是应该反过来系统请求人事专员？什么时候该画虚线，不是很理解，想请老师指教。

UMLChina潘加宇

不同的画法，体现了不同的场景，不是随便乱画的。我们一步步看一下：

【步骤1：交请假单】

问题所给图中，人事系统没有实线或虚线箭头指向主管，也就是说，人事系统在这一步没有和主管有任何交互。

如果是下面这样，人事系统和主管有一条虚线：

图1

意思是人事系统会有信息给主管，但员工这边并不等待着主管知晓信息以及作出回应。

更具体一点的场景，例如：

员工使用人事系统交请假单，人事系统保存好，然后，人事系统会在它和主管交互的界面上反馈一条和该请假单相关的信息，但主管什么时候注意到，就不知道了。员工也觉得这样就行了，放下这个事情，去干别的事了。

如果是下面这样，人事系统和主管有一条实线：

图2

意思是，员工使用人事系统交请假单，人事系统请求主管批假，而且员工是期望着马上批的。

如果这样画，主管如何通过人事系统批假的交互已经包含在人事系统指向主管的箭头中，不需要再画一条主管指向人事系统的“批假”消息，可修改如下：

图3

体现在用例图上，像下面这样：

图4

当然，由于批假也合并在里面，“交请假单”的名字有点小了，可以改为“请假”。

像图3和图4这样，电脑系统调用人肉系统的情况，是比较少见的，碰到的时候要谨慎再想一想，是不是确实是这样。可以参考《软件方法》：

图5

这里要注意“意淫”错误。

如果员工使用人事系统交请假单，人事系统保存好，就完了，并没有给主管反馈任何信息，那么按照你所提问题中的图这样画就可以，像这样：

图6 同问题图

但有的人就会想：按照工作流程规定，这个请假单接下来是给主管审批的呀，等主管下次用人事系统批假的时候，人事系统就会把这张请假单给主管看……于是，他就“意淫”了一条消息，像图1这样画：

图7 同 图1

这是不对的。

首先，在这一步，并没有任何事情发生，这条消息纯属意淫；

其次，也是最致命的认识错误，以为数据和行为是一一对应的——把“请假单”数据和“主管批假”行为绑在一起。而这个世界之所以复杂，或者说软件之所以复杂，就是因为数据和行为不是一一对应的。一条“请假单”数据摆在那里，接下来会用到该数据的行为可能是“主管批假”，还有可能是“员工撤销”、“时间过期失效”、“人事专员批量删除”等等，如果要意淫就应该充分意淫，这样画才对：

图8

上面的意淫还有一种变体：

图9

员工使用人事系统交请假单，然后人事系统自己来一个“流转到主管环节”，其实系统可能只是把请假单保存下来，根本不存在一个“流转到主管环节”这样的行为。

建模人员可能意淫了一个采用某工作流框架的设计方案，把它带入业务序列图中，这样的内容连需求都不是，更不用说业务建模了。

涉众在意的可能是“主管负责审批自己所主管部门的员工提交的请假单”或“请假单必须经过提交请假单的员工所属部门的主管审批通过才能生效”这样的业务规则，这些规则可能会绑定到人事系统的某个用例规约的某个步骤。如果是问题所给的图的情况，应该在“主管→批假”用例中，如果是图2或图3的情况，应该在“员工→交请假单（更贴切是“请假”）”用例中。

【步骤2：员工找主管】

再来看员工找主管这一步：

图10

意思是员工请求主管批假。

例如，员工面对面用肉嗓子向主管请求；

例如，员工通过微信、QQ、电话、Email向主管请求，但采用哪一种方式，不属于我们关注的核心域的问题，也不影响我们的改进结果，那么就可以不用画微信、QQ、电话系统、邮件系统等，表达如图10即可。

参见《软件方法》：

图11

如果强调用某种通信方式，例如微信，可以画成这样：

图12

微信是和员工、主管平等的系统。员工已经不能请求主管批假，只能请求微信发消息，然后看微信的脸色。

【步骤3：人事部专员备案】

再往下看，问题所给图中，人事部专员是孤零零的，没有任何人肉系统或电脑系统给他发消息。

意思就是他吃饱喝足，啥时候有空想起来有这么个事了，就到人事系统这边来备案。

如果此处又没事找事，非得从哪里画一个消息指向人事部专员，那又属于意淫了。