7 Relationships

The 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

7.1 Structural Relationships

7.1.1 Composition Relationship

The composition relationship indicates that an object is composed of one or more other objects.

The composition relationship has been inspired by the composition relationship in UML class diagrams. 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 46: 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 33: Composition

7.1.2 Aggregation Relationship

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. 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 47: 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 34: Aggregation

7.1.3 Assignment Relationship

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, a business actor with a business role, or a location with a business object, representation, or business actor.

Figure 48: Assignment Notation

Alternatively, an assignment relationship can be expressed by nesting the model elements.

Example

The model in the example 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 Payment interface.

Example 35: Assignment

7.1.4 Realization Relationship

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 49: 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 36: Realization

7.1.5 Used By Relationship

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. (Note that, although the notation of the “used by” relationship resembles the notation of the dependency relationship in UML, the relationship has a distinct meaning in ArchiMate.)

Figure 50: 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 37: Used By

7.1.6 Access Relationship

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 head, if present, indicates the direction of the flow of information. (The access relationship should not be confused with the UML dependency relationship, which uses a similar notation.)

Figure 51: 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 38: Access

7.1.7 Association Relationship

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 passive structure concepts with the other concepts: a business object with a representation, a representation with a meaning, and a business service with a value.

Figure 52: Association Notation

Example

The model illustrates a number of uses of the association relationship.

Example 39: Association

7.2 Dynamic Relationships

7.2.1 Triggering Relationship

The triggering relationship describes the temporal or causal relationships 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 53: Triggering Notation

Example

The model below illustrates that triggering relationships are mostly used to model causal dependencies between (sub-)processes and/or events.

Example 40: Triggering

7.2.2 Flow Relationship

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 54: 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 41: Flow

7.3 Other Relationships

7.3.1 Grouping

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 55: 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 42: Grouping

7.3.2 Junction

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 56: Junction Notation

Example

In the model below, a junction is used to denote an or-split (choice).

Example 43: Junction

7.3.3 Specialization Relationship

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 57: 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 44: Specialization

7.4 Summary of Relationships

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 is composed of one or more 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 relationships 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.

7.5 Derived Relationships

The structural relationships described in the previous sections form an important category of relationships 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.

For the application of this rule, it is assumed that the assignment relationship has a direction (as indicated by the role names in Figure 2, Figure 3, Figure 9, Figure 26, Figure 34, and Figure 44).

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 [13].

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 48: 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” relationship (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 45: Derived Structural Relationship

For the two dynamic relationships, the following rules apply:

• The begin and/or end point of a triggering or flow relationship between behavioral elements (e.g., processes or functions) may be transferred to active structural elements (e.g., business actors or application components) that are assigned to them.

• The begin and/or end point of a triggering or flow relationship between behavior elements may be transferred to services that they realize.

Example 46: Derived Dynamic 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 Section A.2 shows all permitted relationships between two elements in the language.

return to top of page