## Appendix B: Relationships (Normative)

This appendix details the normative requirements for relationships between elements of the ArchiMate modeling language. This is mainly intended for tool implementation purposes.

### B.1. Specification of Derivation Rules

The following sections specify the formal rules for deriving relationships. The input relationships used for derivation must be allowed by the tables in this appendix. The resulting relationship will then always be allowed by definition and is listed in these tables as well. Note that these derivation rules do not work on relationships between core elements and other elements such as motivation, strategy, or implementation and migration elements, with the exception of the realization and influence relationships. This appendix states in more detail the restrictions that were applied to the use of the derivation rules to arrive at the relationship tables. Applying these rules and restrictions together results in the tables in this appendix, which contain all allowed relationships in the language.

We distinguish between two types of derivations: those that are certainly true in any model where these rules apply, and those that are potentially true but uncertain, depending on the specifics of the model concerned.

Notation of Derivation Rules

In the description of the derivation rules, a shorthand is used to describe relations: p(a,b):R is used to describe the relationship with name p that has concept a as source, concept b as target, and R as its relationship type.

The source and target concepts may be of any type. The relationship type can be restricted by the definition.

By convention, concepts are named a, b, and c in order of appearance, relationships are named p, q, and r in order of appearance, and relationship types are named S, T, and U in order of appearance.

### B.2. Derivation Rules for Valid Relationships

This section states the derivation rules for derivations that are valid in any model where these rules apply.

#### B.2.1. Valid Derivations for Specialization Relationships

DR 1: Transitivity of Specialization

If two relationships p(a,b):S and q(b,c):S exist, with S being Specialization, then a relationship r(a,c):S can be derived.

Example 37: Transitivity of Specialization

#### B.2.2. Valid Derivations for Structural Relationships

The structural relationships can be ordered by “strength”:

• Realization (weakest)

• Assignment

• Aggregation

• Composition (strongest)

Part of the language definition is an abstraction rule that states that, two structural relationships that join at an intermediate element under specific conditions, can be combined and replaced by the weaker of the two.

DR 2: Derivation Between Structural Relationships

If two relationships p(a,b):S and q(b,c):T exist, with S and T being structural relationships, then a relationship r(a,c):U can be derived, with U being the weakest of S and T.

Example 38: Derivation of Structural Relationships

Informally, this means that if two structural relationships are “in line” (the target of one relation joins at the source of the other relation) they can be replaced by the weakest of the two. Transitively applying this property allows us to replace a “chain” of structural relationships that are in line (with intermediate model elements) by the weakest structural relationship in the chain.

An example is shown in Example 39: assume that the goal is to omit the functions, sub-functions, and services from the model. In this case, an indirect realization relationship (the relationship labeled “Derived Relationship” (thick arrow on the right) can be derived from “Financial Application” to the “Payment Service” (from the chain assignment – composition – realization).

Example 39: Derivation from a Chain of Structural Relationships

#### B.2.3. Valid Derivations for Dependency Relationships

Part of the language definition is an abstraction rule that states that a structural relationship, and a dependency relationship that join at an intermediate element under certain conditions, can be combined and replaced by the dependency relationship. This rule is split into two parts for both the source and target side of the dependency.

DR 3: Derivation Between Structural and Dependency Relationships

If two relationships p(a,b):S and q(b,c):T exist, with S being a structural relationship and T being a dependency relationship, then a relationship r(a,c):T can be derived.

Example 40: Derivation from a Dependency and a Structural Relationship in Line

DR 4: Derivation Between Opposing Structural and Dependency Relationships

If two relationships p(a,b):S and q(c,b):T exist, with S being a structural relationship and T being a dependency relationship, then a relationship r(c,a):T can be derived.

Example 41: Derivation from a Dependency and a Structural Relationship in the Opposite Direction

These rules may be combined with the derivation rule for structural relations (DR2), allowing to replace a “chain” of structural relationships and a dependency relationship (with intermediate model elements) by the dependency relationship in the chain, given that the chain does satisfy the restrictions for structural and dependency relationships. Informally, this means that the begin and/or endpoint of a dependency relationship can be transferred “backwards” in a chain of elements connected by structural relationships.

#### B.2.4. Valid Derivations for Dynamic Relationships

Part of the language definition is an abstraction rule that states that a structural relationship, and a dynamic relationship that join at an intermediate element under certain conditions, can be combined and replaced by the dynamic relationship. This rule is split into a generic rule and rules specific for flow and triggering.

For the two dynamic relationships, the following rules apply.

DR 5: Derivation Between Structural and Dynamic Relationships

If two relationships p(a,b):S and q(b,c):T exist, with S being a structural relationship and T being a dynamic relationship, then a relationship r(a,c):T can be derived.

Example 42: Derivation from a Dynamic and a Structural Relationship in Line

DR 6: Derivation Between Structural and Flow Relationships

If two relationships p(a,b):S and q(c,b):T exist, with S being a structural relationship and T being Flow, then a relationship r(c,a):T can be derived.

Example 43: Derivation from a Flow and a Structural Relationship in the Opposite Direction

DR 7: Derivation Between Structural and Triggering Relationships

If two relationships p(a,b):S and q(b,c):T exist, with S being Triggering and T being a structural relationship, then a relationships r(a,c):S can be derived.

Example 44: Derivation from a Triggering and a Structural Relationship in Line

These rules can be applied repeatedly. Informally, this means that the begin and/or endpoint of a flow relationship can be transferred “backwards” in a chain of elements connected by structural relationships. Example 45 shows two of the possible flow relationships that can be derived with these rules, given a flow relationship between the two services.

Example 45: Derivation from Dynamic Relationships

Moreover, triggering relationships are transitive, as expressed in the next rule.

DR 8: Derivation Between Triggering Relationships

If two relationships p(a,b):S and q(b,c):S exist, with S being Triggering, then a relationship r(a,c):S can be derived.

Example 46: Derivation from Triggering Relationships

This rule may be combined with the rules for deriving dynamic relations and structural relationships, thus allowing discovery of triggering relations. Example 47 shows how the “Sales Department” is assigned to a business process “Selling” that triggers a business process “Invoicing”, which is composed of the business processes “Billing” and “Payment”. “Invoicing” in turn triggers the business process “Shipping”, to which the “Shipping Department” is assigned. The derivation rules allow that the “Sales Department” triggers the “Shipping” business process, but also the business process “Billing”.

Example 47: Derivation from Triggering and Structural Relationships

### B.3. Derivation Rules for Potential Relationships

The derivation rules defined so far lead to relationships that are valid with high certainty. If a model is well designed and describes a stable state of the enterprise, these derived relationships can be trusted.

This section describes derivation rules for relationships with lower certainty. They might be relevant but may also be wrong, depending on the specifics of the model. It is up to the modeler to decide on this.

The derivation rules for potential relationships are used to enrich the metamodel with relationships that otherwise would not be allowed and can be used to discover relationships in a model that otherwise might not show.

Example

Example 48 shows a potential derivation in which some relationships are valuable, and some are not. In this example, an architect first modeled an application component called “Suite” that uses two infrastructure services called “Website Hosting” and “Database Hosting”. Later, the application component “Suite” was detailed by adding two composed application components “Front-end” and “Back-end”. The architect in this case did not reconsider the serving relations. Potential derivation rule PDR 5 allows the red and grey relationships. In this case, the architect determines that only the red relationships are valuable.

Example 48: Examples of Potential Derivation

#### B.3.1. Potential Derivation for Specialization Relationships

Part of the language definition is a rule that states that every relation from or to a generic element is inherited by the specialized element. This leads to a number of potential derivations.

The first two rules apply in the case where the target of a specialization relationship is the source or target of any other relationship. In this case, the source of the specialization could have the same relationship.

PDR 1: Derivation with Specialization and Other Relationships

If two relationships p(a,b):S and q(b,c):T exist, with S being Specialization and T being a structural, dependency, or dynamic relationship, then a relationship r(a,c):T might be derived.

Example 49: Potential Derivation from a Specialization and Another Relationship in Line

PDR 2: Derivation with Specialization and Other Relationships

If two relationships p(a,b):S and q(c,b):T exist, with S being Specialization and T being a structural, dependency, or dynamic relationship, then a relationship r(c,a):T might be derived.

Example 50: Potential Derivation from a Specialization and Another Relationship in the Opposite Direction

The next two rules apply in the case where the source of a specialization relationship is joining the source or target of any other relationship. In this case, the target of the specialization could have the same dependency.

PDR 3: Potential Derivation Between Specialization and Any Other Relationship

If two relationships p(a,b):S and q(a,c):T exist, with S being Specialization and T being a structural, dependency, or dynamic relationship, then a relation r(b,c):T might be derivable.

Example 51: Potential Derivation from Another Relationship and a Specialization in Line

PDR 4: Potential Derivation Between Specialization and Any Other Relationship

If two relationships p(a,b):S and q(c,a):T exist, with S being Specialization and T being a structural, dependency, or dynamic relationship, then a relationship r(c,b):T might be derivable.

Example 52: Potential Derivation from Another Relationship and a Specialization in Line

The potential relationships derived with the rules from this section may vary a lot in likelihood, depending on the direction of the derivation (from generalized to specialized element or vice versa), the type of relationship, and the specific interpretation of the relationship. Also, a chain of multiple potential derivations usually leads to a lower probability.

Consider a model with a “Project Team” assigned to a “Project”, and an “IT Project Team”, as a specialization of “Project Team”, assigned to an I”T Project”, as a specialization of “Project”. A “Project Team” aggregates a “Project Manager”, a “Project” accesses (reads) “Project Planning”, and an “IT Project” accesses (writes) “Software Documentation” (Example 53).

Example 53: Specializations Used in Potential Derivations
• Composition or aggregation relationships often lead to derivations that are (almost) certain when moving the source of the relationship to a specialized element (PDR 1), or the target of the relationship to a generalized element (PDR 4)

In this example, “IT Project Team” aggregates “Project Manager” is a derived relationship that is almost certain.

• For the assignments, this depends on the perspective: “IT Project Team” assigned to “Project” (PDR 1) is probably true in the sense that the “IT Project Team” always performs a “Project”, but uncertain in the sense that a “Project” is not always performed by an “IT Project Team” (e.g., if it is a business project)

For “Project Team” assigned to “IT Project” (PDR 2), this is the other way around.

• “IT Project” accesses (reads) “Project Planning” (PDR 1) is almost certainly a derived relationship, while “Project” accesses (writes) “Software Documentation” (PDR 3) is only valid for a subset of “Projects”

#### B.3.2. Potential Derivation for Structural and Dependency Relationships

The next two rules apply in the case where a structural and dependency relation are joining at the source of the structural relation. In this case, the target of the structural relation could have the same dependency.

PDR 5: Potential Derivation Between Structural and Dependency Relationships

If two relationships p(a,b):S and q(c,a):T exist, with S being a structural relationship and T being a dependency relationship, then a relationship r(c,b):T might be derivable.

Example 54: Potential Derivation from a Dependency and a Structural Relationship in Line

PDR 6: Potential Derivation Between Structural and Dependency Relationships

If two relationships p(a,b):S and q(a,c):T exist, with S being a structural relationship and T being a dependency relationship, then a relationship r(b,c):T might be derivable.

Example 55: Potential Derivation from a Dependency and a Structural Relationship in the Opposite Direction

#### B.3.3. Potential Derivation for Dependency Relationships

The next rule applies in the case where two dependency relationships are joining at an intermediate element. In this case, the two relations could be replaced by one, being the weaker of the two.

The dependency relationships are ordered by “strength”:

• Association (weakest)

• Influence

• Access

• Serving (strongest)

PDR 7: Potential Derivation Between Dependency Relationships

If two relationships p(a,b):S and q(b,c):T exist, with S and T being a Dependency Relationship, then a relationship r(a,c):U might be derivable, with U being the weakest of S and T.

Example 56: Potential Derivation from Two Dependency Relationships

#### B.3.4. Potential Derivation for Dynamic Relationships

The next rules apply in the case where a structural and dynamic relation are joining at an intermediate element. In this case, the target of the structural relation could have the same dependency.

PDR 8: Potential Derivation Between Structural and Dynamic Relationships

If two relationships p(a,b):S and q(b,c):T exist, with S being Flow and T being a structural relationship, then a relation r(a,c):S might be derivable.

Example 57: Potential Derivation from a Dynamic and a Structural Relationship in Line

PDR 9: Potential Derivation Between Structural and Dynamic Relationships

If two relationships p(a,b):S and q(a,c):T exist, with S being a structural relationship and T being a dynamic relationship, then a relationship r(b,c):T might be derivable.

Example 58: Potential Derivation from a Dynamic and a Structural Relationship in the Opposite Direction

The next rule applies in the case where two flow relationships join at an intermediate element. In this case, the flow relations could be replaced by one relation.

PDR 10: Potential Derivation Between Flow Relationships

If two relationships p(a,b):S and q(b,c):S exist, with S being Flow, then a relationship r(a,c):S might be derivable.

Example 59: Potential Derivation from Two Flow Relationships

PDR 11: Potential Derivation Between Triggering and Structural Relationships

If two relationships p(a,b):S and q(c,b):T exist, with S being a Triggering relationship and T being a structural relationship, then a relation r(a,c):S might be derivable.

Example 60: Potential Derivation from a Triggering and Structural Relationships

#### B.3.5. Potential Derivation Rule for Grouping

The next rule applies specifically for the grouping element.

PDR 12: Potential Derivation with Elements Aggregated in a Grouping Element

If two relationships p(b,a):S and q(b,c):T exist, with S being Aggregation or Composition, b being a Grouping element and T being a Realization or Assignment, then a relationship r(a,c):T might be derivable, only if the metamodel allows T from a to c.

Example 61: Potential Derivation with Grouping Element

### B.4. Restrictions on Applying Derivation Rules

This section describes a number of restrictions that apply when using the derivation rules to infer the set of allowed relationships. In this context, the following are called “domains”:

Given a relation p(a,b):S that can be derived through one of the derivation rules of Sects. B.2 or B.3, then that derivation is not allowed if any of the following is true:

• a is in one of the domains Implementation and Migration, Core, or Strategy, and b is in the domain Motivation, and S is not Assignment, Realization, Influence, or Association

• a is in the domain Motivation, and b is in one of the domains Implementation and Migration, Core, or Strategy, and S is not Association

• a is in one of the domains Implementation and Migration or Core, and b is in the domain Strategy, and S is not Realization or Association

• a is in the domain Strategy, and b is in one of the domains Implementation and Migration or Core, and S is not Association

• a is in the domain Implementation and Migration, and b is in the domain Core, and S is not Realization or Association

• a is in the domain Core, and b is in the domain Implementation and Migration, and S is not Assignment or Association

• a is a Grouping, Location or Plateau, and b is in the domain Relationships, and S is not Composition, Aggregation, or Association

• a is not a Grouping, Location, or Plateau, and b is in the domain Relationships, and S is not Association

• a is in the domain Relationships, and S is not Association

• S is Influence and b is not in the domain Motivation

• S is Access and b is not a Passive Structure Element

• a is not a Passive Structure Element, and b is a Passive Structure Element, and S is not Access, Assignment, or Association

• a is a Passive Structure Element, and b is a Passive Structure Element, and S is not Realization or Association

• a is a Passive Structure Element, and b is not a Passive Structure Element, and S is not Realization, Influence, or Association

Given a relation p(a,b):S that can be derived through one of the derivation rules of Sects. B.2 or B.3, with c being the third element on which the original relations joined (for instance q(a,c):T and r(c,b):U) than that derivation is not allowed if any of the following is true:

• The domain of c is different from the domains of both a and b, unless a is in domain Implementation and Migration, c is in domain Core, and b is in one of the domains Motivation or Strategy

• a is in domain Implementation and Migration, b is in one of the domains Motivation or Strategy, and c is Location or Grouping

Notes:

• These restrictions only apply to derived relationships, not to relationships explicitly defined in the metamodel diagrams, which are allowed by definition

• Figure 5, Figure 12, and Figure 18, which provide the generic structure of layers, are intended as a template for these layers; the subtypes of these elements do not inherit all possible relationships with other subtypes, only with those within their own layer, as specified in the layer-specific metamodel fragments

• Product and plateau are composite elements, but can only aggregate or be composed of the specific concepts depicted in their respective metamodel fragments Figure 67 and Figure 104

### B.5. Relationship Tables

This section provides a set of tables with all allowed relationships. It is constructed from the metamodel figures in Chapter 3 through Chapter 12 and the derivation rules for relationships outlined in Section B.1.

The letters in the tables have the following meaning:

(a)ccess (c)omposition (f)low a(g)gregation ass(i)gnment i(n)fluence ass(o)ciation (r)ealization (s)pecialization (t)riggering ser(v)ing

### B.6. Grouping, Plateau, and Relationships Between Relationships

In addition to the relationships derived using the rules specified in Sections B.2 and B.3, the following relationships are also allowed for grouping, plateau, relationships, and relationship connectors:

• Grouping and location elements may have an aggregation or composition relationship to any concept (element, relationships, or relationship connectors)

• A grouping element may be the source of any relationship with any element (provided that the element is a possible target element for the relationship)

• A grouping element may be the target of any relationship with any element (provided that the element is a possible source element for the relationship)

• A grouping element may have any relationship with another grouping element

• Any relationship may have an association relationship with any element

The resulting relationships between elements have been added to the table in Section B.5 and are summarized in Table 21.

 From → ↓ To Grouping Plateau/ Location Element other than Grouping, Plateau, Location Relationship Relationship Connector Grouping any cg + any** any** o afinortv* Element other than Grouping any* See metamodel. See metamodel. o afinortv* Relationship cg + o cg + o o o Relationship Connector afinortv afinortv** afinortv** o afinortv

* Provided that element is a possible target element of the relationship (see Section B.5).

** Provided that element is a possible source element of the relationship (see Section B.5).

(a)ccess (c)omposition (f)low a(g)gregation ass(i)gnment i(n)fluence ass(o)ciation (r)ealization (s)pecialization (t)riggering ser(v)ing