Software architecture description


Software architecture description is the set of practices for expressing, communicating and analysing software architectures, and the result of applying such practices through a work product expressing a software architecture.
Architecture descriptions are also sometimes referred to as architecture representations, architecture specifications
or software architecture documentation.

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.
Architecture models can take various forms, including text, informal drawings, diagrams or other formalisms.
An architecture description will often employ several different model kinds to effectively address a variety of audiences, the stakeholders and a variety of architectural concerns.
Often, the models of an architecture description are organized into multiple views of the architecture such that "each addresses specific concerns of interest to different stakeholders of the system".
An architecture viewpoint is a way of looking at a system. 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.
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. 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.
Influences on architecture description came from the areas of Software Engineering and from system design.
Work on programming in the large, such as module interconnection languages focused on the expression of the large-scale properties of software: modules and module-relationships. This work influenced both architectural thinking about programming languages, and design and architecture notations 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 and object-oriented techniques.
Perry and Wolf 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:
, distinguishing three kinds of elements :
Perry and Wolf identified four objectives or uses for architecture descriptions :
Following the Perry and Wolf paper, two schools of thought on software architecture description emerged:
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:
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. The viewpoint specifies not only the concerns framed but the presentation, model kinds used, conventions used and any consistency rules to keep a view consistent with other views.
Examples of viewpoints include:
The term viewtype is used to refer to categories of similar views sharing a common set of elements and relations.

Architecture description languages

An architecture description language is any means of expression used to describe a software architecture.
Many special-purpose ADLs have been developed since the 1990s, including AADL, Wright, Acme, xADL, Darwin, DAOP-ADL, and ByADL.
Early ADLs emphasized modeling systems in terms of their components, connectors and configurations. More recent ADLs 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". A framework is usually implemented in terms of one or more viewpoints or ADLs.
Frameworks of interest in software architecture include:
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.

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".
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.
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.
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 :