2.7 关系模型元素
企业架构模型包括了各种概念元素以及他们之间的关系，这其中的概念元素已经在前面几节中进行了阐述，而这些概念元素之间的关系则是本节的叙述重点。虽然ArchiMate中具有种类繁多的概念元素，并且横跨企业中的多个领域，但是这些元素之间的关系经过抽象后却并不像想象中那么多，并且其中的大部分关系来源于诸如UML、BPMN等在业界被广泛使用的标准，因而掌握起来并不难。总体来说，ArchiMate中的关系元素可概括为如下三类：
- 结构关系：用于表示相同或不同类型的概念元素间结构的关系。
- 行为关系：用于表示行为元素之间的依赖关系。
- 其他类型关系：不属于以上两种类型的关系。
2.7.1 结构关系
结构关系有着强弱之分，这一点在通过关系链合并（即两个概念元素间如果没有直接关系连接，但是却可以通过一系列结构关系而间接相连，则他们之间可看作为具有一条间接结构关系，且此间接关系与关系链中关系强度最弱的结构关系相同）而获取概念元素之间的间接关系时尤为重要。本节将按照从强到弱的顺序对这些结构关系一一进行描述。
2.7.1.1 组合关系（Composition Relationship）
- 定义：用于表示一个对象是由其他若干组件组合而成。组合关系来源于UML，因而与同样来源于UML的聚合关系（Aggregation）相比，虽然两者都表示了包含与被包含的关系，但具有组合关系的容器对象和组件对象具有更强的联系：一个对象能且只能作为一个组成部分而被组合到一个容器对象之中。
- 表示图符：
-
实例：在本案例中，“财务应用”包含了三个子组件，分别为：“会计组件”、“计费组件”和“支付组件”。
2.7.1.2 聚合关系（Aggregation Relationship）
- 定义：用于表示一个对象组织包含了其他若干对象。与组合关系类似，聚合关系也来源于UML。不过与组合关系不同的是，聚合关系没有那么强的约束关系，即一个对象可以通过聚合关系而从属于两个或两个以上的容器对象。
- 表示图符：
-
实例：在本案例中，“车辆保险”这一产品包含了“更改条件”和“提交索赔”这两个业务服务，但这两个业务服务并不会因为该产品的退出而消失，亦即具有不同的生命周期。
2.7.1.3 分配关系（Assignment Relationship）
- 定义：分配关系用于在主动性结构元素（业务角色或应用组件等）和表示其行为的行为元素之间，或在业务参与者与其所扮演的业务角色之间创建联系。
- 表示图符：
-
实例：本案例描述了两种分配关系：其一是“支付接口”与“支付服务”之间的支配关系，他表示了需要通过“支付接口”来获取“支付服务”；另外一个是“财务应用”与“支付功能”之间的支配关系，他表示了“财务应用”这一主动性结构元素能够执行“支付功能”这一行为。
2.7.1.4 实现关系（Realization Relationship）
- 定义：实现关系用于将逻辑实体与用于实现他的更加具体的实体连接在一起，从而体现两者之间的实现与被实现关系。实现关系可以存在于运行的情景之下（例如，业务流程或业务功能实现业务服务），也可以存在于设计-实现这一情景中（例如，数据对象实现业务对象，或制品实现应用组件）。在ArchiMate 2.0的动机扩展中，实现关系的意义有所拓宽，因为在此扩展中仅有逻辑概念，而并不像核心元素中那样具有从逻辑到现实的跨越，所以在这一扩展中，实现关系除了具有原来的逻辑到现实这一方向外，还具备了仅在逻辑维度上逐步细化方向。动机扩展为实现关系的使用增加了如下三个方面的情境：
- 目标可被原则、需求或约束所实现。
- 原则可被需求或约束所实现。
- 需求可被用于表示具体系统的概念元素所实现。
- 表示图符：
-
实例：本案例展示了实现关系所适用的两种情景：从运行角度来说，“财务应用”这一应用组件实现了“计费服务”；从设计-实现这个角度来说，数据对象“计费数据”实现了业务数据“单据”。
2.7.1.5 使用关系（Use by Relationship）
- 定义：使用关系被用来描述流程、功能或交互对于服务的使用，以及业务角色、应用组件或合作集合对各类接口的访问。从其表示图符来看，使用关系借用了UML中依赖关系的表示图符，不过两者的含义却不尽相同。
- 表示图符：
-
实例：在本案例中，名为“更新客户信息服务”的应用服务被“变更地址流程”这一业务流程所使用，而隶属于“客户关系管理系统”的“客户关系管理接口”则被业务角色“前台职员”所使用。
2.7.1.6 访问关系（Access Relationship）
- 定义：用于描述行为元素对业务或数据对象的访问。访问关系具有方向性，其图符连线上的箭头指示了信息流动的方向（如果箭头指向业务或数据对象，则表示行为元素对其执行写操作，反之则表示行为元素对业务或数据对象执行读操作），而如果图符没有箭头指向则表示行为元素与业务或数据对象之间同时具有读和写的关系。
- 表示图符：
-
实例：在本案例中，“创建发票”业务流程创建了业务对象“发票”，而业务流程“发送发票”则对此业务对象执行了读取操作。
2.7.1.7 影响关系（Influence Relationship）
- 定义：影响关系描述了某些动机元素对其他动机元素具有正面或负面的影响。影响关系反映了现实中在决策阶段需要进行权衡利弊的情景，处在这条关系两端的元素并没有很强的依赖或实现关系，因而并不能因为影响源元素对受影响的元素有正面影响就把其当作实现受影响元素的必要条件，同样也不能因为影响源元素对受影响的元素有负面影响就在受影响元素的实现之中将其排除。
- 表示图符：
-
实例：本案例展示了用来实现“提高产品组合管理”这一目标的两个需求所产生的利弊权衡情形。对于“指派个人助理”这一需求来说，他对“降低人员工作量”这一目标有着负面影响（两者之间的影响关系标注了两个“-”），但他对“改善客户满意度”却有着非常正面的影响（影响关系被标注了两个“+”），同理可知，此需求对于“系统必须面客户”这一原则也有着非常负面的影响。
2.7.1.8 关联关系（Association Relationship）
- 定义：用于描述对象之间不同于以上各种特定关系的联系。关联关系来源于UML，因而与其所定义的一样，主要用来描述业务或数据对象之间不属于组合、聚合以及特化（继承）的关系。除此之外，在ArchiMate中关联关系还主要用来联系信息元素与其他种类的元素，例如业务对象与表现方式、表现方式与含义等。
- 表示图符：
-
实例：在本案例中，业务对象“保险政策”在“客户”和“参保对象”这两个业务对象之间具有关联关系，并且“保险销售服务”与“受保”这一价值元素之间也有着关联关系。
2.7.2 行为关系
2.7.2.1 触发关系（Triggering Relationship）
- 定义：用于表示流程、功能、交互或事件之间的时序或因果关系。
- 表示图符：
-
实例：本案例描述了从“保险申请”事件触发“接收申请”业务流程开始到“申请批准”事件的产生为结束的整个过程。
2.7.2.2 流动关系（Flow Relationship）
- 定义：用于描述流程、功能、交互或事件之间对信息或价值的交换或转移。
- 表示图符：
-
实例：在本案例中，业务功能“日程安排”将索赔诉求的处理安排信息传递给业务功能“索赔评估”，而后者最后会将评估结果转移给“理赔”这一业务功能，从而进行对于索赔诉求的最终处理。
2.7.3 其他类型关系
2.7.3.1 分组关系（Grouping）
- 定义：用于根据一系列对象的通用性质来对他们进行分类组织。分组关系与UML中的“包”概念相类似，他们都可用来对各种对象进行分类组织。与组合和聚合关系不同，分组关系中并没有一个容器性对象，所有对象都被平等地组织在一起。
- 表示图符：
-
实例：在本来中，“财务管理”分组中包含了此领域中的相关业务对象：“单据数据”、“账户信息”和“债务信息”。
2.7.3.2 连接关系（Junction）
- 定义：用于连接相同类型的行为关系。
- 表示图符：
-
实例：在本案例中，“访问申请”业务流程之后通过连接关系对该业务流程之后可能出现的两种情况进行了描述：如果申请被接受，则进入“通知接受申请”业务流程；如果申请被否决，则进入“通知拒绝申请”业务流程。由此可见，本案例中的连接关系描述了流程之间逻辑或的关系，但这并不代表连接关系只能表示这一种逻辑关系，建模人员甚至可以通过ArchiMate扩展规则对连接关系进行特化，从而能够清楚地表达各种逻辑关系。
2.7.3.3 特化关系（Specialization Relationship）
- 定义：用于表示一个对象是另外一个对象的特殊化对象。此关系来源于UML的特化（继承）关系，但在ArchiMate中此关系所涉及的概念元素却不仅仅是业务或数据对象。任何一个概念元素的实例均可为同类型概念元素的其他实例的特化。
- 表示图符：
-
实例：从本案例中可以看出，业务流程“处理旅游保险”和“处理行李保险”都是业务流程“处理保险”的具体特化。
2.8 ArchiMate扩展机制
通过前面几节的介绍，我们对ArchiMate 2.0中定义的概念元素以及他们之间的关系有了应该有了一定的了解，但这并不代表这些元素和关系就足够应对一切情况，因而基于如下的原因，ArchiMate需要有一定的扩展机制来应对现实使用过程所面对的具体问题：
- 由于ArchiMate面向的是企业架构模型，且此种模型的抽象层次较高，因而在实际使用过程中一定会遇到ArchiMate标准所没有精确定义的情况。所以ArchiMate需要通过扩展来应对具体领域中的问题。
- 企业中可能已经存在了大量的具体领域内的模型，而企业架构模型也只是在抽象层次上与这些具体领域模型的描述内容有所区别，但由于他们都是对“企业”这一客观对象进行建模，所以他们之间应该是相互融合，而不是相互割裂的。为了达到这种融合，采用ArchiMate所建立的模型需要经过扩展来兼容各具体领域模型。
- 模型的重要目标之一就是辅助分析决策，虽然ArchiMate在不同领域之间建立了联系，但缺乏足够的细节来支持针对具体领域模型的分析方法。
- 模型的重要目标还包括促成干系人之间的无障碍沟通，但由于不同领域、不同背景的干系人其使用的沟通语言也不尽相同，因而只有通过扩展ArchiMate才能帮助干系人之间的沟通。
由此可见，ArchiMate语言是一种核心语言，需要通过扩展来联系原本分离的具体领域内的模型，因而我们不能把他看成诸如UML这样的包罗万象的语言。实际上，ArchiMate的初衷也并不是要从头建立一种新的语言（那样只会带来新的学习曲线以及由此产生的抵制），而是对各种领域标准和最佳实践进行抽象后得到共通的部分，并以面向服务架构（SOA）概念为基础，将抽象出的各领域的通用联系起来，最后辅以扩展机制来适应各种具体情况。这一语言扩展规则可以总结为如下两点：
- 增加属性：前面介绍的各种概念元素只给出其定义而并没有设置其属性，因而建模人员可以根据需要为各种概念元素添加适当的属性。例如，如果要对企业进行性能分析，就需要为各个概念元素添加诸如服务时间、吞吐量这样的属性。由于属性的添加具有一定的背景性，即为了不同的目的所添加的属性也不尽相同，而概念元素却具有更强的稳定性，因而保证概念元素与属性的独立性是必要的。为了解决这一问题，ArchiMate扩展规则建议采用属性配置的方式来记录概念元素和特定属性的对应关系，并且这一映射配置的存储将独立于模型的存储。
- 进行特化：由于ArchiMate中的概念元素都是由各领域建模语言以及最佳实践抽象而来，因而也可以通过特化（继承）的方式将其转换回去，从而将各领域内特有的概念元素添加到ArchiMate之中。ArchiMate 2.0中列举了如下实例：
2.9 跨领域关联
通过前面对于概念元素以及他们之间的关系的介绍，我们可以在高抽象层次上创建企业架构模型，并可以通过扩展机制来适应实际应用过程中遇到的各种问题，不过ArchiMate所不同于具体领域内建模语言的根本还是在于它能将各个分立的领域联系起来，从而建立具有一致性的模型。前面已经提到过，在ArchiMate中跨领域的联系的基础是面向服务架构（SOA），不过为了达成业务与信息技术之间的协调整合，通常来讲，还需要注意其他的概念元素间关系，而本节将针对这些跨领域关联的常用模式进行归纳总结。
2.9.1 业务-信息技术协调整合
在上图中，包含在“业务层”分组之内的是具有跨领域关联关系的各个业务领域概念元素，而分组之外的则是与之相关的信息技术领域（应用层和技术层）内的概念元素。如图所示，业务与信息技术之间的跨领域关联关系主要包括了如下几个方面的内容：
- 使用关系：业务行为元素（业务流程、功能、交互）可以使用应用服务，而业务参与者和业务角色除了可以使用应用服务外还可以对应用接口进行使用。
- 实现关系：数据对象与业务对象之间具有实现关系，而这条关系说明了数据对象是相关业务对象的一个电子化表现方式。
- 分配关系：
- 应用组件与业务流程、功能、交互和服务之间具有分配关系，用以体现业务行为元素是在应用组件支持下的自动化行为，而对于非自动化行为来说，各行为元素和应用组件之间应该采用使用关系。需要注意的是，ArchiMate 2.0中对于涉及到分配关系的跨领域关联的描述中还包括了应用接口和业务服务之间的关系，不过就笔者的理解来说这条关系应该不是一条直接关系，而是将相关关系链（应用接口与应用组件之间具有组合关系，而应用组件可以通过分配关系关联到业务服务，而在这条关系链中由于分配关系优先级最低，因而应用组件和业务服务之间具有间接的分配关系）进行转换而得的间接关系，因为应用接口是应用组件对外提供服务的渠道，同时也是应用组件的一个组成部分，因而对于通过应用接口使用应用服务的业务服务或其他业务行为元素来说，将应用接口直接“分配”给他们是有待商榷的。
- 应用组件与位置之间的分配关系指明了应用组件的空间位置。
- 与前一点相类似，数据对象与位置之间的分配关系亦指明了数据对象，这个业务对象的电子化表现方式，在空间中的位置。
- 技术层各概念元素中的节点、网络、通信路径和制品与位置之间也具有分配关系，分别用以表示他们在空间中的位置。
- 聚合关系：产品和应用服务之间具有聚合关系，这说明应用服务可以作为产品的一个部分而直接提供给客户。同理，处于技术层中的基础设施服务也可以通过聚合关系而成为产品的一个组成部分。
2.9.2 应用-技术协调整合
上图展示了应用层和技术层之间发生跨领域关联的各种概念元素，以及他们之间的关系。这些关系主要包括如下几个方面的内容：
- 使用关系：
- 应用组件和应用功能可以使用技术层面的基础设施服务。
- 应用组件可以使用技术层面的基础设施接口。
- 实现关系：
- 数据对象与制品之间的实现关系体现了逻辑上的数据对象与物理上的存储或部署对象之间的关系。例如，数据对象可以存储在一份数据文件之中。
- 同理，应用组件和制品之间的实现关系也体现了逻辑上的应用或应用组件与物理上的可执行程序文件之间的关系。
2.9.3 动机扩展-核心协调整合
动机扩展的目标是对采用核心概念元素所建模型的原因进行描述，因而这一扩展所包含的各个概念元素与核心概念元素之间有着密不可分的关联。需要注意的是，ArchiMate 2.0（第10.4节Cross-Aspect Dependencies）已经明确指出：动机扩展中仅有需求和约束元素可以通过实现关系与核心概念元素发生直接关联，不过在其中的图72（本文中的图 203）中又为动机扩展元素与价值概念元素之间添加了一条影响关系，由于影响关系的定义只涉及到在动机概念元素之间描述权衡利弊的情况，因而其图72种所描绘的动机扩展元素与价值概念元素之间的影响关系不应该是一条间接关系（虽然两者之间可以通过关系链相连，不过按照合并规则最后获得的应该是关联关系而不是影响关系），而应该是一条直接关系。此外， 干系人与业务参与者之间的分配关系也应该是直接关系。因此，笔者认为上图中所表示的各条关系中，直接关系包括了需求、约束和核心概念元素之间实现关系、各动机扩展概念元素与价值之间的影响关系，以及干系人与业务参与者之间的分配关系。动机扩展与核心元素之间的关联关系主要包括如下内容：
- 影响关系：各个主要的动机概念元素（驱动力、评估、目标、原则、需求和约束）与业务层的概念元素“价值”之间具有影响关系，亦即这些表述建模动机的概念元素对于业务价值有着正面的或负面的影响，从而体现了不同动机之间的权衡关系。
- 实现关系：绝大部分核心概念元素（除了含义和价值等概念元素）可以实现动机扩展中的需求和约束这两个概念元素。需要注意的是，由于需求概念元素与价值概念元素之间有着影响关系，因而根据关系合并规则，那些用来实现需求和约束的核心概念元素与价值概念元素之间有着间接的影响关系。
- 分配关系：干系人概念元素所指代的是对架构产生的结果具有利益关系或对其进行关注的个人、团队或组织的类别，其并不特指某个特定的参与者个体或组织，所以为了体现他们之间的关联就需要通过分配关系将他们联系起来，而这与业务角色和业务参与者之间的分配关系也是相似的。
- 关联关系：干系人与价值和含义之间分别具有一条关联关系，不过从前面的叙述中我们可知，这两条关联关系应该是通过合并关系链而得的间接关系，而不是直接关系。不过从关联关系的定义来看，他们之间建立直接的关联关系也无不可，因而需要根据建模实际情况来进行判别。
2.9.4 实施和迁移扩展-核心协调整合
实施和迁移扩展的目标是对企业架构从设计走向实现的这一过程进行建模，因而其所包含的各种概念元素与核心概念元素之间也有着密不可分的关系，这些关系的主要内容包括：
- 分配关系：
- 业务角色与工作包之间具有分配关系，用以表示参与到工作包实施中的个人或团队所担负的职责。
- 位置与交付物、工作包之间具有分配关系，用以表示他们在空间中的位置。
- 聚合关系：稳定阶段描述了架构在一定期间内的状态，而为了对此稳定阶段包括了哪些架构的部分进行描述，我们需要通过聚合关系来联系稳定阶段与相关的核心概念元素。
- 关联关系：差距用于描述两个稳定阶段之间发生变化的架构部分，因而需要通过关联关系来对差距和代表了发生变化的架构部分的核心概念元素创建联系。
- 实现关系：交付物与绝大部分概念元素之间具有实现关系。
2.9.5 实施和迁移扩展-动机扩展协调整合
严格来说，实施和迁移扩展与动机扩展之间并没有直接的关联，而都是通过经由核心概念元素的关系链而进行关联。例如，交付物可以实现诸如应用组件、业务流程这样的核心元素，而后者又可以用来对动机扩展中的目标或需求进行实现。不过在实际建模过程中，在这两个扩展之间创建直接关联也有助于更加清晰地体现企业架构实现与动机之间的关系，且也符合ArchiMate的基本语法。这两种扩展之间的关系可总结如下：
- 聚合关系：由于对于架构的需求或目标都有其自身的生命周期，因而某一个具体需求或目标可能仅适用于某个稳定阶段，而另外的需求或目标则属于其他的稳定阶段。为了体现这种关系，稳定阶段概念元素可以聚合相关的需求或目标概念元素。
- 实现关系：从前面的例子可以看出，交付物概念元素与需求概念元素之间有着实现与被实现的关系，因而他们之间可以通过实现关系相联系。