Bibliographic Software Architecture Definitions

Bibliographic definitions are taken from papers and articles in our software architecture bibliography.


Contact us to submit your definition of software architecture.


[Lane 90]: Software architecture is the study of the large-scale structure and performance of software systems. Important aspects of a system's architecture include the division of functions among system modules, the means of communication between modules, and the representation of shared information. 

[Rechtin 92]: Systems architecture: The underlying structure of a system, such as a communication network, a neural network, a spacecraft, a computer, major software or an organization.

[Bhansali 92]: A generic architecture is defined as a topological organization of a set of parameterized modules, together with the inter-modular relationships. Designing a software system using a generic architecture consists of instantiating the parameters of each parameterized module by a concrete value while maintaining the inter-modular constraints.

[Garlan 92]: As the size and complexity of software systems increases, the design problem goes 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; composition of design elements; scaling and performance; and selection among design alternatives. This is the software architecture level of design.

[Perry 92]: We distinguish three different classes of architectural elements: processing elements; data elements; and connection elements. The processing elements are those components that supply the transformation on the data elements; the data elements are those that contain the information that is used and transformed; the connecting 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. For example, procedure calls, shared data, and messages are different examples of connecting elements that serve to "glue" architectural elements together. Consider the example of water polo as a metaphor for the different classes of elements: the swimmers are the processing elements, the ball is the data element, and the water is the primary connecting element (the "glue"). Consider further the similarities of water polo, polo, and soccer. They all have a similar "architecture" but differ in the "glue"- that is, they have similar elements, shapes and forms, but differ mainly in the context in which they are played and in the way that the elements are connected together. We shall see below that these connecting elements play a fundamental part in distinguishing one architecture from another and may have an important effect on the characteristics of a particular architecture or architectural style. The architectural form consists of weighted properties and relationships. The weighting indicates one of two things: either the importance of the property or the relationship, or the necessity of selecting among alternatives, some of which may be preferred over other. The use of weighting to indicate importance enables the architect to distinguish between "load-bearing" and "decorative" formal aspects; the use of weighting to indicate alternatives enables the architect to constrain the choice while giving a degree of latitude to the designers who must satisfy and implement the architecture. Properties are used to constrain the choice of architectural elements-that is, the properties are used to define constraints on the elements to the degree desired by the architect. Properties define the minimum desired constraints unless otherwise stated- that is, the default on constraints defined by properties is: "what is not constrained by the architect may take any form desired by the designer or implementer. "Relationships are used to constrain the "placement" of architectural elements-that is, they constrain how the different elements may interact and how they are organized with respect to each other in the architecture. As with properties, relationships define the minimum desired constraints unless otherwise stated. An underlying, but integral, part of an architecture is the rationale for the various choices made in defining an architecture. The rationale captures the motivation for the choice of architectural style, the choice of elements, and the form.

[Crispen 94]: An Architecture, as we intend to use the term, consists of (a) a partitioning strategy and (b) a coordination strategy. The partitioning strategy leads to dividing the entire system in discrete, non-overlapping parts or components. The coordination strategy leads to explicitly defined interfaces between those parts.

[Clements 94-2]: Software architecture is loosely defined as the organizational structure of a software system including components, connections, constraints, and rationale. Components can be small pieces of code, such as modules, or larger chunks, such a stand-alone programs like database management systems. Connections in an architecture are abstractions for how components interact in a system, e.g., procedure calls, pipes, and remote procedure calls. An architecture has various constraints and rationales associated with it, including the constraints on component selection and the rationale for choosing a specific component in a given situation.

[Moriconi 94]: A software architecture is represented using the following concepts: 1. Component: An object with independent existence, e.g., a module, process, procedure, or variable. 2. Interface: A typed object that is a logical point of interaction between a component and its environment. 3. Connector: A typed object relating interface points, components, or both. 4. Configuration: A collection of constraints that wire objects into a specific architecture. 5. Mapping: A relation between the vocabularies and the formulas of an abstract and a concrete architecture. The formula mapping is required because the two architectures can be written in different styles. 6. Architectural style: A style consists of a vocabulary of design elements, a set of well-formedness constraints that mush be satisfied by any architecture written in the style, and a semantic interpretation of the connectors. Components, interfaces, and connectors are treated as first-class objects- i.e., they have a name and they are refinable. Abstract architectural objects can be decomposed, aggregated, or eliminated in a concrete architecture. The semantics of components is not considered part of an architecture, but the semantics of connectors is.

[Kruchten 94]: Software architecture deals with the design and implementation of the high-level structure of the software. It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and performance requirements such as scalability and availability. Software architecture deals with abstraction, with decomposition and composition, with style and aesthetics.

[Garlan 94]: A critical aspect of the design for any large software system is its gross structure that is, its high-level organization of computational elements and interactions between those elements. Broadly speaking, we refer to this as the software architectural level of design.

[FHayes-Roth 94]: Software Architecture: An abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections. The interconnections define provide by which components interact.

[Abowd 95]: Software architecture is an important level of description for software systems. At this level of abstraction key design issues include gross-level decompositional components, protocols of interaction between those components, global system properties (such as throughout and latency), and life-cycle issues (such as maintainability, extent of reuse, and platform independence).

[Boasson 95]: [We take] "architecture" to mean a system structure that consists of active modules, a mechanism to allow interaction among these modules, and a set of rules that govern the interaction.

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

[BHayes-Roth 95]: The architecture of a complex software system is its "style and method of design and construction".

[Lawson 95]: A system architecture is typically defined in the context of the "requirements, design, implementation" sequence, referring the top level of the design stage, "...where the design issues involve overall association of systems capabilities with components." It also designates a higher level of abstraction, codification, and standardization, targeting the improvement of system design and making the complex system intellectually tractable. To characterize a system architecture the following topics must be addressed: The relations that bind a system architecture to the corresponding development process: the important decisions to be made (at the corresponding level of abstraction), the issues to be resolved, the properties to be guaranteed. The relations to the information model employed, and the tools used. The corresponding body of applicable engineering knowledge and design rationale. The set of constructive concepts-architecture elements- as well as notations for them, that can be used to build the system description at the appropriate level of abstraction. From this perspective, we define and architecture as a system design model that captures system organization and behavior in terms of components, interactions, and static and dynamic configurations.

[KJackson 95]: "The definition of a set of generic component types together with: -a description of the properties of each type, -the rules governing the way each component type may interact with each other type -the style of interactions allowed between components, and -the rules which govern how a system (or subsystem) may be composed from instances of the generic components." For an architecture to be considered "good" and provide the facilities defined in the previous section an architecture must, in addition to the items indicated above: -support the specification of design specific but context independent (reusable) component types; -support the composition of system (and subsystems) from instances of these design specific components, -support the ability to place components in appropriate physical locations and define the run-time software and/or special purpose hardware required to support the execution of the system. (We refer to this item as "infrastructure" or "middleware", since it sits between the application software and the standard computer hardware plus operating system.

[ATA 96]: The U.S. Army's Army Technical Architecture (ATA) provides these definitions:

  • A Technical Architecture is the minimal set of rules governing the arrangement, interaction, and interdependence of the parts or elements that together may be used to form an information system. Its purpose is to ensure that a conformant system satisfies a specified set of requirements. It is the build code for the Systems Architecture being constructed to satisfy Operational Architecture requirements.
  • An Operational Architecture is a description, often graphical, which defines the force elements and the requirement to exchange information between those force elements. It defines the types of information, the frequency of its exchange, and what warfighting tasks are supported by these information exchanges. It specifies what the information systems are operationally required to do and where these operations are to be performed.
  • A Systems Architecture is a description, often graphical, of the systems solution used to satisfy the warfighter's Operational Architecture requirement. It defines the physical connection, location, and identification of nodes, radios, terminals, etc., associated with information exchange. It also specifies the system performance parameters. The Systems Architecture is constructed to satisfy the Operational Architecture requirements per the standards defined in the Technical Architecture.