UML软件工程组织

《分析模式:可重用对象模型》-- 责任模式
Windy J(windy.j@163.com)

1          责任模式

这一章关注的重点是关系,以及怎样为错综复杂的关系建立模型,另外,所有的插图都来自原书(《Analysis PatternsReusable Object Models》),并遵循UML标准。

1.1    Party模式

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

1.2    组织(Organization)的内部结构

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

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

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

1.3        组织关系抽象

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

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

1.4    责任(Accountability)模式

第四步,从第一步看到,PartyPersonOrganization的抽象父类,因此把Party代入上面的模式(有点象我们小时侯代数里常用的代入),正式形成责任(Accountability)模式。

1.5    知识层(Knowledge level)和操作层(Operational level)分离

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

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

 

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

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

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

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

1.6        小结

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

原文参照《Analysis PatternsReusable Object Models》,Chapter 2Martin Fowler

 

版权所有:UML软件工程组织