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.
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
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).
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.
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.
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.
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.
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.
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.
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.
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”.
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
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.
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.
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.
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.
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.
-
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.
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.
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.
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.
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.
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.
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.
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.
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”:
-
Motivation (Motivation Elements)
-
Strategy (Strategy Layer)
-
Core, which includes the Business Layer (Business Layer), Application Layer (Application Layer), Technology Layer (Technology Layer), the location element (Location) and the grouping element
-
Implementation and Migration (Implementation and Migration Layer)
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
-
Behavior and Structure Elements Metamodel, Specializations of Core Elements, and Composite Elements, 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 Representation Notation and Relationships Between Business Layer and Application and Technology Layer Elements
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
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.
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