IEEE 1471-2000™ Conceptual Framework for Architectural Description
For historical reasons, here is the conceptual framework that was
a part of IEEE 1471-2000 (adopted by ISO as ISO/IEC 42010:2007).
See current conceptual model for ISO/IEC/IEEE 42010 [here].
The diagram above captures the conceptual framework of the
2000/2007 edition of the standard via a UML class diagram. The
diagram has two purposes in the standard: to establish terminology
for stating requirements on architectural descriptions (the subject
matter of the standard); and to offer the community a conceptual
basis for continued evolution of practices in the field. The
discussion here will stick to the terms of the 2000/2007 edition, but may
allude to some clarifications considered by subsequent joint IEEE
and ISO revisions.
- System
- The standard takes no position on the question, What is a
system? It could be an application, a subsystem, a service, a
product line, a system of systems or an enterprise. The system may
be man-made or natural. The premise of the standard is, If you
have a system of interest, the standard provides guidance for
documenting that system's architecture. Nothing in the standard
depends upon a specific definition of system.
- Mission
- Most systems exist to fulfill one or more missions, or functions
or objectives. The architecture should help the system meet its
missions.
- Environment
- A system exists within an environment. The system acts upon that
environment and vice versa. A system's environment determines the
range of influences upon the system. In the standard we intend
environment in the widest possible sense to include all relevant
operational, developmental, regulatory, etc. influences.
- Architecture
- Every system has an architecture. In fact, a system could have
many architectures. In IEEE 1471, an architecture is a conception of
a system. There may be many conceptions of a system. Within the
scope of use of the standard, when one is sitting down to produce an
architectural description (AD), there is exacly one architecture
(concept) being documented.
NOTE: The entities above, System, Mission, Environment and
Architecture, are all conceptual in nature. There are no requirements
("shalls") in the standard pertaining to these entities. The
requirements in the standard apply to the items below which pertain to
the concrete representation of an architecture.
- Architectural Description
- An architectural description (AD) is an collection of artifacts
or work products used to describe an architecture. Architectural
descriptions are the primary subject of the standard. Any
architecture may be described by one or more architecture descriptions
(not shown in diagram). In the standard, an AD describes exactly one
architecture for a system of interest. An architecture description,
per the standard, is made up of various contents: identification of
stakeholders, architectural concerns, architectural viewpoints,
architectural views and architectural models.
- Stakeholder
- A stakeholder is any person, organization or group with an
interest in the system. Examples of stakeholders: architect,
designer, client, user, maintainer, auditor, and certification
authority. Within the standard, a stakeholder has one or more
(architectural) concerns pertaining to the system of interest.
- (Architectural) Concern
- A concern is any interest in the system. The term is derived from
the phrase "separation of concerns" as in Software Engineering. A
concern may be held by one or more stakeholders.
NOTE: Just as an architectural description is a concrete
representation of an architecture, the identification of a system's
stakeholders and concerns is a concrete representation of its
environment in terms of its influences.
- (Architectural) Viewpoint
- A viewpoint is a set of conventions for constructing,
interpreting and analyzing a view in terms of viewpoint languages
and notations, modeling methods and analytic techniques to be used
to address a set of concerns held by stakeholders. A viewpoint
covers 1 or more concerns and stakeholders
- (Architectural) View
- A view is a representation of the whole system from the
perspective of a related set of concerns. A view conforms to exactly
one viewpoint.
- (Architectural) Model
- A view is comprised of one or more models. Each model is
constructed in accordance with conventions established by the
viewpoint. A model may be a part of one or more views. Models
provide for sharing details between views and for the use of
multiple viewpoint languages within a view.
- Library Viewpoint
- A library viewpoint is one that is predefined (reusable) and
does not need to be spelled out within an AD in which it is
used.
- (Architectural) Rationale
- Rationale captures the reasons why certain architectural choices
have been made (such as viewpoints selected for use, and
architectural decisions).
Resources for this website, in support of the revision of ISO/IEC/IEEE 42010, provided by
Olimpia.com.
Comments, corrections, suggestions on this site to:
Webmaster.