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.

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.

Derivation Rules for Valid Relationships

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

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.

b ex Transitivity of Specialization
Example 37: Transitivity of Specialization

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.

b ex Derivation of Structural Relationships
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 Derivation from a Chain of Structural Relationships: 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).

b ex Derivation from a Chain of Structural Relationships
Example 39: Derivation from a Chain of Structural Relationships

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.

b ex Derivation from a Dependency and a Structural Relationship in Line
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.

b ex Derivation from a Dependency and a Structural Relationship in the Opposite Direction
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.

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.

b ex Derivation from a Dynamic and a Structural Relationship in Line
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.

b ex Derivation from a Flow and a Structural Relationship in the Opposite Direction
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.

b ex Derivation from a Triggering and a Structural Relationship in Line
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. Derivation from Dynamic Relationships shows two of the possible flow relationships that can be derived with these rules, given a flow relationship between the two services.

b ex Derivation from Dynamic Relationships
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.

b ex Derivation from Triggering Relationships
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. Derivation from Triggering and Structural Relationships 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”.

b ex Derivation from Triggering and Structural Relationships
Example 47: Derivation from Triggering and Structural Relationships

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

Examples of Potential Derivation 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.

b ex Examples of Potential Derivation
Example 48: Examples of Potential Derivation

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.

b ex Potential Derivation from a Specialization and Another Relationship in Line
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.

b ex Potential Derivation from a Specialization and Another Relationship in the Opposite Direction
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.

b ex Potential Derivation from Another Relationship and a Specialization in Line 1
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.

b ex Potential Derivation from Another Relationship and a Specialization in Line 2
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” (Specializations Used in Potential Derivations).

b ex Specializations Used in Potential Derivations
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”

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.

b ex Potential Derivation from a Dependency and a Structural Relationship in Line
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.

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

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.

b ex Potential Derivation from Two Dependency Relationships
Example 56: Potential Derivation from Two Dependency Relationships

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.

b ex Potential Derivation from a Dynamic and a Structural Relationship in Line
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.

b ex Potential Derivation from a Dynamic and a Structural Relationship in the Opposite Direction
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.

b ex Potential Derivation from Two Flow Relationships
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.

b ex Potential Derivation from a Triggering and Structural Relationships
Example 60: Potential Derivation from a Triggering and Structural Relationships

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.

b ex Potential Derivation with Grouping Element
Example 61: Potential Derivation with Grouping Element

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:

Relationship Tables

This section provides a set of tables with all allowed relationships. It is constructed from the metamodel figures in Language Structure through Implementation and Migration Layer and the derivation rules for relationships outlined in Specification of Derivation Rules.

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 fig motivation table
b fig motivation and strategy table
b fig business 1
b fig business 2
b fig application 1
b fig application 2
b fig technology 1
b fig technology 2
b fig physical
b fig implementation and migration

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 Relationship Tables and are summarized in Grouping, Plateau, and Relationships Between Relationships.

Table 1. Grouping, Plateau, and Relationships Between Relationships

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 Relationship Tables).

** Provided that element is a possible source element of the relationship (see Relationship Tables).

(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