架构描述的概念模型

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 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. (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

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.ConcernA 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.