业务工人业务实体元模型-软件方法（下）第9章分析类图案例篇Part09

DDD领域驱动设计批评文集>>

《软件方法》强化自测题集>>

《软件方法》各章合集>>

人群

前面为了不干扰主要的知识点，一直在回避一个问题：怎么看待在组织外面和组织打交道的人？例如，以“中原城镇银行”为目标组织，它服务的储户算什么？

法律上提供了“法人”的概念，把机构拉平到和自然人成为对等的民事主体。不过，在《软件方法》领域的领域模型中，我们把自然人看作人脑系统的容器，而且这个容器在“发糕”的分析模型中暂时不体现。

我们决定采取的处理方式是，把“人群”当作一种“组织类型”，具体人群则相当于具体的组织。以“中原城镇银行”为例，假设其目标储户人群为“中原富裕农民”（注意，要定位），可能的对象图如图9-65：

图9-65 人群作为组织类型的对象图示例

图9-65中，名称为“人群”的组织类型，直接上级是名称为“非正式组织”的组织类型，而名称为“银行”的组织类型和名称为“正式组织”的组织类型之间，可以有中间组织类型。

图9-65的信息如果转成业务用例图，则为图9-66：

图9-66 图9-65的信息对应的业务用例图

如果读者看到这里，冒出类似于“难道只有中原富裕农民可以到中原城镇银行存款吗？中原不富裕农民不行吗？广东的白领去存钱，难道要把人家拒之门外吗？”的想法，那就需要再复习本书的第2章到第5章。

如果需要美观，可以在“组织类型”、“组织”、“业务用例”等类添加一个“图示”属性，其属性值以图形方式反映“名称”属性值所表达的含义，然后在图上用图标代替名称。这个留待以后再考虑。

9.2.2.5 业务工人和业务实体

组织的业务用例所承诺的价值，需要通过一些系统的协作来实现，如图9-67：

图9-67 业务用例的实现

这些系统协作的过程可以称为业务用例的路径或者业务用例的流程，以下我们统一使用最常见的“业务流程”一词来表达。

一个业务用例会有多个业务流程，有主流程，有分支流程，甚至有分支的分支流程。如果用序列图描述，可以把流程看成若干交互片段，每个交互片段由若干消息组成，消息在系统实例之间传递，类图如图9-68：

图9-68 和业务流程相关的类图

我们可以通过图9-68来定义《软件方法》上册中业务工人和业务实体的概念。

业务工人：参与组织的业务流程的人脑系统；

业务实体：参与组织的业务流程的信息系统。

（图9-68也有助于初学者厘清“系统是属于哪个组织”的问题。信息系统“支付宝”由蚂蚁金服公司开发、运营和维护，人脑系统“保安”由保安公司负责招聘、培训和发薪水，但它们都参与到某家医院的流程中，它们就是这家医院的业务工人和业务实体。）

业务工人、业务实体只是系统扮演的角色，我们不能直接说“A系统是业务实体”，因为A系统可能参与组织甲的业务流程，却和组织乙无关。

如果只是要记住哪些系统在哪个组织中扮演业务工人和业务实体，可以使用如图9-69的类图：

图9-69 业务工人和业务实体是系统扮演的角色

不过，我们有了图9-68，就没有必要另外维护类似于图9-69的信息。在建模时，我们只需要说明某个系统的类型是人脑系统或信息系统。如果描述某个组织的业务流程的序列图中有某个系统的实例参与，该系统自然就会成为该组织的业务工人（如果系统的类型是人脑系统）或业务实体（如果系统的类型是信息系统）。

目前的UML建模工具并没有封装这方面的逻辑，常见做法是建立一个类，指定其构造型为“Business Worker”或“Business Entity”，相当于直接为系统指定了角色。例如，案例一“答题抽奖”中就建立了如图9-70的业务工人和业务实体：

图9-70 案例一“答题抽奖”的业务工人和业务实体

如果只是建模业务流程，这样做基本上没有问题。一个系统如果出现在模型中，如果不参与目标组织的流程，把它画出来干什么呢？

不过，更本质的知识是“系统是人脑系统（信息系统），可以在组织中扮演业务工人（业务实体）”而不是“系统是业务工人（业务实体）”。进入需求工作流，研究范围缩小到目标系统时，系统还可以扮演目标系统的执行者，扮演目标系统的涉众（如果类型是人脑系统）。

在《软件方法》上册第5章中说到如何获得系统用例图时，介绍了业务序列图映射系统用例图的方法，但现在的建模工具如EA等，并没有办法完成这个映射，需要建模人员把在系统用例图上建立系统执行者，然后把业务工人、业务实体的名称“搬运”到系统执行者上，如图9-71：

图9-71 业务工人、业务实体和系统执行者的映射

“发糕”需要封装这些映射的逻辑，为建模人员生成系统用例图，并保证有业务序列图存在时，系统用例图的信息不和业务序列图的信息冲突。

关于业务序列图、系统用例图等内容，后面还会再探讨。

我们把当前类图的进展合并，得到图9-72：

图9-72 合并得到的类图

系统和组织的其他关系

除了扮演业务工人和业务实体，系统和组织的关系可能还有：

*组织是系统当前的目标组织（这个看起来和前面的重复，其实不是）

*组织负责提供建造系统的人力资源

*组织负责提供建造系统的金钱资源

……

（待续……）