当某人活某个组织对别人或别的组织承担某种责任时会运用到责任概念。它是非常抽象的概念，可以用来描述很多特殊的问题，包括组织结构、合同协议或者雇用关系等。
本章首先介绍一个重要的模式，团体模式–人和组织的超类型。我们将用组织结构问题来展示责任模型的发展由来。简单组织结构可以用组织层次模式来建模。当 层次结构过多时，会使模型变得复杂，这时需要用到组织结构模式。团体和组织层次模式组合在一起构成责任模式。责任模式可以处理团体之间的许多关系，包括组 织结构、患者同意、服务协议、雇用关系以及专业机构注册等。
当用到责任模式时，有必要描述可形成哪种类型的责任模式，以及这些责任模式的约束规则。这些规则可以用责任知识级的类型实例来描述。该知识级包括团体类 型，该类型用团体类型泛化模式来对各种团体进行分类和子类化，而不用改变模型。层次型责任模式用于表示确实需要严格分级的团体间的关系。这样，责任模式既 可用于刻画层次型关系，也可以用于刻画更复杂的网络型关系。
责任模式定义了团体的职责。这些职责可通过操作范围模式来定义。操作范围模式是责任合同中的一项条款，就像一条命令中的一个子命令。当这些职责逐渐增多，让它们隶属于特定的职位模式而不是隶属于拥有该职位的人员会更有好处。
本章基于多个项目，因为责任是一种很通用的概念。其最初思想来自一个为公用事业开发的客户服务项目和为一个电信公司开发的财务项目。而完整的责任模型则是在做英国国民医疗服务制度的Cosmos项目中开发出来的。
2.1团体
留意一下你的通讯簿，你看到些什么？如果不出我所料的话，你会看到大量的地址、电话号码、E-Mail地址等，这些信息都与特定的某个事务有关。通常该事 务是某个人，但有时也可能是某个公司。这使我想起我经常会给出租车公司打电话，但我并不是要与某个特定的人通话—-我只是想要一辆计程车而已。最初为 通讯簿建造的模型可能如图2-1所示，但是我对该图并不是很满意，因为其中有些概念性的重复。我马上就很自然地想到要找一个能概括人和公司的类型。该类型 是一个典型的还没有命名的概念—-所有人都知道并用到了，但没有人给它命过名。我曾在数不清的数据模型中见过不同的名称：人员/组织、参与者、法定实 体等。
我喜欢用“团体”一次。在图2-2中定义了一个团体作为任何组织的超类型。这样，就可以为公司的各个部门或者甚至非正式的小组建立起地址和电话号码等通讯记录。
多数事务都与“团体”相关而不是与某个组织相关。比如，跟个人和组织互通新建；付款给个人和组织；组织和个人都会产生某些行为，都会有银行账户，都会缴纳税款。我想，这些例子已经足够体现“团体”概念的价值所在了。
例：在英国国民医疗服务制度系统中，有如下一些“团体”：Tom Cairns一生、圣。玛丽医院的肾病治疗小组、公园路地区卫生当局以及皇家医学院。
2.2组织层次
我们首先看一下跨国公司芳香咖啡机制造公司（ACM），它有许多分公司，每个分公司又分成不同的区域子公司，而每个区域子公司又分成不同的部门，每个部门 又有很多个销售办事处。我们可以用图2-3来模拟这种结构关系。然而我对改图也不是是很满意，因为如果公司的组织发生变化，比如说去掉了区域子公司的划 分，我们就必须改变模型。图2-4提供了一个更简单的模型，该模型可以很容易的加以改变。但盖膜行的递归关系隐含着某种危险，比如它允许降部门作为销售办 事处的一部分。我们可以通过定义相应的子类型并对每种子类型施以一定的约束的方式来处理这一问题。一旦组织层次发生变化，我们可以改变这些子类型和约束规 则。通常，改变规则比改变模型结构要容易得多，所以我倾向用图2-4取代图2-3。
上面提到的层次结构具有一定的通用性，但仍然具有其局限性。其不足之处在于它只支持单一的组织层次关系。假设ACM公司针对每种主要的咖啡机系列为所属的 销售办事处配备一个服务小组，那么这个小组就具有双重的责任结构：既向个销售小组负责，也向各产品上产单位的服务部门负责，而这些服务部门则轮流向产品的 支持单位负责。例如，为波士顿的2176大容量卡布奇诺（一种意大利咖啡）咖啡机（每小时生产50杯）设立的服务小组既向波士顿的销售办事处负责，还向 2170系列产品的服务中心负责。该产品服务中心又向大容量意大利咖啡机服务部门负责，该部门则向咖啡机服务部门负责（这可不完全是我编造出来的！）。面 对这种情况，我们可以再增加一个层次结构，如图2-5所示（像图2-4那样，该图中还需要一些约束规则，但我把它留给读者去完成–当成一种练习）。该方 法确实是有效的，但随着更多层次的出现，整体结构会变得非常复杂而无法实用。
2.3组织结构
如果一个模型有多个隶属层次关系，我们可以用一种类型化的关系（如图2-6所示）来表示。我们把层次关系转化为一种类型，通过使用组织结构类型的不同实例 来区分不同的层次关系。这样就能用组织结构的两个实例（销售组织和服务组织）来处理上一节的场景（双层关系）。新产生的层次关系可以通过简单地增加新的组 织结构类型的方式加以处理。显然，这种抽象方式使我们能够在复杂性适度增加的情况下的增加更多的系统柔性。对于双层关系，这样去作并不值得，但是对于多层 关系，就很有必要。另外请注意，组织结构有时间周期；这使我们可以有效地记录组织结构的周期性变化。进而要注意的是，我并没有把组织结构类型堪称是一种树 形—-类型树形是一个很重要的概念，我们将在后面具体谈到。
例：为波士顿的2176大容量卡布奇诺咖啡机而设立的服务小组向波士顿的销售办事处负责。我们可以将其刻画成这样一个组织结构模型：父节点是波士顿的销售办事处，字节点是波士顿的2176服务小组，组织结构类型叫做产品线管理。
例：为波士顿的2176大容量卡布奇诺咖啡机而设立的服务小组向产品你支持结构中的2170产品系列服务中心负责。我们可以把它堪称是一个单独的组织结构，它的父节点是2170产品系列服务中心，而子节点是波士顿的2176服务小组，组织结构类型叫做产品支持。
要简化对象结构，应把重点放在玉树规则上。这些具体的形式可以使：“对于一个组织结构，如果其类型是销售组织并且其子节点是一个部门的话，那么其父节点必 须是一个区域子公司”。请注意，约束规则被表示成指向组织结构的属性，其暗含着约束规则针对该组织结构。然而，这也意味着当通过增加新的组织结构类型的方 式来扩展系统时，会改变组织结构中的约束规则。而且，随着组织结构类型数量的增加，这些规则将变得难以处理。
可以把约束规则放到组织结构类型中（如图2-7所示）。针对特定的组织结构类型的所有规则被集中到一个地方，这样便于增加新的组织结构类型。
然而，如果我们很少改变组织结构类型而是经常增加新的组织子类型，图2-7就难以处理了。在这种情况下，组织子类型的没词增加都会导致约束规则的改变。更 好的办法是让约束规则跟随组织子类型。概括起来，我们的目标是尽量减少模型的变化。我们应该按照这种方式，在不影响模型的其它部分的前提下，把约束放在最 容易发生变化的地方。
2.4责任
图2-7展现了一个组织按照某种定义好的规则，在某段时间里与其它组织存在某种关联关系。虽然一直是在围绕组织进行讨论，但考虑是否能降相同的描述方式也 应用到人身上总是值得的。也就是要文：“人是否可以按照某种定义好的规则，在某段时间里与组织或者别的人存在关联关系？”答案是肯定的，因此我能够并且也 应该降图2-7进一步抽象化，以应用到团体上面。在我这样去作的过程中，我将这种新的抽象概念命名为“责任模式”，如图2-8所示。
例：John Smith为ACM工作，这可以被建模为一个责任模型，其中ACM是委托方，John Smith是责任方，责任类型是雇佣关系。
正如前面这些例子所显示的，从组织结构中抽象出责任模型为我们带来更广阔的空间，可以应对更多的情形，而模型的复杂度并没有增加。基本的模型与图2-7有着相同的结构，唯一的变化是将组织替换成团体。
2.5责任知识级
然而，责任的引入带来了复杂性，因为责任的类型比组织结构的类型要多得多。相应地，定义责任类型的规则将变得更加复杂。
这种复杂性可以通过引入知识级来管理。知识级将模型分为两部分：操作级和知识级。操作级包括责任、团体以及它们之间的关联关系；知识级包括责任类型、团体类型以及它们之间的关联关系，如图2-9所示。
在操作级，模型记录该领域每天所发生的事件；在知识级，模型记录着控制着结构的各种通用规则。知识级的实例支配着操作级的实例的具体配置。在该示例中，责任实例（实际团体之间的关联）受到责任类型与团体类型之间的关联的约束。
例：区域子公司又可细分成各个部门。这可由一个区域子公司结构的责任类型来处理，其中委托方是区域子公司，责任方是部门。
例：患者许可可被定义成责任类型，其中委托方是患者，责任方是医生。
请注意如何用团体类型映射来替代团体子类型化。这时Odell在所讲的“强力类型”的一个实例，其主要出现在用映射来定义子类型时。团体类型与团体的子类 型有很紧密的关系，因为子类型“区域子公司”必须有它的类型作为团体类型团体类型“区域子公司”。从概念上讲，可以把团体类型的实例看成是与团体子类型相 同的对象，虽然用主流的编程语言无法直接实现该概念。团体类型是团体的一种强力类型。通常，我们只需要映射（Mapping）或者子类化 （SubTyping）这两者中的一个。但是，如果子类型具有特殊的行为并且强力类型也拥有自己的特征，那么子类型和到强力类型的映射都是需要的 （Odell用一种特殊的表示法来表示这种情况）。
知识级和操作级相对应但并不完全一样，因为父节点与子节点的映射在知识级是多值的而在操作级是单值的。这时由于操作级刻画的是参与责任的实际团体，而知识级刻画的是参与责任类型的可能的团体类型。这种用多值的知识映射来表示单值的操作映射的可能类型的方式是很常见的。
知识级和操作级是模型所具有的一个共同特征，虽然我们经常不显示指明两者之间的差异。我将两者明确地分开是因为我发现这样做有助于理清建模思路。本书中有大量关于操作级与知识级的例子，尤其是在第3章。
建模原则：将模型清晰地分解成操作级和知识级。
多数的数据建模人员用“元模型”一次来描述知识级，我对这样的用法不是很赞同。因为元模型也可以用于建模技术，其中，元模型包括了诸如类型、关联、子类型 以及操作等（例如Rational软件的统一方法的元模型）。知识级则不同，它不描述用于操作级的各种图符。因此我只在刻画用于描述模型语言（图符的语 法）的模型时才使用“元模型”一词。
责任模型表达了一些乡党员是的抽象概念。就像在爬山的过程和总，在高原反应到来之前，我们会停下来做适当的准备。虽然对象模型的结构非常的简单，但在知识 级的实例中却隐藏着大量的知识。仅仅这些工作还不足以实现对象模型，必须对知识级加以初始化。初始化知识级是一个受限的因而也是简单的编程过程，目的是要 有效的配置系统。虽然简单，但仍然是属于程序设计，因此应当考虑如何加以测试。
丰富的知识级也会影响系统间的通信，如果两个子系统需要进行通信，它们不仅必须共享对象模型，还必须拥有同样的知识对象（和这至少是如5.4节所述的知识 级间的一些等价物）。接下来最终我们会遇到下面这个问题：如果责任类型的数量非常庞大，使用图2-9的结构更容易些还是扩展图2-5为每种责任类型配置关 联关系更容易些？问题本身的复杂度是回避不了的，我们只能比较权衡类型结构和知识对象，判断哪个模型更加简单。
需要注意的是，对关系加以类型化并不是可以应用在所有的团体关系上。比如，生物学上的父子关系就不能作为责任类型的一个实例，因为没有团体之间的责任关系，也不存在固有的责任期限。但是法定的监护关系属于责任类型。
2.6团体类型泛化
正如模型自身所体现的那样，其功能的强大不容置疑，但如果能够增加一些有用的变化，则可以使的模型具有更强的适应能力。这些变化可以用在任何使用了知识级/操作级花粉方式的模型中。
我们来分析一下Edwards医生，他是一个普通的分析模式实践者（简称GP）。使用图2-9所示的模型，我们可以把他堪称是GP或者是医生，但不能两者 都是。针对医生所定义的而又适用于GP的所有责任类型都必须重复描述。我们可以采用多种技术来缓解这个问题。其中一种方式就是允许团体类型拥有子类型或者 超类型关系（如图2-10所示）。这样就引入了团体类型的泛化概念，起作用与类型的泛化相似。泛化使得针对责任类型的约束发生了变化，因此既要考虑团体的 类型（来自类型映射），又需要考虑团体的超类型（来自所有的类型映射）。
图2-10给出了团体类型的一个单继承关系。多继承可以通过允许超类型的映射是多值的方式来实现。因此，图2-10只支持单一分类，即如果Edwards 既是一个GP，又是一个儿科医生的话，我们只能通过创建安一个特殊的“GP/儿科医生”团体类型来刻画，赋予团体多种团体类型，这可以通过允许映射到团体 的类型可有多个取值的方式来实现。
有关知识级和操作级之间的许多讨论与元模型建模中的对象和类型的关系是类似的。
2.7层次型责任
要实现责任模型所给出的柔性结构，还需要在一些责任类型的约束规则上多下功夫。比如图2-3所示的组织结构定义了一个严格的层级序列：分公司被划分成若干 区域子公司、区域子公司被划分成若干部门、部门被划分成若干销售办事处。定义一个区域子公司结构的责任类型是可能的，但是如何才能保持图2-3中的严格规 划呢？
首要的问题是图2-3刻画了一个层次型的结构，而责任模型没有相应的规则来约束这样一种结构。这可以通过提供附加有约束规则的责任类型的子类型的方式来加 以处理（如图2-11所示）。这些附加的约束规则和惯例性的约束规则一起共同作用于责任类型，从而保持操作级结构的层次特性，类似的责任类型子类型可以用 于实现一个有向无循环图结构。
利用图2-11，通过一系列的责任类型，我们可以刻画图2-3所示的情形。责任类型“区域子公司结构层1”对分公司负有区域性的责任，“区域子公司结构层 2”对区域子公司富有部门性的责任，以此类推。这种方法确实可行，但是有点笨拙。另一种方式是使用一种如图2-12所示的分级的责任类型，采用这种方式就 只有一种“区域子公司结构”责任类型，其中，各级分别映射到相应的团体类型—-分公司、区域子公司、部门、销售办事处。这种模型使得可以很容易地增加 新的级别的责任类型，并便于修改所需结构中的级别。分层的责任类型捕获团体的责任关系并组织成一个层次型的模型，而分级的责任类型用于捕获其中具有固定次 序的团队责任关系。
遵循“契约式设计”的原则，为责任类型所定义的约束规则与附加的约束规则一起共同作用于子类型。对于存在分级责任类型的情况，约束包括了对超类型的约束， 并使得委托方和责任方的映射显得多余。这样的一种想法可以用图2-13所示的模型来表达。需要特别强调的是，图2-12并非不正确。分级的责任类型是一种 非常好的责任类型子类型，因为施加于责任类型的约束规则仍然会适用于分级的责任类型，而其中的责任方和委托方的映射仍然得以继续保持，虽然它们需要从级别 映射关系中派生而来的。我倾向于采用图2-12的模型。分级的责任类型可能并不总是必须的，只要不违反模型，添加起它们来也很容易。图2-12还具有这样 的有点：它使得知识级和操作级的关系更加明确。
2.8操作范围
责任提供了一条描述团体之间如何相互联系的颇有价值的途径。责任的类型描述了它们所具有的关系的种类；通常还需要其它一些更详细的信息来具体阐明责任的内 涵。举例来讲，1997年，一名医生被聘用为肝脏方面的外科医生，其任务是为伦敦东南部地区实施20例肝脏移植手术；某医院的糖尿病治疗小组应红十字会的 要求，为马萨诸塞西部地区依赖胰岛素的糖尿病患者提供医疗服务。
诸如此类的详细说明称为责任的操作范围（如图2-14所示）。每个操作范围都定义了责任团体所担当的某部分责任。很难用抽象的方式列举操作范围的具体属性。因此，我们认为责任应当拥有大量的操作范围，每一操作范围是某种描述实际特征的子类型。
例：某位要在一年内负责伦敦东南部地区20例肝脏移植手术的外科医生，他参与一个雇用责任模型，该责任有一个协议范围：数量是20；肝脏移植方面的协议；地点是伦敦东南部地区。
例：糖尿病治疗小组和红十字会参与一个责任模型，其临床治疗范围如下：其中“观察概念”对象是以来胰岛素的糖尿病患者；地点是马萨诸塞州西部地区。
例：芳香咖啡机制造公司（ACM）与印度尼西亚咖啡出口公司（ICE）签订有每年3000吨爪哇咖啡和2000吨苏门答腊咖啡的合同。这可以用ACM与 ICE之间的责任模型来描述，其责任期限是一年，资源类型有两种：3000吨/年的爪哇咖啡和2000吨/年的苏门答腊咖啡。
在针对特定的组织使用操作范围时，需要识别其所具有的操作范围类型及属性。要用很抽象的方式来概括操作范围是非常困难的，但地点好像是一个各种操作范围都 具有的属性。操作范围俄的子类型如果很多的话，其间的继承关系可能会形成层次结构。在特别复杂的实例中，你可能会见到在知识级防止有操作范围类型，用来说 明哪些责任类型具有哪些操作范围类型。
2.9职位
通常，对于人的操作范围—-他们的职责（包括它们的诸多职责中的许多责任）—-已经预先在工作说明中做了具体的规定。当某人次去工作时，替代者将继承所有的职责。也就是说，职责与工作相关，而不是与人相关。
我们可以通过引进“职位”的概念（作为团体的第三个子类型）来处理这种情况（如图2-15所示）。隶属于工作的任何职责，无论谁拥有它，都只与职位相关。通过在人员和职位之间建立责任模型来表示人员占据该职位。具体来讲，就是某人在规定的时间内负责某个职位的各项职责。
例：Paul Smith是大容量产品开发小组的负责人，这可以通过设立大容量产品开发小组负责人这样一个职位的方式来描述，该职位和大容量产品开发小组（一个团体）之间有管理责任关系，而Paul Smith和该职位之间有另一个责任关系（聘用关系）。
不应该在所有时候都使用职位，因为它们引入了更多的间接联系，会增加操作级的复杂性。只有职位中体现了一些稳定的重要职责，而人员经常变换职位的情况下才使用职位的概念。对于模型中所有的职责都与某个特定的人相关的情况，就没必要再使用职位这一概念。