除了第4章中概述的通用元素之外,ArchiMate语言定义了一组核心通用关系,每个关系都可以连接一组预定义的源和目标概念(在大多数情况下是元素,但在少数情况下也是其他关系)
。其中许多关系都“超负荷的”; 即,它们的确切含义取决于它们连接的源和目的地概念。
关系分类如下(见图19):
结构关系,模拟相同或不同类型的静态结构或概念组成
依赖关系,它模拟元素如何用于支持其他元素
动态关系,用于模拟元素之间的行为依赖关系
其他关系,不属于上述类别之一
图19:关系概述
每个关系都只有一个'from'和一个'to'概念(元素,关系或关系连接符)作为端点。以下限制适用:
两个关系之间不允许任何连接
与关系连接器连接的所有关系必须属于同一类型
连接两个元素,并通过关系连接器连接的相同类型的关系链仅在这两个元素之间的相同类型的直接关系有效时才有效
连接元素与第二关系的关系只能是聚合,组合或关联; 聚合或组合仅对从第二个关系的复合元素有效
为了便于阅读,本文档中的元模型数字并未显示该语言中所有可能的关系。5.6节描述了一组推导规则,用于导出模型中元素之间的间接关系。在两个相同类型的元素之间始终允许聚合,组合和特化关系,并且在任何两个元素之间以及任何元素和关系之间始终允许关联。附录B给出了允许关系的确切规范。
5.1结构关系
结构关系代表了架构中的“静态”连贯性。构成概念(关系的'从'侧)始终是一个元素;
组合概念(关系的'到'侧)在某些情况下也可能是另一种关系。
作为本节中提出的图形符号的替代,结构关系也可以通过在组成元素内嵌套组合概念来表达。但请注意,如果这些元素之间允许多个结构关系,这可能会导致模糊模型。
5.1.1构成关系
组合关系表示元素由一个或多个其他概念组成。
组合关系受到UML类图中组合关系的启发。与聚合关系相反,组合概念可以是仅一种组合的一部分。
在同一元素类型的两个实例之间始终允许组合关系。
除此之外,元模型还明确定义了可以通过组合关系连接的其他源和目标元素。
图 20:组成符号
通常对组成关系的解释是,源元素的整体或部分是由目标元素的整体组成的。
示例
示例2显示了表示"财务处理"功能由三个子功能组成的两种方式。
示例 2:组合物
5.1.2聚合关系
聚合关系表示元素将许多其他概念分组。
聚合关系受到UML类图中聚合关系的启发。与组合关系相反,对象可以是多个聚合的一部分。
在同一元素类型的两个实例之间始终允许聚合关系。
除此之外,元模型还明确定义了可以通过聚合关系连接其他源和目标元素。
图 21:聚合表示法
聚合关系的通常解释是源元素的全部或部分聚合整个目标元素。
示例
示例3显示了两种表示“客户文件”汇总“保险单”和“保险索赔”的方式
例 3:聚合
5.1.3分配关系
分配关系表示责任分配,行为表现或执行。
赋值关系将主动结构元素与由它们执行的行为单元,具有由它们履行的业务角色的业务角色以及具有技术对象的节点相关联。例如,它可以将内部主动结构元素与内部行为元素,与服务的接口或具有工艺对象的节点相关联。附录B中列出了全套允许的关系。
图 22:赋值表示法
在3.4节描述的ArchiMate框架中,它始终指向从主动结构到行为,从行为到被动结构。ArchiMate
2.1规范中以及之前显示关系两端黑球的非方向符号仍然被允许但不赞成使用。
与所有结构关系一样,也可以通过嵌套模型元素来表达赋值关系。上述方向也是筑巢的方向; 例如,执行该角色的业务主角内部的业务角色,执行该功能的应用程序组件内的应用程序功能,或存储该角色的节点内的工件。
赋值关系的通常解释是为源元素的全部或部分分配整个目标元素。这意味着,如果将两个主动结构元素分配给同一行为元素,则它们中的任何一个都可以执行完整行为。如果需要两个主动结构元素来执行行为,则可以使用分组元素或结点(参见第5.4.3节),如果这些元素的组合具有更实质和独立的特性,则协作将是正确的表达这一点的方式。
示例
示例4包括表达分配关系的两种方式。Finance主动结构元素被分配给事务处理功能,并且支付接口被分配给支付服务。
例 4:分配
5.1.4实现关系
实现关系表明,一个实体在创建、完成、维护或操作中起着至关重要的作用。
实现关系表明,实体(“什么”或“逻辑”)是通过更具体的实体(“如何”或“物理”)来实现的。实现关系用于建模运行时实现;例如,业务流程实现业务服务,数据对象实现业务对象、工件实现应用程序组件或核心元素实现动机元素。
图 23:实现表示法
实现关系的通常解释是源元素的全部或部分实现目标元素的整体。这意味着,如果两个内部行为元素与同一服务有实现关系,那么它们中的任何一个都可以实现完整的服务。如果需要实现两个内部行为元素,则可以使用分组元素或连接(参见5.4.3节)。对于对实现某一要素的贡献较弱的类型,应使用影响关系(见第5.2.3节)
示例
示例5说明了使用实现关系的两种方法。交易处理功能实现了计费服务;
“ 开票数据”业务对象由“纸发票”表示形式实现。
例 5:实现
5.1.5 结构关系的语义
结构关系 描述了源方面的元素包含,分组,执行或实现关系的目标方面的概念。可以将结构关系可传递地应用于源元素的(可能未建模)部分。以下是这些语义如何工作的一些示例:
部分的组成和聚集关系也适用于整体
例如,如果A的一部分聚合B,则A本身也被视为聚合B。相反,如果A聚合B,则可以解释为A聚合B的某些部分。
行为元素的分配关系也适用于主动结构元素
例如,如果将业务角色A分配给业务流程B,则A的一部分可以执行B。相反,如果将A的一部分分配给B,则A本身也被认为分配给B。
与外部行为元素的实现关系也适用于内部行为元素
例如,如果服务B是由进程A实现的,则B可以由A的一部分实现。反之,如果A的一部分实现了B,则A本身也被认为是实现B。
例
在示例6的左侧,通过业务人员A(可能是部门)中的整个业务角色B(可能是部门)通过A内部的一些未建模元素组成。在右侧的示例中,业务流程A完全是通过A内部的一些未建模元素来实现业务服务B。
5.2依赖关系
依赖关系 描述元素如何支持或被其他元素使用。区分了四种依赖关系:
服务关系表示控件依赖关系,由实线表示。
访问关系表示数据依赖关系,由虚线表示。
影响关系是最弱的依赖关系,用于模拟动机元素如何受其他元素的影响。
请注意,尽管这些关系的表示法类似于UML中依赖关系的表示法,但这些关系在ArchiMate表示法中具有不同的含义,并且(通常)指向相反的方向。这一方法的一个优点是,它产生具有方向性的模型,,其中大多数[2]表示这样的支持、影响、服务或实现对客户机/用户/业务的依赖关系点“向上”,这是因为在第C.1.11节中的分层视点示例中可以看到。这个方向,特别是服务关系的另一个原因是它从“调用者”或“发起者”摘要中提取,因为服务可以主动地或反应地传递。传送方向总是相同的,但是交互的起点可以在任一端。UML的依赖关系通常用来表示后者,表明调用方取决于调用的某些操作。然而,为了建模这种类型的倡议,Archimate语言提供了触发关系(第5.3.1节),其可以被解释为动态(即,时间)依赖性。类似地,使用流关系来模型如何(通常信息)从一个元素转移到另一个元素,这也是动态的依赖关系。
5.2.1服务关系
服务关系模型元素将其功能提供给另一个元素。
服务关系描述了行为或主动结构元素提供的服务或接口如何为其环境中的实体提供服务。此关系适用于行为方面和主动结构方面。
与此标准的早期版本相比,此关系的名称已从“使用”更改为“服务”,以更好地反映其使用主动动词的方向:服务为用户服务。这种关系的意义没有改变。'used
by'标识仍然允许但不建议使用,并在标准的将来版本中删除。
图 24:服务表示法
服务关系的通常解释是,源元素的整体服务(由目标元素使用)。这意味着,如果两个服务提供相同的内部行为元素,那么这两个服务都是必需的。如果两个服务是替代解决方案,并且内部行为元素只需要其中一个,则可以使用一个或连接(参见5.4.3节)。
示例
例6说明了服务关系。支付界面为客户提供服务,而支付服务则为该客户的支付发票流程提供服务。
例 7:服务
5.2.2访问关系
访问关系模拟了行为元素和主动结构元素对被动结构元素的观察和行为能力。
访问关系表示流程,功能,交互,服务或事件与被动结构元素“做某事”; 例如,创建新对象,从对象读取数据,写入或修改对象数据,或删除对象。该关系还可用于指示对象仅与行为相关联;
例如,它模拟事件附带的信息,或作为服务的一部分提供的信息。箭头(如果存在)指示信息流的方向。(访问关系不应与UML依赖关系混淆,后者使用类似的表示法。)
注意,在元模型级别,关系的方向总是从主动结构元素或行为元素到被动结构元素,尽管符号可以指向另一个方向以表示“读取”访问,并且在两个方向上表示读写访问。使用推导关系访问时必须小心,因为关系上的箭头与其方向性无关。
图 25:访问符号
或者,可以通过将被动结构元素嵌套在访问它的行为或主动结构元素内来表示访问关系; 例如,将数据对象嵌套在应用程序组件中。
访问关系的通常解释是源元素访问整个目标元素。这意味着,例如,如果相同的内部行为元素访问两个被动结构元素,则需要这两个被动结构元素。例如,如果两个被动结构元素是替代信息源,并且内部行为元素只需要其中一个,则可以使用一个或一个结(见第5.4.3节)。
示例
示例8 说明了访问关系。“ 创建发票”子流程写入/创建“ 发票”
业务对象;“ 发送发票”子流程将读取该对象。
例 8:访问
5.2.3影响关系
影响关系 表示一个要素影响某个动机要素的实施或迁移。
影响关系用于描述某些架构元素影响动机元素的实施或迁移。通常,在一定程度上实现了动机元素。例如,始终如一地满足“为客户提供服务”的原则将有助于实现“增加市场份额”的目标。换句话说,该原则有助于实现目标。反过来,为了实现“为客户提供服务”这一原则,在某些面向客户的应用程序组件上强加“24x7
Web可用性”的要求可能会很有用。这可以被建模为对该原理有影响的要求,以及作为反过来影响要求的应用程序组件。通过影响关系一致地建模这些依赖关系,产生了可追踪的激励路径,解释了为什么(在此示例中)某个应用程序组件有助于企业“增加市场份额”的目标。这种可追溯性支持测量企业架构的结果,并提供有价值的信息,例如,更改影响评估。
除了这种“垂直”使用贡献之外,从核心要素向上到要求和目标,这种关系还可以用来模拟激励要素之间的“横向”贡献。该案例中的影响关系描述了某些激励因素可能影响(实现或实施)另一个激励因素。通常,在一定程度上实现了动机元素。某些其他元素的影响可能会影响这个程度,具体取决于其他元素本身的满足程度。例如,实现提高客户满意度的目标的程度可以通过参与市场访谈的满意客户的百分比来表示。例如,这个百分比可能受到提高公司声誉的目标的影响;
即 更高程度的改进可以提高客户满意度。另一方面,裁员的目标可能会对公司声誉造成负面影响; 也就是说,更多的裁员可能导致公司声誉的降低(甚至降低)。因此(间接地),提高客户满意度的目标也可能受到负面影响。
实现关系应该用于表示对目标的存在或实现至关重要的关系,而影响关系应该用于表示对目标对象的存在或实现不重要的关系。例如,代表施工人员的商业行为者可能意识到建造建筑物的目标,并且要求将已经足够的熟练建筑工人添加到已经足够的工作人员可能会影响建筑物的建造目标,但也实现了打开的另一个目标。特定日期的建筑物。此外,影响关系可以用来模拟:
一个元素对某个动机元素的实现或实现有积极贡献的事实,或者
一个因素对这种成就产生负面影响 - 即阻止或抵消这一事实的事实
属性可用于指示影响的符号和/或强度。可能的属性值的选择留给建模者; 例如,{++,+,0,
- , - }或[0..10]。默认情况下,影响关系会使用未指定的符号和强度来模拟贡献。
图 26:影响符号
示例
示例9 说明了如何使用影响关系对相同需求“ 分配个人助理”
的不同影响进行建模。这对“ 减少员工的工作量”具有积极的影响,而对“ 降低成本”则具有很大的消极影响。
例 9:影响
5.2.4 关联关系
关联关系 表示未指定的关系,或未由另一ArchiMate关系表示。
始终在两个元素之间或在关系和元素之间允许关联关系。
当绘制第一个高级模型时,可以使用关联关系,其中最初以通用方式表示关系,之后对其进行细化以显示更具体的关系类型。在元模型图片中,明确显示了关联关系的某些特定用途。关联默认情况下是无向的,但可以是有向的。另见5.2.5
节。
图 29 :关联符号
例
示例10 说明了合同与该合同所引用的两个业务对象之间的两个定向关联关系。它还显示了流程关系与该合同之间的关联,以指示在两个功能之间传递的信息的种类。
示例 10 :关联
5.2.5 依赖关系的语义
依赖关系 描述目标元素的一部分对源元素的一部分具有依赖。尽管两个元素之间存在依赖关系,但这并不一定意味着这适用于任何结构关系所定义的元素的所有部分。
此语义使您可以在较高级别(已删除细节)上对依赖关系进行建模,而不必在更详细的级别上暗示特定的依赖关系。例如,这意味着:
在服务关系中,内部行为元素的某些部分由外部行为元素的某些部分提供服务;例如,如果业务服务A为业务流程B提供服务,则A的某些未建模子服务可能会为B的未建模子流程提供服务
在访问关系中,行为元素的某些部分访问被动结构元素的某些部分;例如,如果应用程序功能A访问数据对象B,则A的某些未建模子功能可能会访问B的未建模部分
在影响力关系中,核心要素的某些部分影响动机要素的某些部分;例如,如果应用程序组件A影响需求B,则A的某些未建模部分可能会影响B的某些未建模部分
在关联关系中,一个元素的某个部分与另一个元素的某个部分相关;如果 是定向的,则只能在该方向的推导中使用(请参见5.7
节)
例
在示例11 的左侧,业务流程B的一部分由应用程序服务A的一部分提供服务。在右侧的示例中,业务流程B的一部分访问(读取)业务对象A的一部分。
示例 11 :依赖关系的语义
5.3 动态关系
动态关系描述了体系结构中元素之间的时间依赖性。区分两种类型的动态关系:触发和流。
5.3.1触发关系
触发关系描述了元素之间的时间或因果关系。
触发关系用于模拟过程中行为元素的时间或因果优先级。触发关系的通常解释是,源元素应该在目标元素开始之前完成,尽管也允许较弱的解释。请注意,这不一定表示一个行为元素主动启动另一个行为元素;绿灯变绿也会触发汽车通过交叉口。
图 27:触发符号
示例
示例12表示出了触发关系主要用于对(子)过程和/或事件之间的因果依赖性进行建模。
例 12:触发
5.3.2流关系
流关系表示从一个元素到另一个元素的转移。
流关系用于对行为元素之间的信息,商品或货币流进行建模。流动关系并不意味着因果关系。
图 28:流表示法
示例
示例13显示了索赔评估功能,该功能将关于索赔的决定转发给索赔结算功能。为了确定索赔的评估顺序,索赔评估利用从计划功能收到的计划信息。
例 13:流程
5.3.3 动态关系的语义
触发关系和流关系的语义不同。触发关系遵循与结构关系相同的语义(第5.1.5
节)。从A到B的触发关系表明B中的所有内容都以A的一部分开头。例如,当A和B是业务流程时,这意味着业务流程B中的所有步骤都是在A的一部分发生之后执行的,但是B中的某些或所有步骤都已发生之后,A中的步骤才可能发生。希望这样做的建模小组可以对ArchiMate模型施加更强的触发解释(B中的所有内容都在A中的所有内容之前)。
流关系遵循与依赖关系相同的语义(请参阅第5.2.5 节)。从A到B的流关系表明A的全部或部分将某些信息(例如信息)转移到B的全部或部分。
5.4其他关系
5.4.1专业化关系
专业化关系表示元素是另一种元素的特定种类。
专业化关系受到UML类图中泛化关系的启发,但适用于专业化更广泛的概念。专业化关系可以将概念的任何实例与同一概念的另一个实例相关联。
在同一元素的两个实例之间始终允许专业化关系。
图 29:专业化关系符号
或者,可以通过将专用元素嵌套在通用元素内来表示专业化关系。
示例
例14说明了过程的专业化关系的使用。在这种情况下,Take
Out Travel Insurance和Take Out Luggage Insurance流程是更通用的Take
Out Insurance流程的专业化。
例 14:专业化
5.4.2 其他关系的语义
专门化关系的语义是整个通用元素都由专门化元素来专门化。
5.5 关系连接器
5.5.1 连接点
连接不是与本章中描述的其他关系相同的实际关系,而是关系连接器。
结点 用于连接相同类型的关系。
连接在许多情况下用于连接相同类型的关系。如果允许在两个概念之间使用这种类型的直接关系,则仅允许在两个概念之间使用具有连接这种类型的关系的结的路径。简而言之,您不能使用结点在概念之间创建本来不允许的关系。
一个连接可以具有多个传入关系和一个传出关系,一个传入关系和多个传出关系,或多个传入和传出关系(后者可以视为两个连续连接的简写)。
可以与结点结合使用的关系是所有动态关系和依赖关系,以及分配和实现。结点用于明确表示所有元素必须一起参与关系(或结点),或者至少一个元素参与关系(或
结点)。的或结可用于表达包括两个端点和异或的条件下,这可能是由建模器通过命名结,以反映其类型来指示。允许省略导致结点的关系的箭头。
图 33 :结符号
用于触发关系的连接类似于BPMN中的网关,以及UML主动图中的分支和联接(没有关联的语义)。它们可用于建模高级流程。可以将标签添加到结点的传出触发关系中,以指示适用于该关系的选择,条件或防护。这样的标签仅仅是非正式的指示。尚未为这些关系定义正式的,可操作的语义,因为诸如BPMN和UML之类的实现级语言在其执行语义上有所不同,并且ArchiMate语言不想过分地限制到此类语言的映射。
例子
在 示例15中,模型中的and结点用于表示“销售”和“财务”业务功能共同实现“发票”业务服务。
示例 15 :(和)连接点
在 示例16中,“ 或” 连接用于表示一个选择:业务流程“评估请求”触发“接受请求”或“拒绝请求”。(通常将两种独立的触发关系解释为“评估请求”触发其他两个业务流程,一种是从“评估请求”到“接受请求”,另一种是从“评估请求”到“拒绝请求”。)
示例 16 :(或)连接点
5.6 关系汇总
表3 概述了ArchiMate关系及其定义。
表 3 :关系
5.7 关系的推导
在ArchiMate语言中,您可以基于建模的关系推导模型中元素之间的间接关系。这样就可以从与在某个模型或体系结构视图中显示无关并支持影响分析的中间元素中抽象出来。进行此类推导的精确规则在附录B
中指定。
例
在 示例17中,假设目标是从模型中的应用程序功能,子功能和服务中抽象出来。在这种情况下,可以从“财务申请”到“发票和收款”业务流程推导间接服务关系(右侧的红色粗箭头)(从链分配–组成–实现–服务)。
示例 17 :从关系链中推导
关系的推导旨在作为创建详细模型摘要的一种方式。这是一种在模型中删除(从中提取)细节的方法,同时仍然可以进行有效的“声明”。因此,推导总是意味着从更多细节到更少细节。与其他建模语言相比,该机制是ArchiMate语言的独特属性之一。
该语言允许建模者直接创建必然是有效的推导关系的关系,而在模型中不可用推导的成分。这些关系(例如,应用程序组件和应用程序服务之间的实现关系)假定所需的成分(例如,存在推导关系所需的应用程序功能);但是,这些缺失的元素无需显式建模,并且可以将推导的关系用作未推导的关系。因此,建模者可以自由选择所需的详细程度。
因为推导的本质是简化或汇总,所以不能用来推断更多细节。例如,可以对从应用程序组件到应用程序服务的实现关系进行建模,但是从中不能得出关于该推导的确切来源的结论(例如,哪些功能实现了哪些服务)。
这是建模人员应在设计过程中添加的信息:可以通过详细说明推导的关系(在上一示例中,通过添加实现应用程序服务的应用程序功能,并在其中添加详细信息来精炼更高级别,更抽象的模型)。应用程序组件已分配)。
重要的是要注意,所有这些推导关系在ArchiMate语言中也有效。在标准中包含的元模型图中未显示它们,因为这会降低其可读性。但是,附录B中的表显示了该语言中两个元素之间的所有允许的关系。
|