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