企业架构研究总结（43）——企业架构与建模之ArchiMate详述（下）

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的基本语法。这两种扩展之间的关系可总结以下：

• 聚合关系：因为对于架构的需求或目标都有其自身的生命周期，于是某一个具体需求或目标可能仅适用于某个稳定阶段，而另外的需求或目标则属于其余的稳定阶段。为了体现这种关系，稳定阶段概念元素能够聚合相关的需求或目标概念元素。
• 实现关系：从前面的例子能够看出，交付物概念元素与需求概念元素之间有着实现与被实现的关系，于是他们之间能够经过实现关系相联系。