Structural, which model the
structural coherence of concepts of the same or different typesThe metamodels and examples from the previous chapters show the different types of relationships that the ArchiMate language offers. In this chapter, we provide a more precise description of these relationships.
The relationships can be classified as either:
Structural, which model the
structural coherence of concepts of the same or different types
Dynamic, which are used to
model (temporal) dependencies between behavioral concepts
Other, which do not fall in
one of the two above categories
The composition relationship indicates that an object consists of a number of other objects.
The composition relationship has been inspired by the composition relationship in UML class diagrams, but is applicable to compose a wider range of concepts. In contrast to the aggregation relationship, an object can be part of only one composition.
In addition to composition relationships that are explicitly defined in the metamodel figures of the previous sections, composition is always possible between two instances of the same concept.
Figure 41: Composition Notation
Alternatively, a composition relationship can be expressed by nesting the model elements.
Example
The models below show the two ways to express that the application component Financial application is composed of three other application components.
Example 31: Composition
The aggregation relationship indicates that a concept groups a number of other concepts.
The aggregation relationship has been inspired on the aggregation relationship in UML class diagrams, but is applicable to aggregate a wider range of concepts. In contrast to the composition relationship, an object can be part of more than one aggregation.
In addition to aggregation relationships that are explicitly defined in the metamodel figures of the previous sections, aggregation is always possible between two instances of the same concept.
Figure 42: Aggregation Notation
Alternatively, an aggregation relationship can be expressed by nesting the model elements.
Example
The models below show the two ways to express that the product Car insurance aggregates a contract (Policy) and two business services.
Example 32: Aggregation
The assignment relationship links active elements (e.g., business roles or application components) with units of behavior that are performed by them, or business actors with business roles that are fulfilled by them.
The assignment relationship can relate a business role with a business process or function, an application component with an application function, a business collaboration with a business interaction, an application collaboration with an application interaction, a business interface with a business service, an application interface with an application service, or a business actor with a business role.
Figure 43: Assignment Notation
Alternatively, an assignment relationship can be expressed by nesting the model elements.
Example
The model in below includes the two ways to express the assignment relationship. The Payment function (application) is assigned to the Financial application (component), and the Payment service (application) is assigned to the Application interface.
Example 33: Assignment
The realization relationship links a logical entity with a more concrete entity that realizes it.
The realization relationship indicates how logical entities (“what”), such as services, are realized by means of more concrete entities (“how”). The realization relationship is used in an operational sense (e.g., a process/function realizes a service), but also in a design/implementation context (e.g., a data object may realize a business object, or an artifact may realize an application component).
Figure 44: Realization Notation
Example
The model below illustrates two ways to use the realization relationship. An application (component) Financial application realizes the Billing service (application); the Billing data object realizes the business object Invoice.
Example 34: Realization
The used by relationship models the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations.
The used by relationship describes the services that a role or component offers that are used by entities in the environment. The used by relationship is applied for both the behavior aspect and the structure aspect.
Figure 45: Used By Notation
Example
The model below illustrates the used by relationship: an application interface (in this case, the user interface of the application) is used by the Front office employee, while the Update customer info service is used in the Process change of address business process.
Example 35: Used By
The access relationship models the access of behavioral concepts to business or data objects.
The access relationship indicates that a process, function, interaction, service, or event “does something” with a (business or data) object; e.g., create a new object, read data from the object, write or modify the object data, or delete the object. The relationship can also be used to indicate that the object is just associated with the behavior; e.g., it models the information that comes with an event, or the information that is made available as part of a service. The arrow indicates the flow of information.
Figure 46: Access Notation
Example
The model below illustrates the access relationship: the Create invoice sub-process writes/creates the Invoice business object; the Send invoice sub-process reads the Invoice business object.
Example 36: Access
An association models a relationship between objects that is not covered by another, more specific relationship.
Association is mainly used, as in UML, to model relationships between business objects or data objects that are not modeled by the standard relationships aggregation, composition, or specialization. In addition to this, the association relationship is used to link the informational concepts with the other concepts: a business object with a representation, a representation with a meaning, and a business service with a purpose.
Figure 47: Association Notation
Example
The model illustrates a number of uses of the association relationship.
Example 37: Association
The triggering relationship describes the temporal or causal relations between processes, functions, interactions, and events.
The triggering relationship is used to model the causal relationships between behavior concepts in a process. No distinction is made between an active triggering relationship and a passive causal relationship.
Figure 48: Triggering Notation
Example
The model below illustrates that triggering relationships are mostly used to model causal dependencies between (sub-)processes and/or events.
Example 38: Triggering
The flow relationship describes the exchange or transfer of, for example, information or value between processes, function, interactions, and events.
The flow relationship is used to model the flow of, for example, information between behavior concepts in a process. A flow relationship does not imply a causal or temporal relationship.
Figure 49: Flow Notation
Example
The model below shows a Claim assessment business function, which forwards decisions about the claims to the Claim settlement business function. In order to determine the order in which the claims should be assessed, Claim assessment makes use of schedule information received from the Scheduling business function.
Example 39: Flow
The grouping relationship indicates that objects belong together based on some common characteristic.
Similar to the UML package, the grouping relationship is used to group an arbitrary group of model objects, which can be of the same type or of different types. In contrast to the aggregation or composition relationships, there is no “overall” object of which the grouped objects form a part.
Figure 50: Grouping Notation
Unlike the other language concepts, grouping has no formal semantics. It is only used to show graphically that model elements have something in common. Model elements may belong to multiple (overlapping) groups.
Example
In the model below, the grouping relationship is used to group business objects that belong to the same information domain, in this case Financial administration.
Example 40: Grouping
A junction is used to connect dynamic relationships of the same type.
A junction is used in a number of situations to connect dynamic (triggering or flow) relationships of the same type; e.g., to indicate splits or joins.
Figure 51: Junction Notation
Example
In the model below, a junction is used to denote an or-split (choice).
Example 41: Junction
The specialization relationship indicates that an object is a specialization of another object.
The specialization relationship has been inspired by the generalization/specialization relationship in UML class diagrams, but is applicable to specialize a wider range of concepts. The specialization relationship can relate any instance of a concept with another instance of the same concept.
Specialization is always possible between two instances of the same concept.
Figure 52: Specialization Notation
Example
The model below illustrates the use of the specialization relationship for a business process. In this case the Take out travel insurance and Take out luggage insurance processes are a specialization of a more generic insurance take out process.
Example 42: Specialization
Table 4 gives an overview of the ArchiMate relationships with their definitions.
Table 4: Relationships
|
Structural Relationships |
Notation |
|
|
Association |
Association models a relationship between objects that is not covered by another, more specific relationship. |
|
|
Access |
The access relationship models the access of behavioral concepts to business or data objects. |
|
|
Used by |
The used by relationship models the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations. |
|
|
Realization |
The realization relationship links a logical entity with a more concrete entity that realizes it. |
|
|
Assignment |
The assignment relationship links units of behavior with active elements (e.g., roles, components) that perform them, or roles with actors that fulfill them. |
|
|
Aggregation |
The aggregation relationship indicates that an object groups a number of other objects. |
|
|
Composition |
The composition relationship indicates that an object consists of a number of other objects. |
|
|
Dynamic Relationships |
Notation |
|
|
Flow |
The flow relationship describes the exchange or transfer of, for example, information or value between processes, function, interactions, and events. |
|
|
Triggering |
The triggering relationship describes the temporal or causal relations between processes, functions, interactions, and events. |
|
|
Other Relationships |
Notation |
|
|
Grouping |
The grouping relationship indicates that objects, of the same type or different types, belong together based on some common characteristic. |
|
|
Junction |
A junction is used to connect relationships of the same type. |
|
|
Specialization |
The specialization relationship indicates that an object is a specialization of another object. |
|
The structural relationships described in the previous sections form an important category of relations to describe coherence. The structural relationships are listed in Table 4 in ascending order by “strength”: association is the weakest structural relationship; composition is the strongest. Part of the language definition is an abstraction rule that states that two relationships that join at an intermediate element can be combined and replaced by the weaker of the two.
If two structural relationships r:R and s:S are permitted between elements a, b, and c such that r(a,b) and s(b,c), then a structural relationship t:T is also permitted, with t(a,c) and type T being the weakest of R and S.
Transitively applying this property allows us to replace a “chain” of structural relationships (with intermediate model elements) by the weakest structural relationship in the chain. For a more formal description and derivation of this rule we refer to [15].
With this rule, it is possible to determine the “indirect” relationships that exist between model elements without a direct relationship, which may be useful for, among other things, impact analysis. An example is shown in Figure 43: assume that we would like to know what the impact on the client is if the CRM system fails. In this case, an indirect “used by” relation (the thick arrow on the left) can be derived from this system to the Claim registration service (from the chain assignment – used by – realization – used by – realization). No indirect (structural) relationship is drawn between the CRM system and the Claims payment service.
Example 43: Derived Relationship
It is important to note that all these derived relationships are also valid in ArchiMate. These are not shown in the “barebones” metamodel illustrations shown in the previous sections, because this would clutter up the diagrams. However, the table in Appendix B shows all permitted relationships between two elements in the language.
Downloads of the ArchiMate documentation, are available under license from the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C091.
