《分析模式：可重用对象模型》-- 责任模式

<!---->

<!---->作者：无<!---->

<!---->

1 责任模式
这一章关注的重点是关系，以及怎样为错综复杂的关系建立模型，另外，所有的插图都来自原书（《Analysis Patterns：Reusable Object Models》），并遵循UML标准。

1.1 Party模式
在这一章中，首先我们接触到是是Party模式，在进行系统分析和概念模型设计的时候，经常发现人和各种各样的组织有着同样的行为，例如，固定电话的计费可能是针对个人，也可能是一个单位；需要各种服务的时候，你可能求助于一个服务公司，或者服务公司一个特定的业务员。总之，因为人（Person）和组织（Organization）表现上的一致性，如下图所见，我们从中抽象出Party，作为Person 和Organization的抽象父类。

 

1.2 组织（Organization）的内部结构
第二步，如果我们把注意力转移到组织（Organization）的内部结构，就会发现一些有趣的问题，通常最常见的一种结构是金字塔结构，因此建模时可能按照这样的结构建立线性的模型，例如：

这样的模型并没有错误，但是有缺陷，首先不能满足比较复杂的组织关系，更严重的是，一旦需要更多的层次关系，例如存在部门直接上下级关系以及区域附属管理方式，必将引起整个模型的更改，对系统的影响可想而知，在这种情况下，最通常的改进措施是引入层次关系，如下图所示：

通过增加新的关联关系，可以灵活实现组织（Organization）之间的各种关系以及可能的变化。在上图中，{hierarchy}是一个约束（constraint）来限定关系。

1.3 组织关系抽象
第三步，在一般的情况下，以上的模式已经足够解决问题，但当这样的层次和组织关系很多而且复杂时（超过两种），例如现在流行的矩阵管理，就可以将关系本身抽取出来独立处理，如下图所示，作者此时考虑到组织结构的有效时段，所以加入了一个时间段属性来记录组织结构的存在时间。

请注意，在这个模式中，Organization Structure才是模式的核心，在系统中，由两个Organization的实例（分别充当parent和subsidiary），以及一个Type实例来说明该结构的类型。在这样的结构中，可能存在许多的规则（Rule），这些规则可以根据情况分别处理：如果Type很多，而且规则主要跟Type有关，就分配给与Type相关联；如果Type并不多，但主要根据Organization的子类型变化，就可以分布到Organization的子类型中。

1.4 责任（Accountability）模式
第四步，从第一步看到，Party是Person和Organization的抽象父类，因此把Party代入上面的模式（有点象我们小时侯代数里常用的代入），正式形成责任（Accountability）模式。

1.5 知识层（Knowledge level）和操作层（Operational level）分离
出现这样一种想法是考虑到以下情况：当Accountablity Type的数量比Accountability的数量多很多的时候，处理Accountablity Type的规则也变得更为复杂，要解决这样的问题，就可以引入知识层和操作层的分离。

由下图可见，用虚线隔离开的，就是知识层（Knowledge level）和操作层（Operational level），在这个模型中，知识层（Knowledge level）由三个类协作完成，它们分别是Accountablity Type、Connection Rule、Party Type，在Connection Rule中定义合法的Party关系规则，并通过Accountablity Type对Accountablity进行创建时的合法性检验。它的另一个好处就是，可以将知识层的实例化独立出来，作为操作层（Operational level）运行时的配置；换句话说，当知识层的规则改变时，系统的行为将被改变，而不需要任何其他代码的改动，这当然是一种比较理想化的情况。

 

由此想到，构建专家系统的设计思路也可以从这个模式得到一些启发，这是笔者一时的感触。

在原书中，如何实现这样的模型提得比较模糊，但是笔者认为，可以将它们作为正常的模型来实现，两个层次的区分只是表明它们各自担负的任务和地位不同。知识层倾向于描述系统可能存在的各种形式，并设定判断系统是否有效的各种规则；操作层则描述在这样的配置下系统实际的行为。通过改变内在的配置来改变外在的行为，就是这个模式的目的。

由于这个模式的特点，改变系统行为时不必更改操作层的代码，但是，并不意味着改变系统行为连测试也不必要做。同样，也需要调试、配置管理。

作者也提到，这样的模式用起来并不轻松，甚至在一般的系统中也不必要，但当你发现有必要用它的时候，别犹豫（感觉象用降落伞一样）！

1.6 小结
从简单到复杂，前面分五步介绍了适用于解决Party及其关系的各种模式，每种推荐的模式都有其表现的机会，希望我这篇文章可以起到一些抛砖引玉的作用，并欢迎大家对其中的错误进行指正，欢迎发表意见，进行交流。