definitions are taken from papers and articles in our software
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
[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
[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
[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.