9.2.2.4 业务用例
在9.2.2.1,我们描述过组织的结构,这是一种组织之间的上下级关系,但这种关系不是《软件方法》关注的重点。
《软件方法》更关注的是组织为其他组织提供的服务,或者说,业务用例,如图9-55。
图9-55 业务用例图示例
把图9-55中的各个概念建模,得到类图如图9-56:
图9-56 业务用例图示例
对象图示例如图9-57:
图9-57 业务用例相关概念的对象图示例
如果把图9-57的信息变成业务用例图,就得到图9-58:
图9-58 对象图信息所表达的业务用例图
当然,图9-57和图9-58仅为示意。只要我们乐意画出来,所有的组织都可以画业务用例图,但在实际项目中,目标组织往往只有一个,如果解决了某个组织的问题之后,再把战场转移到另一个组织,那可能已经是另一个项目了。
把图9-56和之前的图9-42合并,得到图9-59:
图9-59 合并图9-42和图9-56
图9-59中,“组织”之间的关联既有“上下级”也有“业务执行者”,这两者不能互相取代。
业务执行者未必和目标组织有上下级关系。例如,以一家企业为目标组织,客户、供应商、政府部门可能是它的业务执行者,但并不是它的上下级。
那对于一个组织来说,有上下级关系的组织是不是它的业务执行者呢?这就碰到了在第8章评论“聚合根”时类似的问题,看这个上下级关系是怎么定义的。
如果把上下级关系仅仅看作管理或汇报关系,当我们谈到上级组织时,并没有把下级组织包括在里面,那么它们之间可以互为业务执行者。
如果认为下级组织位于上级组织内部,这个时候,如果以下级组织为目标组织,上级组织应该算是业务执行者;如果以上级组织为目标组织,下级组织应该看作组织内部的部件(如何处理后面还会谈到),不是业务执行者。
当然,就算是业务执行者,如果愿景不涉及与上下级组织相关的业务用例,未必需要在模型中出现。
组织和组织类型
从图9-57、图9-58可以看出,“组织”的实例是一个个具体的组织,例如“UMLChina”、“中原金软软件有限公司”、“中原城镇银行”。
但我们平时看到的,更多是图9-60这样的业务用例图:
图9-60 更常见的业务用例图
图9-60中的“银行”、“企业”对应的概念应该是“组织类型”,而不是“组织”,而中间这个椭圆“贷款”对应的概念可以叫“业务用例模板”,如图9-61:
图9-61 图9-60对应的概念
如果按照图9-60来修改图9-58,得到的应该是图9-62这样的用例图:
图9-62 组织类型级别的用例图
把“业务用例模板”添加到图9-59的左上角,可以得到类图如图9-63:
图9-63 加上了“业务用例模板”的类图
不过,如果专门维护“业务用例模板”,可能会导致建模人员的思想僵化,例如下面的拟人化场景:
发糕:目标组织是一家什么类型的组织?
建模人员:银行。
发糕:咳,那不简单嘛,银行的业务用例模板就是“存款”、“贷款”……,是否照搬?
建模人员:照搬!
每个组织都有可能有各自的创新,不应该被模板框住。谁说银行就是存款贷款了,我开创一个卖汗血宝马的业务不行吗?就像人家于谦老师,又说(卖)相声,又养(卖)矮马。
图9-64 相声演员于谦在喂马
因此,“发糕”不专门维护“业务用例模板”,也就是说,保持图9-59的类图,不需要变成图9-63。
如果建模人员在思考业务用例时需要帮助,可以指定某个组织类型,“发糕”会列出系统已经知道的、属于该组织类型的组织的业务用例(需要升级到“发糕年度大会员”才能开通此服务!),供建模人员参考。
查询语句类似于:
业务用例s .Where(业务用例 => 业务用例.目标组织.组织类型 == x)
因此,在建模时,目标组织和业务执行者都要尽量定位到具体组织。如果建模人员没有定位,直接用了“银行”、“企业”等组织类型名称,那么也应该理解成某具体未知银行,某具体未知企业,“发糕”将会提示建模人员,此处还需要做定位思考,不能偷懒。
人群和机构
(待续……)