A Conceptual Model of Architecture Description
ISO/IEC/IEEE 42010 is based upon a conceptual model – or “meta model” – of the terms and concepts pertaining to Architecture Description. The conceptual model is presented here using UML class diagrams to represent classes of entities and their relationships.
The Core Ontology: ISO/IEC/IEEE 42010:2022 (second edition)
Here we provide a brief overview of changes and new concepts in the 2nd edition of ISO/IEC/IEEE 42010. The new edition abandons a UML-based meta model, but due to popular demand and to enable comparison with the previous edition, a UML class diagram is used here. Items in purple are new or changed from the previous edition. Discussion of some of the changes follows the diagram.
The 2nd edition (2022) generalizes the subject of an architecture description from System of Interest to Entity of Interest. In the previous edition, an Architecture View is comprised of one or more Architecture Models. In the new edition, Architecture Model is changed to View Component. This 2nd edition introduces Stakeholder Perspectives as a means to group Concerns and therefore to organize Viewpoints framing those Concerns. This edition also introduces Architecture Aspects: characteristics of the Entity of Interest that are reflected in Architecture Views. Among other uses, Aspects can be used to refine the traceability between Concerns and Views.
For historical perspective, the conceptual models in the first edition (2011) are shown below.
For further comparison, its predecessor, the conceptual framework used in the original IEEE 1471-2000™, can be found [here].
Context: ISO/IEC/IEEE 42010:2011 (first edition)
The first diagram captures terms and concepts of systems and their architectures, as a context for understanding Architecture Description.
Referring to the diagram:
Systems exist. A System is situated in its Environment. That environment could include other Systems.
Stakeholders have interests in a System; those interests are called Concerns. A system’s Purpose is one very common Concern. (Note: In the original edition of the Standard, systems were said to have missions; in the revision, Purpose was chosen as a more general replacement to this term.)
Systems have Architectures. An Architecture Description is used to express an Architecture of a System.
- System
- The Standard takes no position on the question, What is a
system?
In the Standard, the term system is used as a placeholder – e.g., it could refer to an enterprise, a system of systems, a product line, a service, a subsystem, or software. Systems can be man-made or natural. Nothing in the Standard depends upon a particular definition of system. Users of the Standard are free to employ whatever system theory they choose.
The premise of the Standard is, For a system of interest to you, the Standard provides guidance for documenting an architecture for that system. - Environment
- Every System inhabits its Environment. A System acts upon that Environment and vice versa. A system’s Environment determines the range of influences upon the system. In the Standard, Environment is intended in the widest possible sense to include developmental, operational, technical, political, regulatory, and all other influences which can affect the architecture. These influences are categorized as Concerns.
- Architecture
- Systems have architectures. In the Standard, the
architecture of a system is defined as:
“fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. The definition was chosen (1) to accommodate the broad range of things listed above under System: the architecture of X is what is fundamental to X (whether X is an enterprise, system, system of systems, or some other entity); and (2) to emphasize (via the phrase “concepts or properties”) that a system can have an architecture even if that architecture is not written down.
For more about the definition, see [Defining “architecture”]. - Architecture Description
- An Architecture Description (AD) is an artifact that expresses an Architecture. Architects and other system stakeholders use Architecture Descriptions to understand, analyze and compare Architectures, and often as “blueprints” for planning and construction. ADs are the primary subject of ISO/IEC/IEEE 42010 (and the focus of the next diagram).
The Core of Architecture Description: ISO/IEC/IEEE 42010:2011 (first edition)
The Standard is organized around the terms and concepts of the diagram below. It depicts the contents of an AD and the relations between those content items when applying the Standard to produce an Architecture Description to express an Architecture for some System of Interest.
- Architecture Description
- An Architecture Description is a work product used to express
the Architecture of some System Of Interest. The Standard
specifies requirements on ADs. An AD describes one possible
Architecture for a System Of Interest. An AD may take the form of
a document, a set of models, a model repository, or some other
form (AD format is not defined by the Standard).
See [Architecture Descriptions] for further details and requirements on ADs. - Stakeholder
- Stakeholders are individuals, groups or organizations holding Concerns for the System of Interest. Examples of stakeholders: client, owner, user, consumer, supplier, designer, maintainer, auditor, CEO, certification authority, architect.
- Concern
- A Concern is any interest in the system. The term derives from the phrase “separation of concerns” as originally coined by Edsgar Dijkstra. Examples of concerns: (system) purpose, functionality, structure, behavior, cost, supportability, safety, interoperability.
- Architecture Viewpoint
- An Architecture Viewpoint is a set of conventions for constructing, interpreting, using and analyzing one type of Architecture View. A viewpoint includes Model Kinds, viewpoint languages and notations, modeling methods and analytic techniques to frame a specific set of Concerns. Examples of viewpoints: operational, systems, technical, logical, deployment, process, information.
- Architecture View
- An Architecture View in an AD expresses the Architecture of the System of Interest from the perspective of one or more Stakeholders to address specific Concerns, using the conventions established by its viewpoint. An Architecture View consists of one or more Architecture Models.
- Architecture Model
- A view is comprised of Architecture Models. Each model is constructed in accordance with the conventions established by its Model Kind, typically defined as part of its governing viewpoint. Models provide a means for sharing details between views and for the use of multiple notations within a view.
- Model Kind
- A Model Kind defines the conventions for one type of Architecture Model.
AD Elements and Correspondences
Architecture Descriptions are comprised of AD Elements. Correspondences capture relationships between AD Elements. Correspondences and Correspondence Rules are used to express and enforce architecture relations such as composition, refinement, consistency, traceability, dependency, constraint and obligation within or between ADs.
- AD Element
- Any item in an AD is considered an element. Every Stakeholder, Concern, Viewpoint, View, Model Kind in an AD is an AD Element. When a Viewpoint or Model Kind introduces constructs, these too are considered AD Elements.
- Correspondence
- Correspondences express a relation between AD Elements. Correspondences are used to express architecture relations of interest within an Architecture Description or between Architecture Descriptions. Correspondences can be governed by Correspondence Rules.
- Correspondence Rule
- Correspondence Rules enforce relations within an Architecture Description or between Architecture Descriptions.
Architecture Decisions and Rationale
Creating an Architecture involves making Architecture Decisions. ISO/IEC/IEEE 42010 specifies requirements for capturing key decisions within an AD in terms of the concepts shown in the next diagram.
An Architecture Decision affects AD Elements and pertains to one or more Concerns. By making a Decision, new Concerns may be raised.
- Architecture Rationale
- Architecture Rationale records the explanation, justification or reasoning about Architecture Decisions that have been made and architectural alternatives not chosen.
Architecture Frameworks and Architecture Description Languages
Architecture frameworks and architecture description languages (ADLs) are two mechanisms widely used in architecting. Instances of each can be specified by building on the concepts of Architecture Description presented above.
The diagram below depicts the contents of an Architecture Framework.
- Architecture Framework
- An architecture framework establishes a common practice for
creating, interpreting, analyzing and using architecture
descriptions within a particular domain of application or
stakeholder community. Examples of Architecture Frameworks: MODAF,
TOGAF, Kruchten’s 4+1 View Model, RM-ODP.
See [Architecture Frameworks] for requirements and long list of examples.
- Architecture Description Language (ADL)
- An ADL is any form of expression for use in Architecture Descriptions. An ADL might include a single Model Kind, a single viewpoint or multiple viewpoints. Examples of ADLs: Rapide, SysML, ArchiMate, ACME, xADL.
The diagram below depicts the contents of an ADL.
