Software architecture description

Last updated October 03, 2023

Software architecture description is the set of practices for expressing, communicating and analysing software architectures (also called architectural rendering), and the result of applying such practices through a work product expressing a software architecture (ISO/IEC/IEEE 42010).

Concepts

Architecture description defines the practices, techniques and types of representations used by software architects to record a software architecture. Architecture description is largely a modeling activity (Software architectural model). Architecture models can take various forms, including text, informal drawings, diagrams or other formalisms (modeling language). An architecture description will often employ several different model kinds to effectively address a variety of audiences, the stakeholders (such as end users, system owners, software developers, system engineers, program managers) and a variety of architectural concerns (such as functionality, safety, delivery, reliability, scalability).

Often, the models of an architecture description are organized into multiple views of the architecture such that "each [view] addresses specific concerns of interest to different stakeholders of the system".^[2] An architecture viewpoint is a way of looking at a system (RM ODP). Each view in an architecture description should have a viewpoint documenting the concerns and stakeholders it is addressed to, and the model kinds, notations and modeling conventions it utilizes (ISO/IEC/IEEE 42010).

The use of multiple views, while effective for communicating with diverse stakeholders and recording and analyzing diverse concerns, does raise potential problems: since views are typically not independent, the potential for overlap means there may be redundancy or inconsistency between views of a single system.^[3] Various mechanisms can be used to define and manage correspondences between views to share detail, to reduce redundancy and to enforce consistency.

A common misunderstanding about architecture descriptions is that ADs only discuss "technical issues", but ADs need to address issues of relevance to many stakeholders. Some issues are technical; many issues are not: ADs are used to help architects, their clients and others manage cost, schedule and process. A related misunderstanding is that ADs only address the structural aspects of a system. However, this rarely satisfies the stakeholders, whose concerns often include structural, behavioral, aesthetic, and other "extra-functional" concerns.

History

The earliest architecture descriptions used informal pictures and diagrams and associated text. Informal descriptions remain the most widely used representations in industry.^[4] Influences on architecture description came from the areas of Software Engineering (such as data abstraction and programming in the large) and from system design (such as SARA^[5]).

Work on programming in the large, such as module interconnection languages (MILs) focused on the expression of the large-scale properties of software:^[6] modules (including programs, libraries, subroutines and subsystems) and module-relationships (dependencies and interconnections between modules). This work influenced both architectural thinking about programming languages (e.g., Ada), and design and architecture notations (such as Buhr diagrams and use case maps and codified in architectural features of UML: packages, subsystems, dependences) and much of the work on architecture description languages. In addition to MILs, under the influence of mature work in the areas of Requirements and Design within Software Engineering, various kinds of models were "lifted" from software engineering and design to be applied to the description of architectures. These included function and activity models from Structured Analysis SADT, data modeling techniques (entity-relation) and object-oriented techniques.

Perry and Wolf^[1] cited the precedent of building architecture for the role of multiple views: "A building architect works with the customer by means of a number of different views in which some particular aspect of the building is emphasized."

Perry and Wolf posited that the representation of architectures should include: { elements, form and rationale }, distinguishing three kinds of elements (and therefore three kinds of views):

processing: how the data is transformed;
data: information that is used and transformed;
connecting: glue holding the other elements together;

Perry and Wolf identified four objectives or uses for architecture descriptions (called "architecture specifications" in their paper):

prescribe architectural constraints without overspecifying solutions
separate aesthetics from engineering
express different aspects of the architecture each in an appropriate manner
conduct architecture analysis, particularly dependency and consistency analyses

Following the Perry and Wolf paper, two schools of thought on software architecture description emerged^{[ citation needed ]}:

Multiple views school
Structuralist school

Mechanisms for architecture description

There are several common mechanisms used for architecture description. These mechanisms facilitate reuse of successful styles of description so that they may be applied to many systems:

architecture viewpoints
architecture description languages
architecture frameworks

Architecture viewpoints

Software architecture descriptions are commonly organized into views, which are analogous to the different types of blueprints made in building architecture. Each view addresses a set of system concerns, following the conventions of its viewpoint, where a viewpoint is a specification that describes the notations, modeling techniques to be used in a view to express the architecture in question from the perspective of a given set of stakeholders and their concerns (ISO/IEC 42010). The viewpoint specifies not only the concerns framed (i.e., to be addressed) but the presentation, model kinds used, conventions used and any consistency (correspondence) rules to keep a view consistent with other views.

Examples of viewpoints include:

Functional viewpoint
Logical viewpoint
Information/Data viewpoint
Module viewpoint
Component-and-connector viewpoint
Requirements viewpoint
Developer/Implementation viewpoint
Concurrency/process/runtime/thread/execution viewpoint
Performance viewpoint
Security viewpoint
Physical/Deployment/Installation viewpoint
User action/feedback viewpoint

The term viewtype is used to refer to categories of similar views sharing a common set of elements and relations.^[4]

Architecture description languages

An architecture description language (ADL) is any means of expression used to describe a software architecture (ISO/IEC/IEEE 42010). Many special-purpose ADLs have been developed since the 1990s, including AADL (SAE standard), Wright (developed by Carnegie Mellon), Acme (developed by Carnegie Mellon), xADL (developed by UCI), Darwin (developed by Imperial College London), DAOP-ADL (developed by University of Málaga), and ByADL (University of L'Aquila, Italy). Early ADLs emphasized modeling systems in terms of their components, connectors and configurations. More recent ADLs (such as ArchiMate and SysML) have tended to be "wide-spectrum" languages capable of expressing not only components and connectors but a variety of concerns through multiple sub-languages. In addition to special-purpose languages, existing languages such as the UML can be used as ADLs "for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes."

Architecture frameworks

An architecture framework captures the "conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders" (ISO/IEC/IEEE 42010). A framework is usually implemented in terms of one or more viewpoints or ADLs. Frameworks of interest in software architecture include:

Arc42
C4 model
4+1
RM-ODP (Reference Model of Open Distributed Processing)
TOGAF

Multiple Views

Represented in Kruchten's very influential 1995 paper on the "4+1 view model", this approach emphasized the varying stakeholders and concerns to be modeled.^[2]

Structuralism

Second, reflected in work of CMU and elsewhere, the notion that architecture was the high level organization of a system at run-time and that architecture should be described in terms of their components and connectors: "the architecture of a software system defines that system in terms of computational components and interactions among those components".^[7]

During the 1990s-2000s, much of the academic work on ADLs took place within the paradigm of components and connectors. However, these ADLs have had very little impact in industry.^[8] Since the 1990s, there has been a convergence in approaches toward architecture description, with IEEE 1471 in 2000 codifying best practices: supporting, but not requiring, multiple viewpoints in an AD.

Architecture description via decisions

Elaborating on the rationale aspect of Perry and Wolf's original formula, a third school of thought has emerged, documenting the decisions and reasons for decisions as an essential way of conceiving and expressing a software architecture.^[9] This approach treats decisions as first-class elements of the architecture description, making explicit what was often implicit in earlier representations.

Uses of architecture descriptions

Architecture descriptions serve a variety of purposes including (ISO/IEC/IEEE 42010):

to guide system construction and maintenance
to aid system planning, costing and evolution
to serve as a medium for analysis, evaluation or comparison of architectures
to facilitate communication among system stakeholders regarding the architecture and the system
to document architectural knowledge beyond the scope of individual projects (such as software product lines and product families, and reference architectures)
to capture reusable architectural idioms (such as architectural styles and patterns)

Related Research Articles

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

A modeling language is any artificial language that can be used to express data, information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure Programing language.

ISO/IEC 9126Software engineering — Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011.

Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

A software design description is a representation of a software design that is to be used for recording design information, addressing various design concerns, and communicating that information to the design’s stakeholders. An SDD usually accompanies an architecture diagram with pointers to detailed feature specifications of smaller pieces of the design. Practically, the description is required to coordinate a large team under a single vision, needs to be a stable reference, and outline all parts of the software and how they will work.

The British Ministry of Defence Architecture Framework (MODAF) was an architecture framework which defined a standardised way of conducting enterprise architecture, originally developed by the UK Ministry of Defence. It has since been replaced with the NATO Architecture Framework.

The ISO/IEC 15288 is a technical standard in systems engineering which covers processes and lifecycle stages, developed by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). Planning for the ISO/IEC 15288:2002(E) standard started in 1994 when the need for a common systems engineering process framework was recognized. The previously accepted standard MIL STD 499A (1974) was cancelled after a memo from the United States Secretary of Defense (SECDEF) prohibited the use of most U.S. Military Standards without a waiver. The first edition was issued on 1 November 2002. Stuart Arnold was the editor and Harold Lawson was the architect of the standard. In 2004 this standard was adopted by the Institute of Electrical and Electronics Engineers as IEEE 15288. ISO/IEC 15288 has been updated 1 February 2008 as well as on 15 May 2015.

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models - typically matrices and diagrams - for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

IEEE 1471 is a superseded IEEE standard for describing the architecture of a "software-intensive system", also known as software architecture.

Reference Model of Open Distributed Processing (RM-ODP) is a reference model in computer science, which provides a co-ordinating framework for the standardization of open distributed processing (ODP). It supports distribution, interworking, platform and technology independence, and portability, together with an enterprise architecture framework for the specification of ODP systems.

The ISO/IEC/IEEE 42010 Conceptual Model of Architecture Description defines the term architecture framework within systems engineering and software development as:

4+1 is a view model used for "describing the architecture of software-intensive systems, based on the use of multiple, concurrent views". The views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers, system engineers, and project managers. The four views of the model are logical, development, process and physical view. In addition, selected use cases or scenarios are used to illustrate the architecture serving as the 'plus one' view. Hence, the model contains 4+1 views:

ISO/IEC/IEEE 42010Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

TRAK is a general enterprise architecture framework aimed at systems engineers. It is based on MODAF 1.2.

DUALLy is an MDE framework to create interoperability among Architecture Description Languages (ADLs). It is developed at the Computer Science Department of the University of L'Aquila. DUALLy enables the transformation of a model conforming to a specific architecture description language into corresponding models conforming to other architecture description languages.

In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.

References

1 2 Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture". ACM SIGSOFT Software Engineering Notes 17 (4): 40. doi:10.1145/141874.141884
1 2 P. B. Kruchten, "The '4+1' view model of architecture," IEEE Software, vol. 12, no. 6, pp. 42–50, November 1995
↑ A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. Viewpoints: A framework for integrating multiple perspectives in system development. International Journal of Software Engineering and Knowledge Engineering, 2(1):31-58, 1992.
1 2 P. C. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford, Documenting Software Architectures: views and beyond. Addison Wesley, 2003.
↑ G. Estrin, R.S. Fenchel, R.R. Razouk, M.K. Vernon, "The System ARchitect's Apprentice", IEEE Transactions of Software Engineering, 1986.
↑ F. DeRemer and H.H. Kron, "Programming-in-the-Large Versus Programming-in-the-Small", IEEE Transactions on Software Engineering, 1976.
↑ M. Shaw and D. Garlan, Software Architecture: perspectives on an emerging discipline, Prentice Hall, 1996.
↑ E. Woods and R. Hilliard, "Architecture Description Languages in Practice" http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15
↑ A. Jansen and J. Bosch, "Software Architecture as a Set of Architectural Design Decisions" Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture, 2005.