Architectural Description

Reference number of working document: ISO/IEC JTC 1/SC 7 N 000

Date: 2007-07-04

Reference number of document: ISO/IEC WD1 42010 IEEE P42010/D1

Committee identification: ISO/IEC JTC 1/SC 7/WG 42

Secretariat: Sweden

Systems and Software Engineering — Architectural Description

Élément introductif — Élément principal — Partie n: Titre de la partie

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type: International standard Document subtype: if applicable Document stage: (20) Preparation Document language: E

ISO/IEC WD1 42010 IEEE P42010/D1

This ISO/IEC and IEEE document is a Draft International Standard and is copyright-protected by ISO/IEC and IEEE. Except as permitted under the applicable laws of the user's country, neither this draft document nor any extract from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, photocopying, recording or otherwise, without prior written permission being secured.

Requests for permission to reproduce should be addressed to either ISO or IEEE at the address below or ISO's member body in the country of the requester.

ISO copyright office Case postale 55 CH-1211 Geneva 20 Tel. +41 22 749 01 11 Fax. +41 22 749 09 47 E-mail: [email protected] Web: www.iso.org

IEEE Standards Association Manager, Standards Intellectual Property 445 Hoes Lane Piscataway, NJ 08854 E-mail: [email protected] Web: standards.ieee.org

Reproduction may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

ISO/IEC WD1 42010 IEEE P42010/D1

Contents Page

Introduction ...... 6 Historical Background on WD 1...... 6 1 Scope ...... 7 1.1 Purpose ...... 7 1.2 Field of Application ...... 8 1.3 Limitations ...... 8 2 Conformance ...... 9 3 Normative references ...... 9 4 Terms and definitions ...... 9 5 Conceptual framework...... 11 5.1 Architectural description in context...... 11 5.2 Stakeholders and their roles...... 17 5.3 Architectural activities in the life cycle...... 17 5.3.1 Scenario: architecture of single systems...... 18 5.3.2 Scenario: iterative architecture for evolutionary systems...... 18 5.3.3 Scenario: architecture of existing systems ...... 19 5.3.4 Scenario: architectural evaluation...... 19 5.3.X New Scenario(s): ...... 19 5.4 Uses of architectural descriptions...... 20 6 Architecture description practices ...... 20 6.1 Architectural documentation ...... 21 6.2 Identification of stakeholders and concerns ...... 22 6.3 Selection of architectural viewpoints...... 22 6.4 Architectural views...... 23 6.4.1 Architectural Models...... 24 6.5 Consistency among architectural views ...... 24 6.5.1 View Correspondences ...... 25 6.5.2 Viewpoint Correspondence Rules ...... 25 6.6 Architectural rationale ...... 26 6.6.1 Levels of Architectural Rationale ...... 27 6.6.2 Decision Capture and Tracking...... 28 6.7 Architectural Descriptions of Multiple Systems of Interest...... 29 7 Architecture Frameworks ...... 29 7.1 Reference Model and General Concepts ...... 29 Annex A (informative) Notes on terminology...... 32 A.1 Concerns ...... 32 A.2 Architecture...... 32 A.3 Models and Architectural Models...... 33 A.4 Architectural Views and Viewpoints...... 34 Annex B (informative) Template Outline for an Architectural Description ...... 37 Annex C (informative) Examples of architectural viewpoints ...... 38 C.1 Scenarios viewpoint ...... 38

ISO/IEC WD1 42010 IEEE P42010/D1

C.1.1 Stakeholders...... 38 C.1.2 Concerns ...... 38 C.1.3 Viewpoint language ...... 38 C.1.4 Modelling methods ...... 38 C.1.5 Analytic methods ...... 39 C.1.6 References ...... 39 C.2 Components and connectors viewpoint...... 39 C.2.1 Architectural concerns ...... 39 C.2.2 Viewpoint language ...... 39 C.2.3 Analytic methods ...... 40 C.3 Behavioral viewpoint...... 40 C.3.1 Architectural Concerns...... 40 C.3.2 Modelling methods ...... 40 C.3.3 Analytic methods ...... 40 C.4 Physical interconnect viewpoint ...... 41 C.4.1 Architectural Concerns...... 41 C.4.2 Viewpoint language ...... 41 C.5 Link bit error rate viewpoint...... 41 C.5.1 Architectural concerns ...... 41 C.5.2 Viewpoint language ...... 41 Annex D (informative) <>...... 43 Annex E (informative) Review of Architectural Descriptions...... 44 Annex X (informative) <>...... 45 X.1 Relation to 12207.0-1996...... 45 X.2 Decomposition and allocation viewpoint...... 45 Bibliography ...... 47

ISO/IEC WD1 42010 IEEE P42010/D1

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.

ISO/IEC 42010 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology, Subcommittee SC 7, Systems and Software Engineering.

{Editor: In accordance with IEEE CS’s liaison agreement with SC7, the following statement has been added.}

The IEEE Computer Society collaborated with ISO/IEC JTC 1 in the development of this International Standard. The first edition of this international standard was a fast-track adoption of IEEE Std 1471-2000, Recommended practice for architectural description of software-intensive systems.

ISO/IEC WD1 42010 IEEE P42010/D1

Introduction

Editor: The Introduction will address these areas: motivations for architecture; scope of architecture in this standard; envisioned usage by architects, projects, organizations and enterprises; and contain a summary of Clauses and Annexes.

Historical Background on WD 1

The IEEE Architecture Planning Group (APG) was formed in August 1995; chartered by the IEEE Software Engineering Standards Committee (SESC) to set a direction for incorporating architectural thinking into IEEE standards. The result of the APG’s deliberations was to recommend an IEEE activity with the following goals:

— To define useful terms, principles and guidelines for the consistent application of architectural precepts to systems throughout their life cycle

— To elaborate architectural precepts and their anticipated benefits for software products, systems, and aggregated systems (i.e., “systems of systems”)

— To provide a framework for the collection and consideration of architectural attributes and related information for use in IEEE standards

— To provide a useful road map for the incorporation of architectural precepts in the generation, revision, and application of IEEE standards

In April 1996 SESC created the Architecture Working Group (AWG) to implement those recommendations.

In 2000, IEEE Std 1471, IEEE Recommended Practice for Architectural Description of Software-Intensive System, was approved for use, and a year later adopted by ANSI.

In 2006, IEEE 1471-2000 was accepted following a fast-track ballot to become the first edition of ISO/IEC 42010.

The present document is the joint ISO and IEEE draft revision of that standard. Among the revision goals: harmonization with ISO 15288 and ISO 12207 systems and software life cycle models, and alignment with other ISO architecture-related efforts, taking into consideration all comments received during the fast-track ISO ballot (March 2006).

Since the initial approval of IEEE 1471, there has been wide acceptance for the use of multiple viewpoints to describe architectures, and in the notion of stakeholder concerns as a primary motivation for the content of architectural descriptions. This revision of the standard builds upon these core concepts, and captures additional consensus in the areas of view correspondence, commonly used viewpoints and architecture frameworks, and the review of architectural descriptions.

ISO/IEC WD1 42010 IEEE P42010/D1

Systems and Software Engineering — Architectural Description

1 Scope

The scope of this standard encompasses those products of system and software development that capture architectural information: architectural descriptions of general systems. This includes architectural descriptions that are used for the following: a) Expression of the system or software and its evolution b) Communication among the stakeholders c) Evaluation and comparison of architectures in a consistent manner d) Planning, managing, and executing the activities of development e) Expression of the persistent characteristics and supporting principles of a system or software to guide acceptable change f) Verification of an implementation’s compliance with an architectural description g) Recording contributions to the body of knowledge of systems and software architecture

General systems include those “systems that are man-made and may be configured with one or more of the following: hardware, software, data, humans, processes (e.g. processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities (e.g. water, organisms, minerals).” [ISO 15288]

1.1 Purpose

The purpose of this standard is to facilitate the expression, communication and review of architectures and thereby lay a foundation for quality and cost gains through standardization of elements of and practices for architectural description.

Systems continue to present formidable risks and difficulties in their design, construction, deployment, and evolution. Recent attempts to address these difficulties have focused on the earliest period of design decision- making and evaluation, the architectural level of concern in the system life cycle. The phrases architectural level of concern and architecture are widely, though imprecisely, used. Their use reflects acceptance of an architectural metaphor in the analysis and development of systems that acknowledge the long tradition of architectural thinking in building and civil engineering, to name just two precedents. A key premise of this metaphor is that important decisions are made early in system development in a manner similar to the early decision-making found in the development of civil architecture projects.

Many innovations result from this attention to the architecture, among them architectural description languages and associated tools and environments; architectural methods, architecture frameworks, models, and patterns; and techniques for architectural analysis, evaluation, and architecture-based reuse. These innovations are occurring, and maturing, rapidly within many research and application communities, and they reflect differing interests, influences, insights, and intentions. While these efforts differ considerably in

ISO/IEC WD1 42010 IEEE P42010/D1

important aspects, sufficient commonality exists to warrant the development of standards to codify their common elements.

Although there is a wide consensus on the importance of architecture within the systems life cycle, and its essential ingredients: early decision-making about overall design structure, goals, requirements, and development strategies, there has not yet emerged any reliable consensus on a precise definition of a system’s architecture, i.e., how it should be described, what uses such a description may serve, or where and when it should be defined. The boundaries and relationships between architectural trends and practices, and other practices, and between architectural technology and other technology, are not yet widely recognized.

In such situations, progress often depends on mediating influences. Potential adopters of architectural practices and technology can benefit from a conceptual framework, or frame of reference, within which to address implementation and adoption decisions. Technologists can similarly benefit from such a frame of reference within which to communicate the motivating concepts of their technology, relate it to other efforts and accumulate and appreciate feedback from early adoption.

To these ends, this standard is intended to reflect generally accepted trends in practices for architectural description and to offer a technical framework for further evolution in this area. Furthermore, it establishes a conceptual framework of concepts and terms of reference within which future developments in system architectural technology can be deployed. This standard codifies those elements on which there is consensus; specifically the use of multiple views, reusable specifications for models within views, and the relation of architecture to system context, recognition of the role of architectural frameworks as emerging bodies of knowledge, and an approach to the review and evaluation of architectural descriptions.

1.2 Field of Application

The principal users for this standard comprise stakeholders involved in processes throughout the system life cycle, including the following:

— Those that apply it to assist them to create, describe, and document architectures (architects)

— Those that use it during processes of, acquiring, owning, and operating a system to understand a system’s architecture (users, operators, and acquirers, customers or clients)

— Those that use it to assist them to interpret, analyze and understand architectural descriptions: to develop, deliver, and maintain the system (architects, designers, programmers, maintainers, testers, domain engineers, quality assurance staff, configuration management staff, suppliers, and project managers or developers)

— Those who oversee and evaluate systems and their development (chief information officers, auditors, and independent assessors)

— Those involved in the enterprise-wide infrastructure activities that span multiple system developments, including methodologists, process and process-improvement engineers, researchers, producers of standards, tool builders, and trainers, including those that seek to establish and codify architecture frameworks and architecture methods meeting the requirements herein.

1.3 Limitations

This standard is intended for use in the domains of general systems (as in ISO 15288) and software-intensive systems (as in ISO 12207); however, nothing in its content precludes its use for systems of interest outside of those domains.

ISO/IEC WD1 42010 IEEE P42010/D1

This standard imposes no requirements about life cycle processes, architecture methods, or languages, notations or models employed in architectural descriptions.

This standard does not impose requirements on the formats or media used for the physical capture of architectural descriptions.

2 Conformance

An architectural description conforms to this standard if that description meets the requirements listed in Clause 7.

An architecture framework conforms to this standard if that framework meets the requirements listed in Clause 8.

An architectural description conforms to a ISO 42010 architectural framework if (i) it conforms to the requirements of Clause 7, (ii) that framework conforms to the requirements of Clause 8 and that architectural description meets the requirements of 8.x.

Editor: The following statement is a design goal, but is not correct in the current draft because there are some requirements that refer to changes the “using organization” may make. This needs to be resolved in the spirit of ISO 12207 and 15288.

This standard is designed such that tailoring is neither required nor permitted for its use.

3 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 12207, Information Technology — Software Life Cycle Processes.

ISO/IEC 15288, Systems Engineering — System Life Cycle Processes.

ISO/IEC 15289, Systems and Software Engineering — Content of systems and software life cycle process information products (Documentation).

4 Terms and definitions

For the purposes of this document, the following terms and definitions apply.

4.1 architect The system stakeholder (i.e., person, team, or organization) responsible for systems architecture.

4.2 architecting The activities of conceiving, defining, documenting, maintaining, improving, and certifying proper implementation of an architecture.

ISO/IEC WD1 42010 IEEE P42010/D1

4.3 architectural description A collection of information products used to document an architecture.

4.4 architecture framework A set of architectural concerns, generic stakeholders, predefined viewpoints, and viewpoint correspondence rules, that have been established to capture a common practice for architectural descriptions in a specific domain or stakeholder community.

4.5 architectural model A module of an architectural view.

4.6 architectural view A representation of a whole system from the perspective of a related set of architectural concerns.

4.7 architectural viewpoint The conventions for constructing, interpreting and using an architectural view to frame a prescribed set of concerns for a set of stakeholders.

4.8 architectural rationale An explanation or justification for an architectural decision.

4.9 architecture The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Cf. The highest-level conception of a system in its environment.

4.10 environment (of a system) The context which determines the setting and circumstances of developmental, operational, political, regulatory, social, and other critical influences upon a system.

4.11 generic A placeholder in a viewpoint definition which must be instantiated before use in an architectural description. E.g.: generic stakeholder (6.3, 6.6), generic concern (6.3).

4.12 mission (of a system) A use or operation of a system to achieve one or more purposes or objectives.

4.13 scenario A use case, change case or other interaction between a system stakeholder and the system of interest reflecting one or more architectural concerns. Cf. ISO 15288: Scenarios are used to analyze the operation of the system in its intended environment.

ISO/IEC WD1 42010 IEEE P42010/D1

4.14 system of interest: The system whose architecture is under consideration in the context of this standard.

4.15 stakeholder (of a system): An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. Cf. ISO 15288: an individual or organization having a interest in a system or in its possession of characteristics that meet their needs and expectations.

4.16 (system) (architectural) concern An area of interest in a system pertaining to developmental, operational, political, regulatory, social, and other influences which is important to one or more system stakeholders.

4.17 view correspondence A named relation between elements of two architectural views within an architectural description, used to establish consistency or similar relationships that apply to the architecture being described.

4.18 viewpoint correspondence rule A contract between two architectural viewpoints, enforced on their respective views within an architectural description, in terms of a correspondence between elements identified in the two views; i.e. a template for a view correspondence that should be present between the actual views of an architectural description. See: view correspondence

5 Conceptual framework

This clause introduces a conceptual framework or, frame of reference, for architectural description. This conceptual framework establishes terms and concepts pertaining to the contents and use of architectural descriptions upon which requirements in subsequent clauses will be based.

NOTE Annex A provides additional discussion of the terms and concepts used in this standard within the context of the systems and software engineering communities.

5.1 Architectural description in context

Within this standard, system encompasses general systems (as in ISO 15288) and software-intensive systems (as in ISO 12207).

NOTE 1 The scope of systems considered by this standard include: (i) “general systems” which are “man-made, created and utilized to provide products and / or services in defined environments for the benefit of users and other stakeholders [using] hardware, software, data, humans, processes and procedures, facilities, materials and naturally occurring entities (e.g. water, organisms, minerals). In practice, they are thought of as products or services.” and (ii) “software-intensive systems”: those systems where software plays a dominant or pervasive role: individual applications, systems in the sense of (i), subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest [see ISO/IEC 12207].

A system inhabits an environment. The environment bounds the setting and circumstances of developmental, operational, political, and other influences upon that system. A system’s environment influences that system; and that system acts upon its environment.

ISO/IEC WD1 42010 IEEE P42010/D1

There are one or more stakeholders of a system within its environment. A stakeholder is any party that has interests in that system.

The environment determines the boundaries that define the scope of the system of interest relative to other systems. The environment of a system can be understood in terms of its stakeholders and their concerns.

Editor: Are systems stakeholders? The environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. Therefore, systems may be stakeholders of a system, too.

Concerns are areas of interest in a system pertaining to that system’s development, its operation or any other environmental influences that are critical or otherwise important to one or more stakeholders.

EXAMPLE 1 Familiar system concerns include: functionality, performance, reliability, security, distribution, evolvability, openness, concurrency, autonomy, quality of service, flexibility, modifiability, modularity, inter-process communication, deadlock, state change, subsystem integration, data accessibility, and distribution transparencies [ISO 10746–1] such as access transparency; failure transparency; location transparency; migration transparency; persistence transparency; relocation transparency; replication transparency; transaction transparency.

NOTE 2 A concern names an area of interest on the part of one or more stakeholders with respect to a system. This area of interest may result in one or more related stakeholder needs, goals, system requirements, design constraints, quality attributes or risks related to the system. A concern may arise from the “problem space” of client or user requirements or the “solution space” of previously decided issues.

EXAMPLE 2 The statement, (a) The system shall be blue, could be a system requirement. The statement, (b) Good colors are important, could be a goal set by the system’s client or acquirer. Both (a) and (b) pertain to the system concern named color.

NOTE 3 This standard says nothing about the granularity of system or architectural concerns, about how concerns relate to stakeholder needs, goals, requirements, risks, or other such statements, or about how concerns may be interrelated to other concerns. These are topics best addressed within the context of specific architectural methods or practices.

A system exists to fulfil one or more missions in its environment. A mission is a use or operation for which a system is intended by one or more of its stakeholders to meet some purpose or objectives within its identified concerns.

An architecture is the highest-level, i.e., fundamental conception of a system in its environment. In this sense, every system has an architecture, and perhaps more than one.

An architecture of a system can be documented with an architectural description.

In this standard, the term system of interest (or simply, system) refers to the system whose architecture is under consideration for the preparation of an architectural description.

This standard distinguishes the architecture of a system, which is a concept, from architectural descriptions, which are concrete, tangible artefacts or information products. Architectural descriptions (ADs) are the subject of this standard.

NOTE 4 There are no requirements in this standard pertaining to the concepts: Architecture, System, Environment, and Mission (which are shown in Figure 1).

An architectural description is organized into one or more constituents called architectural views. Each architectural view (or simply, view) addresses some of the architectural concerns held by the stakeholders of that system. An architectural view is an expression of a particular system’s architecture with respect to a particular architectural viewpoint.

ISO/IEC WD1 42010 IEEE P42010/D1

NOTE 5 This standard does not use terms such as “business architecture”, “physical architecture”, and “technical architecture”, as are frequently used informally to refer to various descriptions of particular systems. Within the conceptual framework of this standard, the approximate equivalents of these informal terms would be “business view”, “physical view”, and “technical view”, respectively.

An architectural viewpoint (or simply, viewpoint) establishes the conventions by which an architectural view is created, depicted, interpreted and analyzed. These conventions include the languages, notations, and model types used to describe the view, and any modelling methods, analysis techniques, or other operations applicable to the view. An architectural description selects one or more viewpoints for use. Each viewpoint allows the expression of some the system’s architectural concerns to be addressed and the stakeholders holding those concerns.

Editor: Are “proxy” stakeholders adequately covered by current conceptual model? Lankes: I understood that the corresponding views are intended to be used by one or more stakeholders. My question is, how this incorporates users of views that are not among the stakeholders of a system. Specifically, I think of a situation where certain stakeholders do not use the architectural description themselves but are supported by some external experts, that have no direct stake in the systems themselves. An example for such external experts would be the evaluation team in the ATAM.

An architectural viewpoint definition may originate with an architectural description, or it may have been defined elsewhere. A viewpoint that is defined elsewhere is referred to in this standard as a predefined viewpoint.

NOTE 6 In the predecessor of this standard (ANI/IEEE Std 1471:2000), a predefined viewpoint was referred to as a library viewpoint.

An architectural view is composed of one or more architectural models. Architectural models are used to construct architectural views in a modular fashion. Each model can use a different language, notation or model type. Each such architectural model is sanctioned by its associated architectural viewpoint. An architectural model may participate in more than one view to enable sharing of concern-related details across views, without repetition.

Editor: Still to be discussed in next working draft: correspondences between views (6.5), architectural rationales (6.6) and architecture frameworks (7).

Figures 1 and 2 provide a summary of the key terms and concepts used in this standard and their inter- relationships. Figure 1 depicts key concepts of systems and their architectures. Figure 2 presents terms and concepts in the context of producing an architectural description of an architecture for a specific system of interest—not to assume or require that a system has only one architecture or that there can only be one architectural description depicting that architecture.

NOTE 7 The conceptual model defined here is sometimes referred to as the metamodel of architecture description.

ISO/IEC WD1 42010 IEEE P42010/D1

Figure 1 — Conceptual model of architectural description: Conceptual Realm (informative)

ISO/IEC WD1 42010 IEEE P42010/D1

Figure 2 — Conceptual model of architectural description: Core Realm (normative)

NOTE 8 In figures 1 and 2 boxes represent classes of things. Lines connecting boxes represent associations between things. An association has two roles (one in each direction). A role can optionally be named with a label. The role from A to B is closest to B, and vice versa. For example, in Figure 1, the roles between System and Environment can be read: “A system inhabits an environment, and an environment influences a system.” In the figure, roles are one-to-one unless otherwise noted. A role can have a multiplicity, e.g., a role marked with “1..*” is used to denote many, as in a one-to-many or many-to-many association. A diamond (at the end of an association line) denotes a part-of relationship. For example, views are a part of an architectural description. This notation is from the Unified Modelling Language [UML].

ISO/IEC WD1 42010 IEEE P42010/D1

Editor: Text version of the conceptual model.

System fulfils 1..* Mission(s)

System inhabits Environment

Environment influences System

System has 1..* Architecture(s)

System has 1..* Stakeholder(s)

Architecture is described by 0..* Architecture Description(s)

System Of Interest has 1 Architecture

Architectural Description identifies 1..* Concern(s)

Architectural Description identifies 1..* Stakeholder(s)

Architectural Description organized into 1..* View(s)

Architectural Description selects 1..* Viewpoint(s)

Architectural Description offers 0..* Rationale(s)

Stakeholder holds 1..* Concern(s)

Concern is important to 1..* Stakeholder(s)

Viewpoint addresses 1..* Stakeholder(s)

Viewpoint frames 1..* Concern(s)

Viewpoint governs View

Viewpoint sanctions 1..* Model(s)

View conforms to Viewpoint

View composed of 1..* Model(s)

Model participates in 1..* View(s)

Viewpoint cites 0..1 Predefined Viewpoint

ISO/IEC WD1 42010 IEEE P42010/D1

5.2 Stakeholders and their roles

Various stakeholders are involved with regard to the creation and use of architectural descriptions. These stakeholders include clients, users, the architect, developers, and evaluators.

Two key stakeholders are the acquirer (or client) and the architect.

The architect creates and maintains an architecture for a system for the acquirer. The architect may work from requirements provided by an acquirer or may be responsible for eliciting and developing requirements as part of the architecture development.

The role of the acquirer can be filled by a buyer, customer, owner, user, or purchaser [ISO/IEC 15288, ISO/IEC 12207].

The architect records the architecture in an architectural description. In this form, the architecture serves to guide the system’s developers, steer the downstream development, construction, deployment, operation and evolution of the system.

5.3 Architectural activities in the life cycle

Architecting contributes to the development, operation, and maintenance of a system from its initial concept until its retirement from use. As such, architecting is best understood in a life cycle context, not simply as a single activity at one point in that life cycle.

Architecting is concerned with developing satisfactory and feasible system concepts, maintaining the integrity of those system concepts through development, certifying built systems for use, and assuring those system concepts through operational and evolutionary phases.

Detailed systems engineering activities, such as detailed requirements definition and interface specification and the architecting of major subsystems are tasks that typically follow development of the system architecture.

This standard neither assumes nor prescribes a specific life cycle model—a life cycle model is to be separately chosen by users of the standard. The scenarios below are intended to suggest the range of uses of the standard within a system life cycle.

System architecture potentially impacts all processes within the system life cycle. Examples of these impacts are shown in Table 1 [ISO/IEC 15288, Figure 4].

ISO/IEC WD1 42010 IEEE P42010/D1

Editor: this table needs to be filled out, and aligned with 5.4.

Agreement Project-Enabling Project Technical Processes Processes Processes Processes Acquisition Life Cycle Model Project Planning Stakeholder Management Requirements Definition Supply Infrastructure Project Requirements Management Assessment and Analysis Control Project Portfolio Decision Architectural Management Management Design Human Resource Rick Management Implementation Management Quality Configuration Integration Management Management Information Verification Management Measurement Transition Validation Operation Maintenance Disposal

Table 1 — Impacts of Architecture on Life Cycle Processes

5.3.1 Scenario: architecture of single systems

For new system construction, in cases where the user and the acquirer are identical, architecting is carried out in response to the user-acquirer’s vision for the system, the system goals, and stakeholders’ needs and constraints. The primary stakeholders are the user-acquirer and the system developers.

The architectural description can be used throughout the life cycle to aid in developing predictions of the fitness for use of a system whose architecture complies with the architectural description or to assess how well architectural concerns have been addressed (e.g., performance). In addition, the architectural description will typically evolve throughout the life cycle, and can serve as a means for assessing changes to the system.

5.3.2 Scenario: iterative architecture for evolutionary systems

Under this scenario, the architecture, the delivered systems, and the stakeholders co-evolve. An initial architecture is conceived of in response to current and expected user needs using current and estimated technological capabilities. Initial systems are delivered using this architecture. As the architecture evolves in response to new stakeholders’ needs, systems are delivered based on the architecture current at the time of development. Likewise, the set of stakeholders in the systems and architecture will change as the architecture evolves.

ISO/IEC WD1 42010 IEEE P42010/D1

For evolutionary systems, the architectural description is used for system development and evaluation, but its uses and development are concurrent. Stakeholder needs are reassessed with each iteration of the architecture; the architectural description is used to guide each system as it moves through development, and appropriate architectural description versions are used to evaluate each system on delivery. Architectures developed under this scenario will naturally emphasize flexibility and adaptability more strongly than single system architectures. Architectural descriptions for evolving systems will typically be developed in an iterative pattern, or rhythm, of version changes.

The architecture development will normally be carried out by the developer as part of the overall activity of developing a sequence of systems. The architecture can also be established by the acquirer as a way of organizing the acquisition and evolution of a sequence of systems. This approach is one way to evolve a product line architecture. Evolution of the architecture will normally be sponsored by the acquirer as a part of the overall activity of sequential development or, in the case of commercial-off-the-shelf software, deployment of systems.

5.3.3 Scenario: architecture of existing systems

A third scenario occurs when system development has taken place without an architectural description, or when the architectural description, and perhaps the architect, are no longer available. The built system will have an architecture (since every system has an architecture, whether known or not) but it will lack an architectural description. In this case, an architectural description can be created through a reverse- engineering effort.

Using this standard, an architectural description of the existing system is first constructed. This architectural description is then used to develop a new system, to guide maintenance or evolution activities, or to establish an evolutionary architecture as in the scenarios above (see 5.3.1 and 5.3.2).

In some cases, a new architectural description is needed because the original description does not provide views that are necessary later in a system’s life cycle.

5.3.4 Scenario: architectural evaluation

The purpose of evaluation is to determine the quality of an architectural description and to predict the quality of systems whose architectures conform to the architectural description.

Quality of an architectural description refers to its capability to meet the needs and concerns of the stakeholders for whom it was constructed. Such concerns typically include understandability, consistency, completeness, and analyzability of the description.

Prediction of the quality of systems resulting from the architectural description includes such qualities as feasibility, efficiency, and reliability.

In order to evaluate conformance of an architecture to an architectural description, a process for reverse engineering an architectural description from an implementation is needed (see 5.3.3).

5.3.X New Scenario(s):

System/Technology Insertion/Evolution in a System of Systems Environment. Use of architecture in support of governance (management) activities for a System of Systems should be considered as another use case. One of the important considerations for such Systems is the influence of the inserted or evolved system on its environment, for instance through the creation of new or modified interfaces with related systems.

ISO/IEC WD1 42010 IEEE P42010/D1

Product Line Architecture. Is there a new scenario here? Perhaps relevant to 6.7? Suppose I'm building a product line architecture (PLA). Each product will also have an architecture, derived from the PLA by (for instance) component replacement or replication or omission, or maybe re-writing some of the connections. The PLA itself doesn't actually correspond to any architecture. Only the instance architectures do. I want to document this situation as follows. I want to write an AD for the PLA. Then I want the AD for each instance architecture to be a two-sentence "delta" off the PLA AD. ("Take the PLA but replace C3 and C4 with C18.") I'm not sure the conceptual framework works for me in this case, especially the part that maps systems to architectures to ADs.

Editor: Consider Architectural Knowledge (AK) Use cases?

5.4 Uses of architectural descriptions

Architectural descriptions are applicable to a variety of uses, by a variety of stakeholders, throughout the life cycle. These uses include, but are not limited to, the following:

Editor: The following list should be updated in concert with Table 1 above. a) Analysis of alternative architectures b) Business planning for transition from a legacy architecture to a new architecture c) Communications among organizations involved in the development, production, fielding, operation, and maintenance of a system d) Communications between acquirers and developers as a part of contract negotiations e) Criteria for certifying conformance of implementations to the architecture f) Development and maintenance documentation, including material for reuse repositories and training materials g) Input to subsequent system design and development activities h) Input to system generation and analysis tools i) Operational and infrastructure support; configuration management and repair; redesign and maintenance of systems, subsystems, and components j) Planning and budget support k) Preparation of acquisition documents (e.g., requests for proposal and statements of work) l) Review, analysis, and evaluation of the system across the life cycle m) Specification for a group of systems sharing a common set of features, (e.g., product lines)

6 Architecture description practices

This clause defines practices of architectural description that enable the uses outlined in Clause 5. An architectural description conforming to this standard meets the requirements set forth in this clause.

ISO/IEC WD1 42010 IEEE P42010/D1

Architectural descriptions conforming to this standard will include the following elements of content, as delineated in the remainder of this clause: a) architectural description identification, version, and overview information (see 6.1) b) Identification of the system stakeholders and their concerns determined to be relevant to the architecture (see 6.2) c) a definition of each viewpoint that has been selected to organize the representation of the architecture and the rationale for those selections (see 6.3) d) One or more architectural views (see 6.4) e) Any correspondences defined between architectural views, and a record of all known inconsistencies among the architectural description’s required constituents (see 6.5) f) The rationales for architectural choices and decisions made about the architecture (see 6.6)

NOTE 1 This standard does not specify a delivery format for an architectural description.

NOTE 2 Annex B suggests an outline template for architectural descriptions conforming to this standard.

6.1 Architectural documentation

Editor: In IEEE 1471:2000, this subclause was written for the sake of alignment with IEEE/EIA 12207. It should be updated somehow to align with ISO 12207 and ISO 15288. Does ISO 15289 help us here?

An architectural description shall contain the following information pertaining to the architectural description as a whole: a) Date of issue and status b) Issuing organization c) Change history d) Summary e) Scope f) Context g) Glossary h) References

The detailed form and content of the corresponding information items shall be determined by the using organization. These items were selected to allow users to satisfy the requirements of IEEE/EIA Std 12207.0– 1996.

ISO/IEC WD1 42010 IEEE P42010/D1

6.2 Identification of stakeholders and concerns

An architectural description shall identify the system stakeholders considered by the architect in formulating the architecture for the system.

The following generic system stakeholders shall be considered, and instantiated within the architectural description, when applicable:

— Users of the system

— Acquirers of the system

— Developers of the system

— Maintainers of the system

An architectural description shall identify the architectural concerns considered by the architect in formulating the architecture for the system.

The following generic architectural concerns shall be considered, and instantiated within the architectural description, when applicable:

— The purpose or missions of the system

— The appropriateness of the system for use in fulfilling its missions

— The feasibility of constructing the system

— The risks of system development and operation to users, acquirers, and developers of the system

— Maintainability, deployability, and evolvability of the system

— Factors that may constrain the architecture

The specific intent of the generic stakeholders and generic architectural concerns listed in this clause will vary from system to system. An architectural description must therefore instantiate those generic stakeholders and concerns with actual stakeholder and concerns identified for the environment of the system of interest.

6.3 Selection of architectural viewpoints

An architectural description shall identify each of the architectural viewpoints selected for use therein.

Each architectural viewpoint shall be defined by a) a viewpoint name; b) the stakeholders to be addressed by the viewpoint; c) the architectural concerns framed by the viewpoint; d) the languages, modelling techniques, or analytical methods to be used in constructing a view based upon the viewpoint;

ISO/IEC WD1 42010 IEEE P42010/D1

e) a description of any rules and constraints upon the architectural models participating in the resulting view; f) the source, for a predefined viewpoint (the source could include author, date, or reference to other documents, as determined by the using organization).

A viewpoint definition may include additional information on architectural practices for using the viewpoint to create resultant architectural views, as follows:

— Consistency and completeness tests to be applied to architectural models of a resultant view (e.g., 6.5)

— Evaluation or analysis techniques to be applied to the architectural models of a resultant view

— Heuristics, patterns, or other guidelines to assist in synthesis of a resultant view

Viewpoint definitions may be incorporated into the architectural description of the system of interest either by inclusion or by reference (such as to a suitable standard or previously defined practice).

There shall be exactly one architectural view in an architectural description for each selected architectural viewpoint.

Each architectural concern identified in an architectural description in accordance with 6.2 shall be framed by at least one viewpoint selected in accordance with 6.3.

More than one viewpoint may be required to address the architectural concerns held by particular system stakeholder within an architectural description.

More than one viewpoint may be required to address a particular architectural concern within an architectural description.

NOTE 1 The standard does not require that any particular viewpoints be selected by an architectural description. However, the rationale for selection of the viewpoints (per 6.6) must show that the selected viewpoints cover the minimum set of stakeholders and concerns to be considered (per 6.2).

NOTE 2 It is envisioned that through the selection of suitable viewpoints, an architectural description can achieve conformance with other architectural development standards and practices (see 7).

NOTE 3 Annex C contains examples of architectural viewpoint definitions.

6.4 Architectural views

An architectural description shall contain one or more architectural views.

Each architectural view in an architectural description shall be governed by exactly one architectural viewpoint, as selected in accordance with 6.3.

Each view in an architectural description shall conform to the definition of its corresponding viewpoint.

Each view shall include: a) An identifier and other introductory information, as defined by the using organization b) A representation of the whole system using one or model architectural models and constructed in accordance with the languages, methods, and modelling or analytical techniques of the associated viewpoint, addressing the concerns framed by the associated viewpoint

ISO/IEC WD1 42010 IEEE P42010/D1

c) Configuration information, as defined by the using organization

An architectural description may also include other architectural information as a result of an organization’s documentation practices, which is not properly contained in any of its architectural views. Examples of such information are the system overview, …, and the architectural rationale.

The requirement that architectural views depict the whole system is essential to the complete allocation of concerns within an architectural description. Architectural models, within views, can be used to selectively present portions of the system to highlight points of interest.

NOTE 1 In a complex system, architectural descriptions may be developed for components of the system, as well as for the system as a whole. In this case, it may be that one architectural description will have a view corresponding to a particular viewpoint and another architectural description will have a view corresponding to the same viewpoint. Although the system being described by these two views has the whole-part relationship, this is not an instance of multiple views corresponding to one viewpoint because each view has been developed for a different system of interest. The architectural descriptions are considered separate even though they are related by the systems they describe.

NOTE 2 What is called in this standard an architectural view is sometimes referred to as a “viewpoint specification”: the application of a viewpoint to a specific system in RM-ODP [ISO/IEC 10746-2].

6.4.1 Architectural Models

An architectural view shall consist of one or more architectural models.

Architectural models provide a mechanism to modularize architectural views. There are cases when a view may need to use more than one language, notation or modelling technique to address all of the concerns assigned to it. To do this, a view may consist of multiple architectural models. Each model may use a distinct language, notation, or model type, as defined by its viewpoint.

EXAMPLE A Project Management viewpoint frames concerns about project organization, project activities and tasks, project schedule and project cost. It defines four kinds of models to be used in resultant views: organization charts, work breakdown structures, Gantt schedule-dependency charts, and budget spreadsheets.

There are cases when it is useful to share architectural details across two or more views, e.g., to address distinct but related architectural concerns. An architectural model permits this sharing without redundancy (repetition of the information in two different views).

Editor: Do we need identifying attributes on architectural models, as on ADs and views?

Architecture Model: name, configuration information, ...

If so, then as long as we are already requiring such attributes, it seems user-defined attributes would be one way to allow viewpoints to explicitly specify things about models. A viewpoint could introduce a model attribute, and specify rules for same. This would be a lighter-weight change than Mark Gerhardt has suggested: the need for “model types” by analogy with views and viewpoints:

views : viewpoint :: models : model type

NOTE Sharing of models facilitates an “aspect-oriented” style of architectural description. An architectural model shared across architectural views can be used to capture an architectural perspective [RW]. An architectural model shared within an architectural view can be used to capture an architectural texture [Ran].

6.5 Consistency among architectural views

An architectural description shall record any known inconsistencies among its architectural views.

ISO/IEC WD1 42010 IEEE P42010/D1

An architectural description should contain an analysis of consistency across all of its architectural views.

The remainder of this subclause defines a mechanism that may be used to express and analyze consistency and other relations between architectural views.

6.5.1 View Correspondences

A view correspondence records a relation between two architectural views. A view correspondence may be used to capture a consistency relation, a traceability relation, a constraint or obligation of one view imposed upon another, or other relations relevant to the architecture being described.

A view correspondence may be an instance of a viewpoint correspondence rule (6.5.2).

A view correspondence used in an architectural description shall (i) have a name; (ii) identify its associated viewpoint correspondence rule, if any; and (iii) uniquely identify each participating element.

EXAMPLE Consider two views of a system, S, a hardware view, HW(S), and a software component view, SC(S). If SC(S) includes software elements, e1, … e6, and HW(S) includes hardware platforms, p1, … p4, a view correspondence expressing which software elements execute on which platforms might be:

ExecutesOn = { (e1, p1), (e1, p4), (e2, p2), (e2, p3), (e3, p3), (e4, p4) }

Editor: additional examples could be layered dependencies, and traceability.

6.5.2 Viewpoint Correspondence Rules

A viewpoint correspondence rule makes a contract between two architectural viewpoints. This contract is enforced on their respective views within an architectural description in terms of relations on the elements of the two views.

A viewpoint correspondence rule is a template for a view correspondence (6.5.1).

When an architectural description selects viewpoints for use (6.3), the architectural description shall identify any viewpoint correspondence rules that apply.

For each viewpoint correspondence rule that applies to an architectural description, there shall be a view correspondence identified.

A viewpoint correspondence rule holds in an architectural description if its associated view correspondence can be shown to satisfy the rule.

A view correspondence violates a viewpoint correspondence rule if its associated view correspondence can be shown not to satisfy the rule.

An architectural description shall document for each applicable viewpoint correspondence rule whether it holds, and if not, all known violations.

EXAMPLE Consider two viewpoints, Hardware and Software Components. A viewpoint correspondence rule might be as follows:

Every software element, ei, as defined by Software Components must execute on one or more platforms, pj, as defined by Hardware.

ISO/IEC WD1 42010 IEEE P42010/D1

Notice that the view correspondence ExecutesOn from the previous example violates this rule because some software elements of SC(S) (namely e5, e6) have not been assigned to execute on any platform.

A viewpoint correspondence rule may be established within the context of an individual architectural description or provided as a part of an architectural framework (7) or as part of an organization’s architectural practices.

NOTE Mathematically a view correspondence is a binary relation between terms or elements of two architectural views. A viewpoint correspondence rule is an (intensional) definition of a binary relation. They are defined as binary relations because this seems the most natural way of stating and working with most correspondences, although mathematically equivalent to n-ary relations. Binary relations include 1-1 mappings (isomorphisms) and functions as special cases, both of which are too restrictive for many correspondence applications. Relations have useful mathematical properties of composition and reasoning, can be efficiently represented and manipulated [REFS]. This standard does not specify the mechanisms for capturing view correspondences or for stating viewpoint correspondence rules. The standard does not define what constitutes a term or element of a view in the definitions of correspondence above.

Editor: It seems the correspondences and rules could/should also apply between models within views.

6.6 Architectural rationale

Editor: Material for this subclause is based on useful inputs from SHARK and P. Clements. Refer to Figure 3:

An architectural rationale (or simply, rationale) is an explanation or justification for an architectural decision. A rationale explains the basis for the decision, the reasoning that led to the decision, the trade-offs that were considered, the impact of the decision including its pros and cons, and points to further sources of information.

An architectural decision (or simply, decision) is a choice that addresses one or more architectural concerns, and affects (directly or indirectly) the architecture.

A decision may address (in full or partial) more than one concern. A decision may affect the architecture in several ways: existence of an architectural entity, the property of some architectural entities, ... In most cases a decision provides a trace between architectural elements and concerns. A decision may raise additional concerns.

Like architectural concerns (5.1), there are architectural decisions related to the problem space and not solely on the solution space. For example, prioritization of concerns is an architectural decision (though not strictly speaking a design decision).

ISO/IEC WD1 42010 IEEE P42010/D1

Figure 3 — Architectural Rationale

6.6.1 Levels of Architectural Rationale

Decisions may be made with respect to any of the constructs of the Core model (Figure 2). There may be decisions about stakeholders: which are architecturally relevant, which are not, which may be grouped together; about concerns: which concerns are architecturally significant, which are not, which may be combined or interrelated; but most decisions will relate to the constructs in the “hierarchy”: viewpoints, views and models. Therefore, there can be rationales may be used to explain decisions at each of these “levels” within an architectural description, following the “levels” of abstraction/aggregation of AD content.

“The rationale” for the architecture is made of the collection of all the rationale (instances) for all the decisions (instances) from each of these levels.

Viewpoint Rationale

An architectural description shall include a rationale for the selection of each viewpoint.

ISO/IEC WD1 42010 IEEE P42010/D1

The viewpoint rationale shall address the extent to which the stakeholders and concerns required to be identified in 6.2 are covered by the viewpoints selected in accordance with 6.3.

View Rationale

It is difficult to provide detailed requirements at the view and model levels of rationale, because the particulars will depend on the specific viewpoint and model languages used. Examples: What styles, patterns? reference model?

Model Rationale

An architectural description shall include rationales for key architectural decisions selected.

An architectural description should provide evidence of the consideration of alternatives and the rationale for the key choices made.

When the architectural description describes a system that pre-exists the development of the architectural description, the rationale for the legacy system architecture shall be presented, if known.

6.6.2 Decision Capture and Tracking

An AD may choose to capture the decision that led to the choices of architectural elements at any of the levels described above.

Useful process reference: ISO/IEC 15288, 6.3.3 Decision-Making:

1) Record, track, evaluate and report decision outcomes to confirm that problems have been effectively resolved, adverse trends have been reversed and advantage has been taken of opportunities.

2) Maintain records of problems and opportunities and their disposition, as stipulated in agreements or organizational procedures and in a manner that permits auditing and learning from experience.

OUTCOMES

— A decision management strategy is defined.

— Alternative courses of action are defined.

— A preferred course of action is selected.

— The resolution, decision rationale and any assumptions are captured and reported.

If an architectural description chooses to capture decisions, then each decision shall be captured with the following:

— each decision shall be uniquely identified;

— each decision shall be linked to the architectural concerns it addresses;

— the owner of the decision shall be identified (usually the architect);

— decision shall be linked to elements, models, and views impacted by the decision;

ISO/IEC WD1 42010 IEEE P42010/D1

— there shall be rationale linked to each decision.

Some Heuristics

It is not practical to require the capture of every decision. It is useful as a part of a decision strategy, to establish criteria for which kinds of decisions should be supported with rationales. Examples of criteria could be: decisions about architecturally significant requirements, major effort or time needed to make the decision, number of stakeholders affected, etc.

It can be useful to capture rejected alternatives and the rationales for their rejections. It may be the case in the future that these reasons will no longer apply.

Extra credit: Decisions are interrelated, and there are many different types of dependencies between decisions: constrains, enables, subsumes, conflicts, etc. relations labelled in this manner. Simplest: trace/interconnect decisions in the order that they are made, e.g., via timestamps.

6.7 Architectural Descriptions of Multiple Systems of Interest

Editor: This is a placeholder in case we come up with anything special to say about situations where there are multiple, related systems of interest. It would be moved to an annex if not normative.

Consider a collection of systems, S1, S2, ..., Sn. Suppose those systems are in some known relationship to one another. Some common situations would be:

— S1, through Sn are subsystems of a singular system S

— S1 through Sn are the system-of-interest and its enablers [in a 15288-style relationship]

— S1 through Sn are different concepts of a system S, one of which will be selected for implementation

— S1 through Sn are jointly developed and produced as part of product-line or family-of-systems or federation

— S1 through Sn interact with each other to produce system S, but also standalone and do their own things

A Possible Definition. Two systems, Sa and Sb, are architecturally related when there are stakeholders Pi holding architectural concerns Cj that overlap between Sa and Sb.

A Possible Rule: If two systems are architecturally related by concerns Ck, then the viewpoints selected for framing those concerns SHALL be the same, in each system's AD.

7 Architecture Frameworks

7.1 Reference Model and General Concepts

An architecture framework establishes a common practice for creating, organizing, interpreting and analyzing architectural descriptions used within a particular domain of application or stakeholder community. To do this, the architecture framework identifies a set of architectural concerns, generic stakeholders holding these concerns, and one or more predefined architectural viewpoints which frame these concerns. Architectural frameworks use generic stakeholders to motivate the concerns in the predefined viewpoints defined by the architectural framework. In a predefined viewpoint, a generic stakeholder is identified to establish concerns

ISO/IEC WD1 42010 IEEE P42010/D1

that the predefined viewpoint frames. Generic stakeholders are instantiated as specific stakeholders within an actual architectural description.

The definition of each predefined viewpoint in a framework follows the requirements given in 6.3

An architecture framework may also define viewpoint correspondence rules (6.5) to relate its predefined viewpoints.

Figure 4 —Architecture Frameworks

An architecture framework definition shall include:

— the identification of one or more architectural concerns;

— the identification of one or more generic stakeholders holding those architectural concerns;

— the definition of one or more (predefined) architectural viewpoints which frame those architectural concerns; and

— the definition of zero or more viewpoint correspondence rules over those viewpoints.

When the definition of an architecture framework includes a metamodel, that metamodel shall reflect the Core Model (Figure 2).

A metamodel M1 reflects a metamodel M0 if and only iff: all the classes in M0 occur in M1, and all the class associations in M0 occur in M1, with the same roles and multiplicities.

NOTE The motivation for this definition and associated requirements on architecture framework is to provide a means to define existing and future architecture frameworks in a uniform manner. Providing a uniform basis for defining architecture frameworks permits sharing of information across frameworks, inter-working and therefore understanding and interoperability between working architecture communities using different conceptual bases at this time. If viewpoints can be defined in a consistent manner, reuse of tools, techniques across frameworks is possible.

ISO/IEC WD1 42010 IEEE P42010/D1

EXAMPLES Existing practices which could be documented as conforming architectural frameworks include: enterprise architecture frameworks such as Zachman’s information architecture framework [Z], UK Ministry of Defence Architecture Framework [MoDAF], The Open Group’s Architecture Framework [TOGAF]; architecture methods such as: Kruchten’s “4+1” view model [4+1] and the “Siemens method” [HNS]; and architectural practices embodied in other ISO standards such as, RM ODP [ISO 10746], GERAM [ISO 15704 and ISO (FDIS) 19439].

An architectural description, AD, conforms to an architecture framework, AF, if and only if:

— AD conforms to the requirements of clause 6 for any architectural description;

— the architectural concerns identified in AD (6.2) include those defined by the framework AF;

— each of the generic stakeholders of AF has been instantiated among the identified stakeholders in AD (6.2); [too strong?]

— there is a conforming architectural view (6.4) in AD for each predefined viewpoint in the framework AF; and

— there is a view correspondence (6.5) in AD for each viewpoint correspondence rule defined by the framework AF.

NOTE An architectural description could conform to zero, one or more architecture frameworks. It is logically possible for a given architectural description to conform to more than one framework: that would imply some reconciliation between each framework’s set of generic stakeholders, concerns and predefined viewpoints and viewpoint correspondence rules.

NOTE A framework must define at least one predefined viewpoint therefore, that architecture framework must identify at least one concern for that predefined viewpoint, and at least one (generic) stakeholder holding that concern.

ISO/IEC WD1 42010 IEEE P42010/D1

Annex A (informative)

Notes on terminology

This standard makes use of several terms, concern, architecture, architectural view, and architectural viewpoint, which reflect community consensus, but are nevertheless employed in ways differing from some current usages of those same terms. This annex discusses the terms to make clear the fundamental concepts of the standard.

A.1 Concerns

The standard uses the term concern, as in architectural concerns, to capture “areas of interest in the system”. The motivation of this term comes from the use of the phrase “separation of concerns” in software and systems engineering, which appears to have been coined by Edsger W. Dijkstra in 1974 [D].

Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called “the separation of concerns”, which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by “focussing one’s attention upon some aspect”: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect’s point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.

The idea in the Standard is that each architectural viewpoint frames one or more concerns; separating their treatment by the resultant view from that of other concerns using other viewpoints and thereby allowing interested stakeholders to focus on a few things at a time. The literature of systems and software engineering records a large inventory of such concerns [REFS].

Although concerns can include system risks, the term should not be taken to be synonymous with “worries”.

A.2 Architecture

In the standard, architecture is intended as the essential conception of a system in its environment; defined as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This definition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system’s utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships. In other cases, these elements are not physical, but instead, logical components. In still other cases, these elements are overarching principles or patterns that create enduring organizational structures. The definition is intended to encompass these distinct, but related uses, while encouraging more rigorous definition of what constitutes the fundamental organization of a system within particular domains.

Recent empirical work by Smolander suggests that there are four metaphors for architecture which are found to be prevalent in software organizations [Smo]:

ISO/IEC WD1 42010 IEEE P42010/D1

— architecture as blueprint

— architecture as literature

— architecture as language

— architecture as decision

The conceptual framework of the standard is neutral with respect to these; and appears to work equally well under any of these. The existence of these various metaphors in organizations validates a central design tenet of the standard that architecture is inherently based upon multiple stakeholders with multiple concerns.

A.3 Models and Architectural Models

Models and modelling underlie much of systems and software engineering, and therefore systems and software architecture, too.

The notion of model is central to understanding this standard. Different communities define “model” in different ways. Therefore, it is important to understand the sense of the term underlying this standard:

X is a model of Y if X can be used to answer questions about Y. 1

The definition tells us every model has a subject. It also allows that X can be any thing: some things are concepts; some things are tangible artefacts in the world. Therefore, there are conceptual models and concrete models, too.

In the standard, model is used in two ways. First, it is used both in its informal, ordinary language, sense as explained above. Second, it is used in a specialized sense to define a key element of architectural practice, as in the term architectural model (4.x).

An architecture is a (conceptual) model of the system – useful for answering certain questions about that system and not others.

However, in the standard, we are most interested in concrete models, captured as tangible artefacts; there are three kinds of concrete models, each with different purposes, and therefore different question sets:

— an architectural description is a model of the architecture; Purpose: to answer all identified stakeholders’ questions about all identified architectural concerns for the system of interest;

— an architectural view is a model which is a major organizational part of an architectural description; Purpose: to address a specific set of stakeholder concerns from a specified viewpoint;

— an architectural model is a model addressing one or more concerns by contributing to one or more views. Purpose: modularize a view, introduce additional notation, depict an aspect, share detail across views.

1 This practical definition seems to have come from the (famous) MIT Research Lab for Electronics (RLE), in (the infamous) MIT Building 20 during the 1960s. It appears in the work of D.T. Ross and M. Minsky, who were both at RLE during that time period. “To an observer B, an object A∗ is a model of an object A to the extent that B can use A∗ to answer questions that interest him about A.” Marvin Minsky, Matter, Mind and Models, 1968. “M is a model of A with respect to question set Q if and only if M may be used to answer questions about A in Q within tolerance T.” Doug Ross, Technical Foundations for Characterizations, 1977.

ISO/IEC WD1 42010 IEEE P42010/D1

A.4 Architectural Views and Viewpoints

The terms architectural view and architectural viewpoint are central to the standard. Within the conceptual framework of the standard they refer to distinct things, and their definitions vary from some current uses of those terms. Their definitions do, however, reflect established usage in standards and engineering practice. These notes discuss the two concepts to motivate the distinction and to justify the need for both terms.

It is a basic goal of the standard to encompass existing architectural description practices by providing common terminology and concepts. A fundamental observation is that many existing practices represent architectures through collections of models (A.3). Typically, these models are further organized into cohesive groups. The cohesion of a group of models is determined by the observation that all of the included models address related concerns. What has been missing is some mechanism for formalizing these groupings and the models used to make the representations. In this standard, viewpoint refers to a pattern, template, or approach for representing one set of concerns relative to an architecture, while a view is the actual representation of a particular system using that approach. A viewpoint provides the formalization of the groupings of models.

A view is a representation or description of the entire system from the perspective of a related set of concerns. In contrast to a viewpoint, a view pertains to a particular architecture of a system of interest (i.e., an individual system, a product line, a system-of-systems, etc.). A view is composed of architectural models, and may have additional attributes. The models provide the specific description, or content, of an architectural description. For example, a structural view might consist of a set of models of the system structure. The elements of such models might include identifiable system components and their interfaces, and interconnections among those components.

The need for multiple views in architectural descriptions is widely recognized in the literature. To argue otherwise, in the terms of this standard, is to claim that an architecture can be adequately described by a set of models corresponding to a single conceptual perspective. Alternatively, it would be to argue that all stakeholders and concerns can be addressed by a single set of modelling methods.

The use of multiple views to describe an architecture is therefore a fundamental premise of the standard. However, while the use of multiple views is widespread, authors differ on what views are needed and on appropriate methods for expressing each view.

Because of the wide range of opinion on selecting appropriate views, this standard does not require a predefined set of views; rather, the standard uses the term viewpoint to refer to a means for constructing views without reference to a particular system, making viewpoints “first-class” elements of architectural descriptions.

The earliest work on first-class viewpoints appears in Ross’ Structured Analysis (SADT) in 1977 [RSA]. Nuseibeh, Kramer and Finkelstein, in the field of requirements engineering, treat viewpoints as first-class entities, with associated attributes and operations [NKF]. In this standard, the term was also chosen to align with that of the ISO Reference Model of Open Distributed Processing (RM-ODP) [ISO/IEC 10746], which defines viewpoint as follows:

viewpoint (on a system): a form of abstraction achieved using a selected set of architectural constructs and structuring rules, in order to focus on particular concerns within a system.

However, RM-ODP uses the term viewpoint specification to refer to the application of a viewpoint to a particular system, where this standard uses view.

The relationship between viewpoint and view is analogous to that of a template and an instance of that template, or to use a programming metaphor:

ISO/IEC WD1 42010 IEEE P42010/D1

viewpoint : view :: class : object2

In accordance with the standard, a viewpoint must identify the stakeholders that it addresses, the architectural concerns that it frames and the “resources”—languages, models, and techniques—to be employed in resultant views.

By not requiring that specific viewpoints be used, and by making the definition of viewpoints explicit before their use, the standard provides a strategy for the customization and evolution of architectural practices. Users can define architectural frameworks (7) to satisfy the needs of domain-specific uses, where the domain may be, for example, application-specific, method-specific, or organization-specific. This also provides one means to capture the considerable commonality found among existing techniques, and suggests another metaphor that may be useful to understand viewpoint:

view : viewpoint :: map : legend

A legend (or “caption” or “key”) defines the conventions used in preparing a map, such as its scale, colors and symbols, to aid readers of the map to interpret it as intended. Just as every map should have a legend, every architectural view should have a viewpoint to describe the set of conventions for interpreting the contents of the view.

Editor: Is this a good place to mention the term viewtype?

Editor: This annex will need to be edited regarding Clause 7, Architectural Frameworks.

In constructing an architectural description, an architect first selects the viewpoints, or a set of viewpoints via an architecture framework, and then constructs a set of corresponding views. Viewpoints can be thought of as being drawn from a library of predefined viewpoints, whether or not such a viewpoint library actually exists.

Within a particular architectural description, every view is associated with exactly one viewpoint, which must have been selected for that architectural description. The required relationship between that viewpoint and its view is that the view conforms to the viewpoint. A view conforms to a viewpoint if it consists only of models that conform to the modelling methods called for in the viewpoint specification.

In principle, a given view could conform to multiple viewpoints, but should conform to only one viewpoint within a specific architectural description. However, a viewpoint can, and should, be reused across many architectural descriptions. For example, a structural viewpoint requiring the use of a particular modelling method and technique of analysis might be selected by many different architectural descriptions.

While the relationship between views and viewpoints (within a given architectural description) is one-to-one, it should be understood that this relationship is more general outside a given architectural description. If, within one architectural description, a view corresponds to two or more viewpoints, it means the viewpoints are redundant. The stakeholders and concerns of interest to the set of viewpoints are all being addressed by one collection of models using one modelling method, so the stakeholders and concerns might as well be aggregated into a single viewpoint. If an architectural description is written for a system, and then another architectural description is written for a component of the system, as might happen in a complex system, then it is quite likely that the same viewpoints will be chosen for both architectural descriptions. Thus a given viewpoint (say a structural viewpoint) will have a corresponding view of the whole system and a corresponding view of the subsystem. The relationship is still one-to-one—within each architectural description. From the perspective of this standard, the situation is no different than if the same viewpoint had been taken from a library and used on two completely different systems.

2 This may be read, “a viewpoint is to a view as a class is to an object.”

ISO/IEC WD1 42010 IEEE P42010/D1

The relationship between views and viewpoints can be envisioned by imagining a library of viewpoints maintained by an architecting organization and a set of architectural descriptions for a variety of systems produced by that same organization. Each architectural description selects a set of viewpoints from the library of viewpoints. Each architectural description contains views that describe a particular system.

In addition to the required conformance of a view to its viewpoint, there is another form of checking required by the standard. A viewpoint addresses particular stakeholders and frames particular concerns. Every architectural concern must be framed by at least viewpoint and every stakeholder must be addressed by at least one viewpoint.

* A view is incomplete if all concerns framed by the governing viewpoint are not addressed.

* An AD is incomplete if all stakeholder concerns are not addressed.

Annex C presents examples of architectural viewpoints.

ISO/IEC WD1 42010 IEEE P42010/D1

Annex B (informative)

Template Outline for an Architectural Description

Editor: Should the standard offer any templates for preparing ADs (as IEEE 1016 does for software design descriptions)? Topics to include:

— Scope

— Purpose

— Architectural Stakeholders

— Architectural Concerns

— Architectural Viewpoints

— Architectural Views

— Content Maps

ISO/IEC WD1 42010 IEEE P42010/D1

Annex C (informative)

Examples of architectural viewpoints

This annex provides some examples of the central concept of viewpoint.

The first three viewpoints (scenarios, structural viewpoint and behavioral viewpoint) are frequently used in software architecture, but have not been defined explicitly. The next two viewpoints (physical interconnect viewpoint and link bit error rate viewpoint) are informal constructions intended to illustrate application of the viewpoint concept outside purely software architecture.

The viewpoint definitions contained in this annex provide a standardized, minimum definition of the general characteristics of the named viewpoints. A conforming architectural description is not required to use any of these viewpoints. However, should an architect choose to use any of these viewpoints, the architect must do so in a way that is consistent with this standard, by extending, but not contradicting, the minimal viewpoint definitions provided here.

C.1 Scenarios viewpoint

Editor: The idea here would be to define a common viewpoint to capture stakeholder’s interactions with a system of interest relative to identified concerns.

A scenario captures an interaction between a stakeholder and a system with respect to some concerns. Scenarios are used both to describe a system, and as a part of architectural reviews.

Familiar cases: use cases, change cases.

C.1.1 Stakeholders

C.1.2 Concerns

C.1.3 Viewpoint language

Stakeholders, Systems, Concerns, Interactions

C.1.4 Modelling methods

Use cases, textual narratives.

ISO/IEC WD1 42010 IEEE P42010/D1

C.1.5 Analytic methods

C.1.6 References

C.2 Components and connectors viewpoint

This viewpoint is motivated by recent work in structure-oriented architectural description languages. It has developed in the field of software architecture since 1994 and is in widespread use. This viewpoint is often implicit in contemporary architectural description languages.

In perhaps the earliest paper on software architecture, a structural viewpoint is implied by Perry and Wolf’s definition of elements, as follows.

By analogy to building architecture, we propose the following model of software architecture: Software Architecture = {Elements, Form, Rationale}

Perry and Wolf distinguish three classes of elements as follows: a) Processing elements: “those components that supply the transformation of data elements” b) Data elements: “those that contain the information that is used and transformed” c) Connecting elements: those “elements (which at times may be either processing or data elements, or both) are the glue that holds the different pieces of the architecture together”

Shaw and Garlan adopt a similar approach [SG]:

The framework we will adopt is to treat an architecture of a specific system as a collection of computational components—or simply components—together with a description of the interactions between these components—the connectors. … An architectural style, then, defines a family of such systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined.

C.2.1 Architectural concerns

— What are the computational elements of a system and the organization of those elements?

— What software elements compose the system?

— What are their interfaces?

— How do they interconnect?

— What are the mechanisms for interconnection?

C.2.2 Viewpoint language

The viewpoint depends on the following entities:

Components (individual units of computation)

Components have ports (interfaces)

ISO/IEC WD1 42010 IEEE P42010/D1

Connectors (represent interconnections between components for communication and coordination)

Connectors have roles (where they attach to components)

Components and connectors may be typed. All of the previously listed entities may have attributes of varying kinds.

C.2.3 Analytic methods

The structural viewpoint supports the following kinds of checking:

Attachment (are connectors properly connecting components?)

Type consistency (are the types of components and connectors used consistent with their attachments and any style or other constraints?)

Most architectural description languages that support the structural viewpoint provide some kind of syntax checking of the entities above.

References: [V&B]

C.3 Behavioral viewpoint

The behavioral viewpoint has a long history, prior to its use in architecture in the systems engineering, simulation, and software engineering/design communities. Examples include Petri nets, parallel path expressions, and constrained expressions.

The behavioral viewpoint may be specified as follows:

C.3.1 Architectural Concerns

What are the dynamic actions of and within a system?

What are the kinds of actions the system produces and participates in?

How do those actions relate (ordering, synchronization, etc.)?

What are the behaviors of system components? How do they interact?

C.3.2 Modelling methods

Events, processes, states, and operations on those entities.

C.3.3 Analytic methods

Some examples are: communicating sequential processes, the pi-calculus, and partially ordered sets of events.

ISO/IEC WD1 42010 IEEE P42010/D1

C.4 Physical interconnect viewpoint

C.4.1 Architectural Concerns

What are the physical communications interconnects and their layering among system components?

What is the feasibility of construction, compliance with standards, and evolvability?

C.4.2 Viewpoint language

Define the system with a set of one or more block diagrams using the following visual glossary:

Figure — Visual Glossary

One diagram is provided for each identified communication layer. Each diagram is annotated to show the addressing, link access, and routing/switching strategies at each link.

C.5 Link bit error rate viewpoint

C.5.1 Architectural concerns

What is the bit error rate on a communications link?

What is the feasibility of building and maintaining consistency with operational information flows?

C.5.2 Viewpoint language

Compute bit error rate from

P L L SNR = ----T------T------R- N kTB F

Where:

ISO/IEC WD1 42010 IEEE P42010/D1

PT = is the transmit power LT = is the transmit losses, either cable or free space propagation LR = is the receive losses (or gain), either receiver only or antenna determined NF = is the noise figure, computed over whole receiver chain kT = is the standard noise density B = is the receiver detection bandwidth

Then BER = Error(SNR, modulation), where the error function is taken from a standard reference, such as Proakis [Pro].

ISO/IEC WD1 42010 IEEE P42010/D1

Annex D (informative)

Editor: This material is moved from IEEE 1471:2000 subclause 5.7 showing how the requirements now presented in clause 6 interrelate. The example needs to be enhanced and improved or removed.

A brief example shows how the normative requirements of Clause 6 work together. To claim conformance with this standard, the architect must produce an architectural description meeting the requirements in 6.1 through 6.6.

Subclause 6.1 requires that the architectural description include basic documentary information.

Under 6.2, the architectural description must identify architecturally relevant stakeholders and concerns. For example, one stakeholder must be the system builder, and one of that stakeholder’s concerns might be the input/output behavior of the system. This standard places only minimal requirements on the concerns selected and thus deemed architectural. The using organization and the architect must make the central choice of what concerns to address.

Subclause 6.3 requires that a set of viewpoints be selected, defined, and analyzed for coverage and that the rationale be given for their selection. The architect might therefore select a behavioral viewpoint that would describe the system’s input/output behavior. The architect would also be obligated to define what languages or models will be employed to describe system behavior under that viewpoint. No restriction is placed on the language or modelling technique used, but it must be explicitly specified in accordance with 6.3.

Subclause 6.4 requires the representation of the resulting architecture through one or more views. The architect will construct a behavioral view of the system, and that behavioral view must conform to the behavioral viewpoint defined previously.

Subclause 6.5 requires that any known inconsistencies among or between views (e.g., between the behavioral view provided and a structural view) be listed in the architectural description.

Editor: Example should show use of view correspondences.

In accordance with subclause 6.6, the architectural description must contain rationales for the architectural decisions and choices made by the architect.

NOTE The materials pertaining to 6.2 and 6.3, the stakeholders, concerns, and viewpoints, should be readily reusable elements for active architecting organizations. It is likely that such organizations will adopt common sets of viewpoints and common specifications, that is, agreement and specification on concerns addressed and methods used. Indeed, viewpoint standardization could be a fruitful activity within domains where similar systems are repeatedly built. Some existing architectural standards can be recast as standards on selection and specification of viewpoints, with this standard becoming a common reference point for reconciling architecting in various domains.

ISO/IEC WD1 42010 IEEE P42010/D1

Annex E (informative)

Review of Architectural Descriptions

Editor: This annex provides guidance on how to review an architectural description prepared in accordance with the requirements of this standard.

ISO/IEC WD1 42010 IEEE P42010/D1

Annex X (informative)

Editor: This material was in Annex D of IEEE 1471 for use with IEEE/EIA Std 12207. It should be updated for ISO 12207 or removed, as necessary.

Architectural descriptions can be used in a variety of settings and life cycle models. This annex demonstrates how architectural descriptions conforming to this standard can be used to meet the requirements of other standards.

X.1 Relation to 12207.0-1996

IEEE/EIA Std 12207.0-1996 defines two activities pertaining to architecture: system architectural design and software architectural design. The concept of architecture in this standard is consistent with the system architectural design activity of IEEE/EIA Std 12207.0-1996. However, IEEE/EIA Std 12207.0-1996 places requirements on an architectural description in addition to those of this standard. Specifically, a system architectural design must include an identification of the hardware items, software items, and manual operation items included in the system. System architectural designs must also be evaluated according to criteria including traceability to and consistency with the system requirements, appropriateness of design standards and methods, and feasibility of software and manual operations. An approach for meeting these requirements using this standard is to define one or more viewpoints that meet the IEEE/EIA Std 12207.0- 1996 requirements. An example of a viewpoint to satisfy IEEE/ EIA Std 12207.0-1996 is defined in [REF].

The expected use of an architectural description may include elements of other IEEE/EIA Std 12207.0-1996 activities. In particular, an architectural description may be used in activities other than the system architectural design activity to facilitate the communications between the acquirer and the developer roles.

The software architectural design activity of IEEE/EIA Std 12207.0-1996 exemplifies a decompositional approach to architecture. Its primary goal is to decompose the software items of the system into components and then to allocate requirements to those components. Both the system architectural description and the products of other views in the architectural description would contribute to this activity and its products.

NOTE—The provisions of IEEE/EIA Std 12207.0-1996 relevant to architecture are identical to those found in ISO/ IEC 12207: 1995.

An architectural description can conform to this standard, to IEEE/EIA Std 12207.0-1996 and IEEE/EIA Std 12207.1-1997. One approach to joint conformance is to have a viewpoint that is specifically focused on producing the IEEE/EIA Std 12207.0-1996 architectural products. An example of a viewpoint defined for this purpose is shown in [REF].

X.2 Decomposition and allocation viewpoint

Concerns

Identify the system requirements

Decompose the system into items

ISO/IEC WD1 42010 IEEE P42010/D1

Allocate requirements to the items

Ensure that all requirements are allocated to items

Modelling techniques and analytic methods

Each requirement is uniquely identified. If necessary, requirements are decomposed and extended into derived requirements to provide a full set of requirements for the system.

The system is decomposed into a set of items, where each item is a hardware item, a software item or a manual operations item. Interfaces between items are also identified.

System requirements are allocated to the items, such that each item satisfies one or more requirements, and each requirement is allocated to at least one item.

The initial decomposition and allocation produces a set of items with allocated requirements. This is described in terms of a System Architectural Description (see IEEE/EIA Std 12207.0-1996).

The initial software items are decomposed into subordinate components. Requirements allocated to each software item are further allocated to one or more components. Interface descriptions are provided between software components, and between software components and hardware items and manual operation items. This is described in terms of a Software Architectural Description (see IEEE/EIA Std 12207.0-1996).

ISO/IEC WD1 42010 IEEE P42010/D1

Bibliography

Editor: References will be numbered in accordance with ISO style directives when the bibliography becomes more stable.

[V&B] Clements P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., Stafford, J., 2002a. Documenting Software Architectures: Views and Beyond. Boston: Addison-Wesley, 2002.

[D] Dijkstra, E. W. On the role of scientific thought. 1974. http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html.

[HNS] Hofmeister, C., R. Nord, and D. Soni, Applied Software Architecture. Reading, MA: Addison-Wesley, 1999.

[] ISO/IEC 10746-2: 1996, Information technology — Open distributed processing — Reference model: Foundations.

[] ISO/IEC 10746-3: 1996, Information technology — Open distributed processing — Reference model: Architecture.

[] ISO/IEC 15704 Industrial automation systems — Requirements for enterprise-reference architectures and methodologies

[UML] OMG AD/97-08-05, 1997, Unified Modelling Language Specification, version 1.1, Object Management Group.

[4+1] Kruchten, P.B., The “4+1” View Model of Architecture. IEEE Software, 12(6), pp. 45–50, 1995.

[MR] Maier, M.W. and E. Rechtin, The art of systems architecting. CRC Press, 2nd edition 2000.

[NKF] Nuseibeh, B., Kramer, J., Finkelstein, A. A framework for expressing the relationships between multiple views in requirements specification. IEEE Transactions on Software Engineering 20(10) pp. 760–773, 1994.

[PW] Perry, D. E. and Wolf, A. L., Foundations for the Study of Software Architecture. ACM SIGSOFT Soft- ware Engineering Notes, Vol. 17, No. 4, 1992.

[Pro] Proakis, J. G., Digital Communications. New York: McGraw-Hill, 1995.

[Ran] Ran, A. ARES Conceptual Framework for Software Architecture. In: Jazayeri, M., Ran, A., van der Linden, F. (Eds.), Software Architecture for Product Families Principles and Practice. Boston: Addison- Wesley, , pp. 1–29, 2000.

[RSA] Ross, D.T., Structured Analysis (SA): a language for communicating ideas. IEEE Transactions on Software Engineering SE-3(1) (1977) 16–34

[RW] Rozansky, N. and E. Woods, Software Systems Architecture

[SG] Shaw, M. and Garlan, D., An Introduction to Software Architecture. In Advances in Software Engineer- ing and Knowledge Engineering, V. Ambriola and G. Tortora (eds.), River Edge, NJ: World Scientific Publishing Company, 1993.

ISO/IEC WD1 42010 IEEE P42010/D1

[Smo] Smolander, Kari, Four Metaphors of Architecture in Software Organizations: Finding out The Meaning of Architecture in Practice. Proceedings of the 2002 International Symposium on Empirical Software Engineering (ISESE’02)

[TOGAF] The Open Group Architecture Framework.

[Z] Zachman, J. A., A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 1987.