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