A Conceptual Model of Architecture Description
ISO/IEC/IEEE 42010 is based upon a conceptual model (or metamodel) of the terms and concepts pertaining to Architecture Description. The conceptual model is presented in the Standard using UML class diagrams to represent classes of entities and their relationships.
For historical perspective, here is the conceptual framework used in the original edition [IEEE 1471-2000™].
Context
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. (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 the architecture of that system. - Environment
- Every System exists in 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 operational, developmental, regulatory, and all other influences which can affect the architecture. These influences are captured 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 (i) to fit the broad range of things noted above under System: the architecture of an enterprise, system, system of systems, ... is what is fundamental to it; (ii) to emphasize (through use of the phrase "concepts or properties") that a system has an architecture even if that architecture is not written down. - Architecture Description
- An Architecture Description (AD) is an artifact that expresses an Architecture. Architects and other Stakeholders use Architecture Descriptions to understand, analyze and compare Architectures. ADs are the subject of ISO/IEC/IEEE 42010 and the focus of the next diagram.
The Core of Architecture Description
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 the 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).
- Stakeholder
- Stakeholders are individuals, groups or organizations holding Concerns for the System of Interest. Examples of stakeholders: client, owner, user, consumer, designer, maintainer, auditor, 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 a 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.
The diagram below depicts the contents of an ADL.
- 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.