Dependency relationships describe how elements support or are used by other elements. Three types of dependency relationship are distinguished: The serving relationship represents a control dependency, denoted by a solid line. The access relationship represents a data dependency, denoted by a dashed line. The influence relationship is the weakest typeRead More →
The realization relationship indicates that an entity plays a critical role in the creation, achievement, sustenance, or operation of a more abstract entity.. The example below illustrates two ways to use the realization relationship. A Transaction Processing function realizes a Billing Service; the Billing Data object is realized by theRead More →
The aggregation relationship indicates that an element groups a number of other concepts. The example below includes the two ways to express the assignment relationship. The example shows two ways to express that the Customer File aggregates an Insurance Policy and Insurance Claim: The aggregation relationship has been inspired by the aggregation relationship in UMLRead More →
The assignment relationship expresses the allocation of responsibility, performance of behavior, or execution. The example below includes the two ways to express the assignment relationship. The Finance active structure element is assigned to the Transaction Processing function, and the Payment Interface is assigned to the Payment Service. The assignment relationshipRead More →
The composition relationship indicates that an element consists of one or more other concepts. Example below shows the two ways to express that the Financial Processing function is composed of three sub-functions: The composition relationship has been inspired by the composition relationship in UML class diagrams. Note That: In contrastRead More →
Structural relationships represent the ‘static’ coherence within an architecture. The composing concept (the ‘from’ side of the relationship) is always an element; the composed concept (the ‘to’ side of the relationship) may in some cases also be another relationship. Nesting Form of Elements Structural relationships may also be expressed byRead More →
ArchiMate defines a core set of generic relationships, each of which can connect a predefined set of source and target concepts: The relationships are classified as follows: Structural relationships – model the static construction or composition of concepts of the same or different types Dependency relationships – model how elements are usedRead More →
A New GitBook Target for ArchiMate Frequently Asked Questions (FAQ), Here is the Table of Contents: 20 ARTICLES What is ArchiMate? Why ArchiMate? What is Service Concepts in ArchiMate How to Group Services into Product in ArchiMate? What is Aspects in ArchiMate? What is ArchiMate Layers? ArchiMate Core Framework Example Read More →
Notational Cues in ArchiMate In addition to the colors, other notational cues can be used to distinguish between the layers of the framework. A letter ‘M’, ‘S’, ‘B’, ‘A’, ‘T’, ‘P’, or ‘I’ in the top-left corner of an element can be used to denote a Motivation, Strategy, Business, Application,Read More →
The physical elements are added as an extension to the Technology Layer for modeling the physical world. There are only active and passive structure element concepts in the physical elements and there are no separate physical behavior elements are defined here in this layer. The behavior elements from the TechnologyRead More →