ArchiMate® 3.1 Specification. The Open Group
href="#litres_trial_promo">6, 7, 8, 9, 10, 11, 12, and 13
2. Shall support the standard iconography as specified in Chapters 4, 5, 6, 7, 8, 9, 10, 11, and 13, and summarized in Appendix A
3. Shall support the viewpoint mechanism as specified in Chapter 14
4. Shall support the language customization mechanisms as specified in Chapter 15 in an implementation-defined manner
5. Shall support the relationships between elements as specified in Appendix B
6. May support the example viewpoints described in Appendix C
Readers are advised to check The Open Group website for additional conformance and certification requirements referencing this standard.
1.4 Normative References
None.
1.5 Terminology
For the purposes of this standard, the following terminology definitions apply:
Can Describes a possible feature or behavior available to the user.
Deprecated Items identified as deprecated may be removed in the next version of this standard.
Implementation-defined
Describes a value or behavior that is not defined by this standard but is selected by an implementor of a software tool. The value or behavior may vary among implementations that conform to this standard. A user should not rely on the existence of the value or behavior. The implementor shall document such a value or behavior so that it can be used correctly by a user.
May Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.
Obsolescent Certain features are obsolescent, which means that they may be considered for withdrawal in future versions of this standard. They are retained because of their widespread use, but their use is discouraged.
Shall Describes a feature or behavior that is a requirement. To avoid ambiguity, do not use “must” as an alternative to “shall”.
Shall not Describes a feature or behavior that is an absolute prohibition.
Should Describes a feature or behavior that is recommended but not required.
Will Same meaning as “shall”; “shall” is the preferred term.
1.6 Future Directions
None.
2 Definitions
For the purposes of this standard, the following terms and definitions apply. The TOGAF® framework [4] should be referenced for Enterprise Architecture-related terms not defined in this chapter. Merriam-Webster’s Collegiate Dictionary (11th Edition) should be referenced for all other terms not defined in this chapter.
Any conflict between definitions described here and the TOGAF framework is unintentional. If the definition of a term is specific to the ArchiMate modeling language, and a general definition is defined by the TOGAF framework, then this is noted in the definition.
2.1 ArchiMate Core Framework
A reference structure used to classify elements of the ArchiMate core language. It consists of three layers and three aspects.
Note: The ArchiMate Core Framework is defined in detail in Section 3.4.
2.2 ArchiMate Core Language
The central part of the ArchiMate language that defines the concepts to model Enterprise Architectures. It includes concepts from three layers: Business, Application, and Technology (including Physical).
2.3 Architecture View
A representation of a system from the perspective of a related set of concerns.
Note: In some sections of this standard, the term “view” is used as a synonym for “architecture view”.
2.4 Architecture Viewpoint
A specification of the conventions for a particular kind of architecture view.
Note: In some sections of this standard, the term “viewpoint” is used as a synonym for “architecture viewpoint”.
2.5 Aspect
Classification of elements based on layer-independent characteristics related to the concerns of different stakeholders. Used for positioning elements in the ArchiMate metamodel. See also Section 2.9.
Note: Aspects are described in Section 3.4.
2.6 Attribute
A property associated with an ArchiMate language element or relationship.
2.7 Composite Element
An element consisting of other elements from multiple aspects or layers of the language.
2.8 Concept
Either an element, a relationship, or a relationship connector. See also Section 2.12 and Section 2.14.
Note: The top-level language structure is defined in detail in Section 3.2.
2.9 Conformance
Fulfillment of specified requirements.
2.10 Conforming Implementation
An implementation which satisfies the conformance requirements defined by the conformance clause of this standard. See Section 1.3.
2.11