Software Architecture: Practice, Potential, and Pitfalls

Panel Introduction

David Garlan Dewayne Perry

School of Computer Science AT&T Bell Laboratories

Carnegie Mellon University 600 Mountain Ave.
Pittsburgh, PA 15213 USA Murray Hill, NJ 07974 USA

1 What is software architecture? of evolution, its overall computational paradigm, and its
relationship to similar systems.

A critical aspect of the design for any large software The second trend is the recent interest in exploiting spe-
system is its gross structure – that is, its high-level organi- cific domains to provide reusable frameworks for product
zation of computational elements and interactions between families. This is based on the idea that common aspects
those elements [3, 6]. Broadly speaking, we refer to this of a collection of related systems can be extracted so that
as the software architectural level of design. Recently soft- each new system can be built by “instantiating” the shared
ware architecture has begun to emerge as an important infrastructure. Familiar examples include the standard de-
field of study for software engineering practitioners and re- composition of a compiler (which permits undergraduates
searchers. This emergence is evidenced by a large body of to construct a new compiler in a semester), standardized
recent work in areas such as module interface languages, communication protocols (which allow vendors to interop-
domain specific architectures, architectural description lan- erate by providing services a different layers of abstrac-
guages, formal underpinnings for architectural design, and tion), fourth generation languages (which exploit the com-
architectural design environments. mon patterns of business information processing), and user

What do we mean by the term “software architecture”? interface toolkits and frameworks.

If we look at the current uses of the term “architecture”, we Generalizing from these trends, it is possible to iden-
find that it is used in different ways, often making it diffi- tify three salient distinctions. The first distinction is be-
cult to understand what aspect is being addressed. Among tween traditional concerns about design of algorithms and
the various meanings are (a) the architecture of a particular data structures, on the one hand, and architectural con-
artifact, as in “the blueprints describe this building,” (b) cerns about the gross modularization of a large system, on
an architectural style, as in “that church is an example of the other. The has been the traditional focus of
former
Gothic architecture/’ and (c) the general study of architec- much of computer science, while the latter is emerging as
ture, as in “he has an advanced degree in architecture.” a significant and different design level that requires its own
To clarify the meaning of the term “architecture” with re- notations, theories, and tools.
spect to software systems, it is helpful to observe that there- The second distinction is between system description
cent emergence of interest in software architecture has been based on definition-use structure and architectural descrip-
prompted by two distinct trends. The first is the recognition tion based on graphs of interacting components. The for-
that over the years designers have begun to develop a shared mer modularizes a system in terms of source code, usually
repertoire of methods, techniques, patterns and idioms for making explicit dependencies between use sites of the code
structuring complex software systems. For example, the and corresponding definition sites. The latter modularizes
box and line diagrams and explanatory prose that typically a system as a graph, or configuration, of “components” and
accompany a high-level system description often refer to “connectors”. Components define the primary points of
such patterns as a “pipeline”, a “blackboard-oriented de- computation in the system, while connectors define the in-
sign”, or a “client-server system”. Although these terms teractions between those components. These interactions
rarely have precise definitions, they permit designers to de- can be as simple as procedure calls or data sharing, or
scribe complex systems using abstractions that make the can be as complex as pipes, event broadcast, client-server
oyerall system intelligible. Moreover, they provide signif- protocols, database accessing protocols, etc.
icant semantic content that inform others about the kinds The third distinction is between architectural instance
of properties that the system will have: the expected paths and architectural style. An architectural instance refers to

363
0270-5257/94 $3.00@1994IEEE
the architecture of a specific system. Box and line diagrams 3. Evolution: Software architecture can expose the di-
that accompany system documentation describe architec- mensions along which a system is expected to evolve.
tural instances since they apply to individual systems. An By making explicit what are the “load-beruing walls”
architectural style, however, defines constraints on the form of a system, system maintainers can better understand
and structure of a family of architectural instances. For ex- the ramifications of changes, and thereby more accu-
ample, a “pipe and filter” architectural style might define rately estimate costs of modifications [6].
the family of system architectures that are constructed as
4. Analysis: Architectural description provides new op-
a graph of incremental stream transformers. Architectural
styles typically prescribe such things as a vocabulary of portunities for analysis [6], including high-level forms
components and connectors (e.g., filters and pipes), topo-
of system consistency checking [2, 4], conformance
logical constraints (e.g., the graph must be acyclic), seman-
to an architectural style [ 1], and domain-specific anal-
tic constraints (e.g., filters cannot share state), and specific
yses for architectures that conform to specific styles.
instances of components or connectors (e.g., there must
be a database in the system). Different stylistic categories
range from abstract architectural patterns and idioms (such 3 Purpose of the panel
as “client-server” organization) to concrete “reference ar-
chitectures” (such as the ISO 0S1 communication model Whatever the long-term impact of software architecture
and the traditional linear decomposition of a compiler). may turn out to be, an appropriate starting point is a concrete
appraisal of the current state of the practice in the use of
software architecture. It is the purpose of this panel to take
2 Significance to software engineering a step in this direction. By assembling a panel of experts
with a broad base of experience in the area, we hope to
Architectural design of large systems has always played provide concrete examples of what is now possible when
a significant role in determining the ultimate success of a architectural principles are applied to industrial problems
system: choosing an inappropriate architecture can have in systematic ways, to consider the potential impact of
a disastrous effect. However, traditionally architectural software architecture over the next few years, and to suggest
design has been largely informal and ad hoc, with the re- steps that should be taken to bring this about.
sult that it has been difficult to communicate, analyze, and
compare architectural designs and principles. We believe
that the current interest in software architecture signals the References
emergence of a more disciplined basis for architectural de-
sign that has the potential to significantly improve our abil- [1] Gregory Abowd et al. Using style to give meaning to soft-
ity to construct effective software systems. ware architecture. In Proc. of SIGSOFT’93: Foundations of
Specifically, a principled use of software architecture Sojhvare Engineering, December 1993.
can have a positive impact on at least four aspects of soft- [2] Robert Allen and David Garlan. Formalizing architectural
ware development. connection. In Proc. of ICSE’16, May 1994.

1. Understanding: Software architecture simplifies our [3] David Garlan and Mary Shaw. An introduction to soft-
ability to comprehend large systems by presenting ware architecture. In Advances in Sojhvare Engineering and
Knowledge Engineering, Volume I. World Scientific Publish-
them at a level of abstraction in which the whole sys-
ing Company, 1993.
tem can be understood [3, 6]. Moreover, at its best,
architectural description exposes the high level con- [4] David C. Luckham et al. Partial orderings of event sets and
straints on system design as well as the rationale for their application to prototyping concu rrent timed systems,

making specific architectural choices. Unpublished draft of March 1992.

[5] Erik Mettala and Marc H. Graham. The domain-specific

2. Reuse: Architectural description supports reuse at
software architecture program. Technical Report CMU/SEI-
multiple levels. While most current work on reuse 92-SR-9, CMU Software Engineering Institute, June 1992.
focuses on component libraries, architectural design
[6] Dewayne E. Perry and Alexander L. Wolf. Foundations for
supports, in addition, both reuse of large components
the study of software architecture. ACM SIGSOFT Sojiware
(such as subsystems), and also the complementary
Engineering Notes, 17(4), 1992.
need for reusable frameworks into which components
can be integrated. Existing work on domain-specific
software architectures and reference frameworks have
already begun to provide evidence for this [5].

364