Classic definitions appear in some of the more prominent or influential books and papers on architecture.

Submit

Contact us to submit your definition of software architecture.

Entries

Rational Unified Process, 1999

An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition (Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999).

Perry and Wolf, 1992

An early one by Dewayne Perry and Alex Wolf is:

A set of architectural (or, if you will, design) elements that have a particular form. Perry and Wolf distinguish between processing elements, data elements, and connecting elements, and this taxonomy by and large persists through most other definitions and approaches.

Garlan and Shaw, 1993

In what has come to be regarded as a seminal paper on software architecture , Mary Shaw and David Garlan suggest that software architecture is a level of design concerned with issues

...beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives."

Bass, et al., 1994

Writing about a method to evaluate architectures with respect to the quality attributes they instill in a system , Bass and his colleagues write that

...the architectural design of a system can be described from (at least) three perspectives -- functional partitioning of its domain of interest, its structure, and the allocation of domain function to that structure.

Hayes-Roth, 1994

Writing for the ARPA Domain-Specific Software Architecture (DSSA) program, Hayes-Roth says that software architecture is

...an abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections.

Garlan and Perry, 1995

David Garlan and Dewayne Perry have adopted the following definition for their guest editorial to the April 1995 IEEE Transactions on Software Engineering devoted to software architecture:

The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.

(The source of this definition was a weekly discussion group devoted to software architecture at the Software Engineering Institute.)

Boehm, et al., 1995

Barry Boehm and his students at the USC Center for Software Engineering write that:

A software system architecture comprises

• A collection of software and system components, connections, and constraints.
• A collection of system stakeholders' need statements.
• A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.

Soni, Nord, and Hofmeister, 1995

Soni, Nord, and Hofmeister of Siemens Corporate Research write that, based on structures found to be prevalent and influential in the development environment of industrial projects they studied, software architecture has at least four distinct incarnations:

Within each category, the structures describe the system from a different perspective:

• The conceptual architecture describes the system in terms of its major design elements and the relationships among them.
• The module interconnection architecture encompasses two orthogonal structures: functional decomposition and layers.
• The execution architecture describes the dynamic structure of a system.
• The code architecture describes how the source code, binaries, and libraries are organized in the development environment.

Shaw, 1995: At the First International Workshop on Architectures for Software Systems, Mary Shaw provided a much-needed clarification of the terminological chaos. Distilling the definitions and viewpoints (implicit or explicit) of the workshop's position papers, Shaw classifies the views of software architecture thus :

• Structural models all hold that software architecture is composed of components, connections among those components, plus (usually) some other aspect or aspects, including (grouping suggested by the authors):
• configuration, style
• constraints, semantics
• analyses, properties
• rationale, requirements, stakeholders' needs

Work in this area is exemplified by the development of architectural description languages (ADLs), which are formal languages that facilitate the description of an architecture's components and connections. The languages are usually graphical, and provide some form of "box and line" syntax for specifying components and hooking them together.

• Framework models are similar to the structural view, but their primary emphasis is on the (usually singular) coherent structure of the whole system, as opposed to concentrating on its composition. Framework models often target specific domains or problem classes. Work that exemplifies the framework view includes domain-specific software architectures, CORBA [55] or CORBA-based architecture models, and domain-specific component repositories (e.g., PRISM).
• Dynamic models emphasize the behavioral quality of systems. "Dynamic" may refer to changes in the overall system configuration, setting up or disabling pre-enabled communication or interaction pathways, or the dynamics involved in the progress of the computation, such as changing data values.
• Process models focus on construction of the architecture, and the steps or process involved in that construction. In this view, architecture is the result of following a process script. This view is exemplified by work in process programming for deriving architectures.

These views do not preclude each other, nor do they really represent a fundamental conflict about what software architecture is. Instead, they represent a spectrum in the software architecture research community about the emphasis that should be placed on architecture -- its constituent parts, the whole entity, the way it behaves once built, or the building of it. Taken together, they form a consensus view of software architecture.