ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 40

F o u n d a t i o n s for t h e S t u d y of Software A r c h i t e c t u r e

Dewayne E. Perry Alexander L. Wolf

AT&T Bell Laboratories Department of Computer Science

600 Mountain Avenue University of Colorado
Murray Hill, New Jersey 07974 Boulder, Colorado 80309
[email protected] [email protected]

(~) 1989,1991,1992 Dewayne E. Perry and Alexander L. Wolf

ABSTRACT more toward integrating designs and the design process

into the broader context of the software process and
its management. One result of this integration was that
The purpose of this paper is to build the foundation many of the notations and techniques developed for soft-
for software architecture. We first develop an intuition ware design have been absorbed by implementation lan-
for software architecture by appealing to several well- guages. Consider, for example, the concept of support-
established architectural disciplines. On the basis of
ing "programmming-in-the-large". This integration has
this intuition, we present a model of software architec-
tended to blur, if not confuse, the distinction between
ture that consists of three components: elements, form,
and rationale. Elements are either processing, data, or design and implementation.
connecting elements. Form is defined in terms of the The 1980s also saw great advances in our ability to
properties of, and the relationships among, the elements describe and analyze software systems. We refer here to
- - that is, the constraints on the elements. The ratio- such things as formal descriptive techniques and sophis-
nale provides the underlying basis for the architecture in ticated notions of typing that enable us to reason more
terms of the system constraints, which most often derive effectively about software systems. For example, we are
from the system :requirements. We discuss the compo- able to reason about "consistency" and "inconsistency"
nents of the model in the context of both architectures
more effectively and we are able to talk about "type
and architectural styles and present an extended exam-
conformance" 1 rather than just "type equivalence".
ple to illustrate some important architecture and style
considerations. We conclude by presenting some of the The 1990s, we believe, will be the decade of software
benefits of our approach to software architecture, sum- architecture. We use the term "architecture", in con-
marizing our contributions, and relating our approach trast to "design", to evoke notions of codification, of
to other current work. abstraction, of standards, of formal training (of soft-
ware architects), and of style. While there has been
1 Introduction some work in defining particular software architectures
(e.g., [19, 22]), and even some work in developing gen-
Software design received a great deal of attention by eral support for the process of developing architectures
researchers in the 1970s. This research arose in response (notably SARA [8]), it is time to reexamine the role of ar-
to the unique problems of developing large-scale soft- chitecture in the broader context of the software 15rocess
ware systems first recognized in the 1960s [5]. The and software process management, as well as to marshal
premise of the research was that design is an activity the various new techniques that have been developed.
separate from implementation, requiring special nota- Some of the benefits we expect to gain from the emer-
tions, techniques:, and tools [3, 9, 17]. The results of gence of software architecture as a major discipline are:
this software design research has now begun to make in- 1) architecture as the framework for satisfying require-
roads into the marketplace as computer-aided software ments; 2) architecture as the technical basis for design
engineering (CASE) tools [7].
In the 1980s, the focus of software engineering re- 1Conformance is used to describe the relationship between
search moved away from software design specifically and types and subtypes.
 A C M SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 41

and as the managerial basis for cost estimation and pro- 2.1.1 Computing Hardware Architecture
cess managment; 3) architecture as an effective basis for
There are several different approaches to hardware
reuse; and 4) architecture as the basis for dependency
architecture that are distinguished by the aspect of the
and consistency analysis.
hardware that is emphasized. RISC machines are ex-
Thus, the primary object of our research is support amples of a hardware architecture that emphasizes the
for the development and use of software architecture instruction set as the important feature. Pipelined ma-
specifications. This paper is intended to build the foun- chines and multi-processor machines are examples of
dation for future research in software architecture. We hardware architectures that emphasize the configura-
begin in Section 2 by developing an intuition about tion of architectural pieces of the hardware.
software architecture against the background of well-
There are two interesting features of the second ap-
established disciplines such as hardware, network, and proach to hardware architecture that are important in
building architecture, establish the context of software our consideration of software architecture:
architecture, and provide the motivation for our ap-
proach. In Section 3, we propose a model for, and a • there are a relatively small number of design ele-
characterization of, software architecture and software ments; and
architectural styles. Next, in Section 4, we discuss an
• scale is achieved by replication of these design ele-
easily understood example to elicit some important as-
ments.
pects of software architecture and to delineate require-
ments for a software-architecture notation. In Section 5, This contrasts with software architecture, where there is
we elaborate on two of the major benefits of our ap- an exceedingly large number of possible design elements.
proach to software architecture. We conclude, in Sec- Further, scale is achieved not by replicating design el-
tion 6, by summarizing the major points made in this ements, but by adding more distinct design elements.
paper and considering related work. However, there are some similarities: we often organize
and configure software architectures in ways analogous
to the h ~ d w a r e architectures mentioned above. For ex-
2 Intuition, Context, and Motivation ample, we create multi-process software systems and use
pipelined processing.
Before presenting our model of software architecture, Thus, the important insight from this discussion is
we lay the philosophical foundations for it by: 1) devel- that there are fundamental and important differences
oping an intuition about software architecture through between the two kinds of architecture. Because of these
analogies to existing disciplines; 2) proposing a con- differences, it is somewhat ironic that we often present
text for software architecture in a multi-level product software architecture in hardware-like terms.
paradigm; and 3) providing some motivation for soft-
ware architecture as a separate discipline. 2.1.2 Network Architecture

Network architectures are achieved by abstracting the

2.1 Developing an Intuition about Soft- design elements of a network into nodes and connec-
ware Architecture tions, and by naming the kinds of relationships that
these two elements have to each other. Thus we get
It is interesting to note that we do not have named star networks, ring networks, and manhattan street net-
software architectures. We have some intuition that works as examples of named network architectures.
there are different kinds of software architectures, but The two interesting architectural points about net-
we have not formalized, or institutionalized, them. It is work architecture are:
our claim that it is because there are so many software
architectures, not because there are so few, that the • there are two components - - nodes and connec-
present state of affairs exists. In this section we look at tions; and
several architectural disciplines in order to develop our
• there are only a few topologies that are considered.
intuition about software architecture. We look at hard-
ware and network architecture because they have tra- It is certainly the case that we can abstract to a similar
ditionally been considered sources of ideas for software level in software architecture - - for example, processes
architecture; we look at building architecture because it and inteprocess communication. However, rather than
is the "classical" architectural discipline. a few topologies to consider, there are an exceedingly
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 42

large number of possible topologies and those topolo- view. Descriptively, architectural style defines a partic-
gies generally go without names. Moreover, we empha- ular codification of design elements and formal arrange-
size aspects different from the topology of the nodes and ments. Prescriptively, style limits the kinds of design
connections. We consider instead such matters as the elements and their formal arrangements. T h a t is, an
placement of processes (e.g., dislribuled architectures) architectural style constrains both the design elements
or the kinds of interprocess communication (e.g., mes- and the formal relationships among the design elements.
sage passing architectures). Analogously, we shall find this a most useful concept in
Thus, we do not benefit much from using networks software architecture.
as an analogy for software architecture, even though we Of extreme importance is the relationship between
can look at architectural elements from a similar level engineering principles and architectural style (and, of
of abstraction. course, architecture itself). For example, one does not
get the light, airy feel of the perpendicular style as ex-
2.1.3 Building Architecture emplified in the chapel at King's College, Cambridge,
from romanesque engineering. Different engineering
The classical field of architecture provides some of principles are needed to move from the massiveness of
the more interesting insights for software architecture. the romanesque to lightness of the perpendicular. It is
While the subject matter for the two is quite different, not just a m a t t e r of aesthetics. This relationship be-
there are a number of interesting architectural points tween engineering principles and software architecture
in building architecture that are suggestive for software is also of fundamental importance.
architecture: Finally, the relationship between architectural style
and materials is of critical importance. The materi-
• multiple views;
als have certain properties that are exploited in pro-
• architectural styles; viding a particular style. One may combine structural
with aesthetic uses of materials, such as that found in
• style and engineering; and the post and beam construction of tudor-style houses.
However, one does not build a skyscraper with wooden
• style and materials. posts and beams. The material aspects of the design
elements provide both aesthetic and engineering bases
A building architect works with the customer by
for an architecture. Again, this relationship is of critical
means of a number of different views in which some
importance in software architecture.
particular aspect of the building is emphasized. For
Thus, we find in building architecture some funda-
example, there are elevations and floor plans that give
mental insights about software architecture: multiple
the exterior views and "top-down" views, respectively.
views are needed to emphasize and to understand dif-
The elevation views may be supplemented by contextual
ferent aspects of the architecture; styles are a cogent
drawings or even scale models to provide the customer
and important form of codification that can be used
with the look of the building in its context. For the
both descriptively and prescriptively; and, engineering
builder, the archite.ct provides the same floor plans plus
principles and material properties are of fundamental
additional structural views that provide an immense
importance in the development and support of a partic-
amount Q£detail about various explicit design consider-
ular architecture and architectural style.
ations such as electrical wiring, plumbing, heating, and
air-conditioning.
2.2 The Context of Architecture
Analogously, the software architect needs a number of
different views of the software architecture for the var- Before discussing our motivation for software archi-
ious uses and users. At present we make do with only tecture specifications, we posit a characterization of ar-
one view: the implementation. In a real sense, the im- chitecture in the context of the entire software product.
plementation is like a builders detailed view - - that is, Note that we do not mean to imply anything about the
like a building with no skin in which all the details are particular process by which this product is created - -
visible. It is very difficult to abstract the design and ar- though of course there may be implications about the
chitecture of the system from all the details. (Consider process that are inherent in our view. Our purpose is
the Pompidou Center in Paris as an example.) primarily to provide a context for architecture in what
The notion of architectural style is particularly use- would be considered a fairly standard software product.
ful from both descriptive and prescriptive points of We characterize the different parts of the software
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 43

product by the kinds of things that are important for to software architecture are evolution and customiza-
that part - - the kinds of entities, their properties and tion. Systems evolve and are adapted to new uses, just
relationships that are important at that level, and the as buildings change over time and are adapted to new
kinds of decision and evaluation criteria that are rele- uses. One frequently accompanying property of evolu-
vant at that level: tion is an increasing brittleness of the system - - that is,
an increasing resistance to change, or at least to chang-
requirements are concerned with the determination
ing gracefully [5]. This is due in part to two architec-
of the information, processing, and the character-
tural problems: architectural erosion and architectural
istics of that information and processing needed by
drift. Architectural erosion is due to violations of the ar-
the user of the system; 2
chitecture. These violations often lead to an increase in
architecture is concerned with the selection of archi- problems in the system and contribute to the increasing
tectural elements, their interactions, and the con- brittleness of a system - - for example, removing load-
straints on those elements and their interactions bearing walls often leads to disastrous results. Architec-
necessary to provide a framework in which to sat- tural drift is due to insensitivity about the architecture.
isfy the requirements and serve as a basis for the This insensitivity leads more to inadaptability than to
design; disasters and results in a lack of coherence and clarity
of form, which in turn makes it much easier to violate
design is concerned with the modularization and the architecture that has now become more obscured.
detailed interfaces of the design elements, their Customization is an important factor in software ar-
algorithms and procedures, and the data types chitecture, not because of problems that it causes, but
needed to support the architecture and to satisfy because of the lack of architectural maturity that it in-
the requirements; and dicates. In building software systems, we are still at
the stage of recreating every design element for each
implementation is" concerned with the representa-
new architecture. We have not yet arrived at the stage
tions of the algorithms and data types that satisfy
where we have a standard set of architectural styles
the design, architecture, and requirements.
with their accompanying design elements and formal
The different parts of a particular product are by no arrangements. Each system is, in essence, a new ar-
means as simple as this characterization. There is a chitecture, a new architectural style. The presense of
continuum of possible choices of models, abstractions, ubiquitous customization indicates that there is a gen-
transformations, and representations. We simplify this eral need for codification - - that is, there is a need for
continuum into four discrete parts primarily to provide architectural templates for various architectural styles.
an intuition about how architecture is related to the For the standard parts of a system in a particular style,
requirements and design of a software system. the architect can select from a set of well-known and
It should be noted that there are some development understood elements and use them in ways appropriate
paradigms to which our characterization will not apply to the desired architecture. This use of standard tem-
- - for example, the exploratory programming paradigm plates for architectural elements then frees the architect
often found in AI research. However, our characteriza- to concentrate on those elements where customization
tion represents a wide variety of development and evo- is crucial.
lutionary paradigms used in the creation of production Given our characterization of architecture and moti-
software, and delineates an important, and hitherto un- vating problems, there are a number of things that we
derconsidered, part of a unified software product [15]. want to be able to do with an architectural specification:

* Prescribe the architectural constraints rid the desired

2.3 Motivation for Architectural Speci- level - - that is, indicate the desired restrictiveness
fications or permissiveness, determine the desired level of
generality or particularity, define what is necessity
There are a number of factors that contribute to the
and what is luxury, and pin-point the degree of rel-
high cost of software. Two factors that are important
ativeness and absoluteness. We want a means of
2 N o t e t h a t t h e n o t i o n of r e q u i r e m e n t s p r e s e n t e d h e r e is a n ide-
supporting a "principle of least constraint" to be
a i i s t i c one. I n p r a c t i c e , r e q u i r e m e n t s are n o t so " p u r e " ; t h e y o f t e n able to to express only those constraints in the ar-
c o n t a i n c o n s t r a i n t s on t h e a r c h i t e c t u r e of a s y s t e m , c o n s t r a i n t s on chitecture that are necessary at the architectural
the system design, a n d e v e n c o n s t r a i n t s on t h e i m p l e m e n t a t i o n . level of the system description. This is an impor-
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 44

tant departure from current practice that, instead • processing elements;

of specifying 1;he constraints, supplies specific solu-
• data elements; and
tions that embody those desired constraints.
• connecting elements.
• Separate aest~ietics from engineering - - that is, in-
dicate what is "load-bearing" from what is "dec- The processing elements are those.components that sup-
oration". This separation enables us to avoid the ply the transformation on the data elements; the data
kinds of changes that result in architectural erosion. elements are those that contain the information that is
used and transformed; the connecting elements (which
• Express different aspects of the architecture in an at times may be either processing or data elements,
appropriate manner - - that is, describe different or both) are the glue that holds the different pieces
parts of the architecture in an appropriate view. of the architecture together. For example, procedure
calls, shared data, and messages are different examples
• Perform dependency and consistency analysis - -
of connecting elements that serve to "glue" architectural
that is, determine the interdependencies between
elements together.
architecture, requirements and design; determine
Consider the example of water polo as a metaphor for
interdependencies between various parts of the ar-
the different classes of elements: the swimmers are the
chitecture; and determine the consistency, or lack
processing elements, the ball is the data element, and
of it, between architectural styles, between styles
water is the primary connecting element (the "glue").
and architecture, and between architectural ele-
Consider further the similarities of water polo, polo, and
ments.
soccer. They all have a similar "architecture" but dif-
fer in the "glue" - - that is, they have similar elements,
3 Model of Software Architecture shapes and forms, but differ mainly in the context in
which they are played and in the way that the elements
In Section 2 we use the field of building architecture are connected together. We shall see below that these
to provide a number of insights into what software ar- connecting elements play a fundamental part in distin-
chitecture might be. The concept of building architec- guishing one architecture from another and may have
ture that we appeal to is that of the standard definition: an important effect on the characteristics of a particu-
"The art or science of building: especially designing and lar architecture or architectural style.
building habital structures" [11]. Perhaps more relevant The architectural form consists of weighted proper-
to our needs here is a secondary definition: "A unifying ties and relationships. The weighting indicates one of
or coherent form or structure" [11]. It is this sense of two things: either the importance of the property or the
architecture - - providing a unifying or coherent form relationship, or the necessity of selecting among alterna-
or structure - - that infuses our model of software archi- tives, some of which may be preferred over others. The
tecture. use of weighting to indicate importance enables the ar-
We first present our model of software architecture, chitect to distinguish between "load-bearing" and "dec-
introduce the notion of software architectural style, and orative" formal aspects; the use of weighting to indicate
discuss the interdependence of processing, data, and alternatives enables the architect to constrain the choice
connector views. while giving a degree of latitude to the designers who
must satisfy and implement the architecture.
3.1 The Model Properties are used to constrain the choice of archi-
tectural elements - - that is, the properties are used to
By anMogy to building architecture, we propose the
define constraints on the elements to the degree desired
following model of software architecture:
by the architect. Properties define the minimum de-
Software Architecture = sired constraints unless otherwise stated - - that is, the
{ Elements, Form, Rationale } default on constraints defined by properties is: "what
is not constrained by the architect may take any form
T h a t is, a software architecture is a set of architectural desired by the designer or implementer".
(or, if you will, design) elements that have a particular Relationships are used to constrain the "placement"
form. of architectural elements - - that is, they constrain how
We distinguish three different classes of architectural the different elements may interact and how they are
elements: organized with respect to each other in the architecture.
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 45

As with properties, relationships define the minimum 3.3 Process/Data/Connector

desired constraints unless otherwise stated. Interdependence
An underlying, but integral, part of an architecture is
the rationale for the various choices made in defining an As mentioned above, an important insight from build-
architecture. The rationale captures the motivation for ing architecture is that Of multiple views. Three im-
the choice of architectural style, the choice of elements, portant views in software architecture are those of pro-
and the form. In building architecture, the rationale cessing, data, and connections. We observe that if a
explicates the underlying philosophical aesthetics that process view 3 of an architecture is provided, the result-
motivate the architect. In software architecture, the ing emphasis is on the data flow though the processing
rationale instead explicates the satisfaction of the sys- elements and on some aspects of the connections be-
tem constraints. These constraints are determined by tween the processing elements with respect to the data
considerations ranging from basic functional aspects to elements. Conversely, if a data view of an architecture
various non-functional aspects such as economics [4], is provided, the resulting emphasis is on the process-
performance [2] and reliability [13]. ing flow, but with less an emphasis on the connecting
elements than we have in the process view. While the
3.2 Architectural Style current common wisdom seems to put the emphasis on
object-oriented (that is, data-oriented) approaches, we
If architecture is a formal arrangement of architec- believe that all three views are necessary and useful at
tural elements, then architectural style is that which the architectural level.
abstracts elements and formal aspects from various spe-
We argue informally, in the following way, that there
cific architectures. An architectural style is less con-
is a process and data interdependence:
strained and less complete than a specific architecture.
For example, we might talk about a distributed style or
• there are some properties that distinguish one state
a multi-process style. In these cases, we concentrate on
of the data from another; and
only certain aspects of a specific architecture: relation-
ships between processing elements and hardware pro-
cessors, and constraints on the elements, respectively. • those properties are the result of some transforma-
Given this definition of architecture and architectural tion produced by some processing element.
style, there is no hard dividing line between where ar-
chitectural style leaves off and architecture begins. We These two views are thus intertwined - - each dependent
have a continuum in which one person's architecture on the other for at least some of the important charac-
may be another's architectural style. Whether it is an teristics of both data and processing. (For a more gen-
architecture or a style depends in some sense on the eral discussion of process and data interdependence, see
use. For example, we propose in Section 2.3 that archi- [10].)
tectural styles be used as constraints on an architecture. The interdependence of processing and data upon the
Given that we want the architectural specification to be connections is more obvious: the connecting elements
constrained only to the level desired by the architect, are the mechanisms for moving data around from pro-
it could easily happen that one person's architecture cessor to processor. Because of this activity upon the
might well be less constrained than another's architec- data, the connecting elements will necessarily have some
tural style. of the properties required by the data elements in pre-
The important thing about an architectural style cisely the same way that processing elements have some
is that it encapsulates important decisions about the of the properties required by the data elements.
architectural elements and emphasizes important con- At the architectural level, we need all three views
straints on the elements and their relationships. The and the ability to move freely and easily among them.
useful thing about style is that we can use it both to Our example in the next section provides illustrations
constrain the architecture and to coordinate cooperat- of this interdependence and how we might provide three
ing architects. Moreover, style embodies those decisions different, but overlapping, views.
that suffer erosion and drift. An emphasis on style as
a constraint on the architecture provides a visibility to
3 We use the d i c h o t o m y of process a n d data i n s t e a d of.functi0n
certain aspects of the architecture so that violations of
a n d object b e c a u s e these t e r m s s e e m to be m o r e n e u t r a l . T h e
those aspects and insensitivity to them will be more l a t t e r t e r m s seem to suggest s o m e t h i n g m o r e specific in t e r m s of
obvious. p r o g r a m m i n g t h a n the former.
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES voi 17 no 4 Oct 1992 Page 46

4 Examples data elements: characters, tokens, phrases,

correlated phrases, annotated
One of the few software architectural styles that has phrases, and object code.
achieved widespread acceptance is that of the multi-
phase compiler. It is practically the only style in Notice that we have not specified connecting elements.
which every software engineer is expected to have been It is simply the case that this style does not dictate
trained. We rely on this familiarity to illustrate some what connecting elements are to be used. Of course, the
of the insights that we have gained into software archi- choice of connecting elements has a profound impact on
tectures and their descriptions. the resulting architecture, as shown below.
In this section we look at two compiler architectures The form of the architectural style is expressed by
of the multi-phase style: weighted properties and relationships among the archi-
tectural elements. For example, the optimizer and an-
• a compiler that is organized sequentially; and
notated phrases must be found together, but they are
• a compiler that is organized as a set of parallel pro- both only preferred elements, not necessary. As an-
cesses connected by means of a shared internal rep- other example, there are linear relationships between
resentation. the characters constituting the text of the program, the
tokens produced by the lexer, and the phrases produced
Because of space limitations and for presentation pur-
by the parser. In particular, tokens consist of a sequence
poses, our examples are somewhat simplified and ideal-
of characters, and phrases consist of a sequence of to-
ized, with many details ignored. Moreover, we use exist-
kens. However, there exists a non-linear relationship
ing notations because they are convenient for illustrative
between phrases and correlated phrases. These relation-
purposes; proposals for specific architectural notations
ships are depicted in Figure 1. As a final example, each
are beyond the scope of this paper. In each case we focus
of the processing elements has a set of properties that
on the architectural considerations that seem to be the
defines the constraints on those elements. The lexer, for
most interesting to derive from that particular example.
instance, takes as input the" characters that represent
(Of course, other examples of multi-phase compiler ar-
the program text and produces as output a sequence of
chitectures exist and we make no claims of exhaustive
tokens. Moreover, there is an ordering correspondence
coverage of this architectural landscape.) Before explor-
between the tokens and the characters that must be
ing these examples, we provide a brief review of their
preserved by the lexer. A good architectural descrip-
common architectural style.
tion would capture these and other such properties and
relationships.
4.1 The Multi-phase Architectural Let us illustrate this by formally describing the rela-
Style tionship between characters and tokens and describing
Our simplified model of a compiler distinguishes five the order-preserving property of the lexer. We begin
phases: lexical analysis, syntactic analysis, semantic the description with a data view stated in terms of se-
analysis, optimization, and code generation. Lexical quences and disjoint subsequences.
analysis acts on ,characters in a source text to produce Let C = {cl,c2,...,Cm} be a sequence of char-
tokens for syntactic analysis. Syntactic analysis pro- acters representing a source text, C~ i _~ j be a
duces phrases that are either definition phrases or use subsequence of C whose elements are all the el-
phrases. Semantic analysis correlates use phrases with ements in C between ci and cj inclusive, T ----
definition phrases - - i.e., each use of a program element { t l , t 2 , . . . , t n } be a sequence of tokens, and "~"
such as an identifier is associated with the definition for indicate the correspondence between a token in T
that element, resulting in correlated phrases. Optimiza- and a subsequence of C. T is said to preserve C
tion produces annotations on correlated phrases that ff there exists an i, j, k, q, r, and s such that
1 _ < i < j _ < m , 1 < k < n, 1 < q ~_ r < m, and
are hints used during generation of object code. The
for all t E T there exists a C~ such that:
optimization phase is considered a preferred, but not
necessary, aspect of this style. Thus, the multi-phase [ C~ if t = tl
style recognizes the following architectural elements: C~ if t = tn
l_<u_<q-1
processing elements: lexer, parser, semantor, op-
Crq if $ = t~, where S u, V tk-1 = C~-1
u
timizer, and code generator;
and tk+l --~ C~+1
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 47

Characters
Tokens L ~ I L l I I L _ _ I I I I I L ~ J I I

Phrases L ~ I L l L I I I L J

Correlated Phrases i ..............

•
÷ ...............................
,

F i g u r e 1: D a t a E l e m e n t Relationships.

The lexer is now constrained from a processing perspec-

tive to accept a sequence of characters C, produce a Characters
sequence of tokens T, and to preserve the ordering cor-
respondence between characters and tokens: Tokens
OVT) ,,,,,,,~@
lexer: C ---+T, where T preserves C

Finally, it is interesting to note that the connec-

tor view reveals additional constraints that should be
placed on the architectural style. These constraints are ObJect Code
I
Phrases
(NT+AST)
illustrated by the connection between the lexer and the
parser. In particular, connecting elements must ensure Y
G<
that the tokens produced by the lexer are preserved for
Correlated Phrases
the parser, such that the order remains intact and that (NT~ASG)
there are no losses, duplicates, or spurious additions.
Annotated Cor. Phrases CorrelatedPhrases
(NT+AASG) (NT+ASG)
4.2 Sequential Architecture
If there is a "classical" multi-phase compiler archi-
tecture, then it is the sequential one, in which each
phase performs its function to completion before the
next phase begins and in which data elements are passed Figure 2: Processing View o f Se-
directly from one processing element to the other. Thus, quential Compiler Ar-
we add the following architectural elements to those chitecture.
characterizing the overall style:
created and transformed as they flow through the sys-
connecting elements: procedure call and parame- tem. We have found that the data view is best captured
ters. by a notion that we call application-oriented properties.
Application-oriented properties describe the states of a
Furthermore, we refine tokens to include the structur-
data structure that are of significance to the process-
ing of the identifier tokens into a name table (NT), and
ing elements manipulating that structure. They can be
refine phrases to be organized into an abstract syntax
used for such things as controlling the order of process-
tree (AST). Correlation of phrases results in an abstract
ing, helping to define the effects of a processing element
syntax graph (ASG) and optimization in an annotated on a data structure, and even helping to define the op-
abstract syntax graph (AASG). Figure 2 gives a process- erations needed by the processing elements to achieve
ing view of the sequential architecture, showing the flow
those effects.
of data through the system. Notice that there are two
For this example, the (simplified) application-
paths from the semantor to the code generator, only one
oriented properties are as follows:
of which passes through the optimizer. This reflects the
fact that a separate optimization phase is not necessary
in this architecture. T h a t is, a design satisfying this has-all-tokens: a state produced as a result of lex-
architecture need not provide an optimizer. ically analyzing the program text,
To illustrate the interdependence of processing and necessary for the parser to begin
data views, let us consider the data as a whole being processing;
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 48

has-alLphrases: a state produced by the parser,

necessary for the semantor to be-
"•xer
gin processing;
has-all-correlated-phrases: a state produced by the
semantor, necessary for the opti- l~r'ser
mizer and code generator to begin
processing; and
has-all-optimizalion-annotations: a state produced
by the optimizer, preferred for the
code generator to begin process-
ing.
1~'~CneO~tor Code ,/
Notice again that the last property is only preferred.
While in this example the application-oriented proper- Optimizer m C~r~a/~te~d.
ties may appear obvious and almost trivial, in the next
example they are crucial to the description of the archi-
tecture and in guaranteeing the compliance of designs F i g u r e 3: Data View of S e q u e n t i a l
and implementations with that architecture. Compiler Architecture.
An interesting question to consider is why we evi-
dently chose to use a property-based scheme for de- view concentrates on the particular application-oriented
scribing architectural elements rather than a type-based properties that are of importance in describing each
scheme. The rea~3on is that type models, as they cur- data structure, while the processing view concentrates
rently exist, are essentially only able to characterize el-
on the functional properties of each processing element.
ements and element types in terms of the relationship
These views are actually complementary. In fact, if we
of one element type to another (e.g., subtyping and in- depict the data view, as is done in Figure 3, and com-
heritance [12]), in terms of the relationships that par- pare it to the processing view, shown in Figure 2, then
ticular elements :have with other elements (e.g., as in the correspondence becomes fairly obvious.
Ortos [18]), and in terms of the operations that can The important architectural considerations that de-
be performed on the elements. They are not suited to rive from this example can be summarized as follows:
descriptions of characteristics of elements such as the
application-oriented properties mentioned above. For • the form descriptions must include the relation-
example, simply knowing that there is an operation as- ships and constraints among the elements, includ-
sociated with abstract syntax graphs to connect one ing relative weightings and preferences;
phrase to another does not lead to an understanding
that the abstract syntax graph must have all phrases • current type-based schemes for characterizing ele-
correlated before the code generator can access the ments are insufficient; and
graph. • there is a natural interdependence between the pro-
Property-based schemes, on the other hand, can be cessing and data views that can provide comple-
used to capture easily all these characteristics; one prop- mentary descriptions of an architecture.
erty of an element could be the set of operations with
which it is associated. It seems reasonable to consider
4.3 Parallel Process, Shared Data
enhancing type models in this regard and we see this
Structure Architecture
as a potentially interesting area of future work. We
note, however, that type-based schemes are already ap- Suppose that performance is of paramount impor-
propriately used at the design level, as mentioned in tance, such that one wants to optimize the speed of
Section 2. Further, we note that application-oriented the compiler as much as possible. One possible solution
properties provide a good vehicle with which to drive is to adopt an architecture that treats the processing
the design, or justify the suitability, of a set of opera- elements as independent processes driven by a shared
tions for an element type. internal representation - - that is, the connecting ele-
Returning to the interdependence between the pro- ment is the shared representation and each processing
cessing and data views, we can see that the data element performs eager evaluation. Figure 4 depicts a
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 49

sic properties must be explicitly described. A num-

Characters ) ber of notations exist that are suitable for making
such descriptions, including parallel path expressions
[6], constrained expressions [1], and petri nets [16]. In
L this example we use parallel path expressions, where
a comma indicates sequence, a plus sign indicates one
or more repetitions, an asterisk indicates zero or more
repetitions, and subexpressions are enclosed in paren-
theses. Synchronization points occur where names of
Internal
Representation application-oriented properties are the same in differ-
ent parallel path expressions. First, the path expres-
sions for each of the data elements - - tokens, phrases,
and correlated phrases - - are given:

(1) (no-tokens, has-token+) *,

will-be-no-more-tokens, has-token*, no-tokens
F i g u r e 4: P a r t i a l P r o c e s s V i e w of (2) (no-phrases, has-phrase+) * ,
Parallel Process, Shared will-be-no-more-phrases, has-phrase*, no-phrases
Data Structure Com- (3) no-correlated-phrases, (have-correlated-phrases)*,
piler Architecture. all-phrases-correlated

Next, the path expressions relating the application-

simplified and partial process view of this architecture, oriented properties are given:
showing the relationships between the internal repre-
sentation and the lexer, the parser, and the semantor. (4) will-be-no-more-tokens, will-be-no-more-phrases,
(We only consider these three processing elements in the all-plirases-correlated
remainder of this example.) (5) has-token + , has-phrase
The application-oriented properties of the shared in- (6) has-phrase +, has-correlated-phrase
ternal representation in this architecture are much more
Thus, tokens are consumed to produce phrases, and
complicated, and interesting, than those given in the
phrases are correlated until they are all processed.
previous example. In particular, a number of process-
What we have given so far is essentially a connector
ing elements are affecting the state of the internal repre-
sentation, and doing so concurrently. This implies that view (and, in this case, effectively a data view as well).
the application-oriented properties must provide for co- Concentrating instead on the processing view allows us
ordination and synchronization among the processing to describe how each processing element transforms the
internal representation as well as how those processing
elements. We begin by giving the basic properties that
the internal representation may exhibit: elements are synchronized:

no-tokens lexer: (no-tokens, has-token +) ~,

has-token will-be-no-more-tokens
will-be-no-more-tokens
no-phrases parser: no-phrases, (has-token +, has-phrase)*,
has-phrase will-be-no-more-tokens, (has-token + ,
will-be-no-more-phrases has-phrase)*, no-tokens,
no- correlated-phrases will-be-no-more-phrases
have- correlated-phrases
all-phrases- correlated semantor: no-correlated-phrases, (has-phrase + ,
has-correlated-phrase)*,
Notice that these properties imply that tokens and will-be-no-more-phrases, (has-phrase + ,
phrases are consumed, but that correlated phrases has-correlated-phrase)*, no-phrases,
are accumulated (consider "has-phrase" versus "have- all-phrases- correlated
correlated-phrases").
Because of the parallel behavior of the processing el- An interesting question to ask is how this architec-
ements, the interrelationships among the various ba- ture relates to the previous one. In fact, the ability to
 ACM SIGS OFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 50

relate similar architectures is an important aspect of the 5.1 Software Architecture and Analysis
software process; an example is the evaluation of "com-
Aside from providing clear and precise documenta-
peting" architectures. Certainly, the architectures both
tion, the primary purpose of specifications is to provide
being of a common style captures some portion of the
automated analysis of the documents and to expose var-
relationship. More can be said, however, given the use
ious kinds of problems that would otherwise go unde-
of application-oriented properties. In particular, we can
tected. There are two primary categories of analysis
draw correlation~3 among the properties of the different
that we wish to perform: consistency and dependency
architectures. The table below shows some of these cor-
relations. analysis. Consistency occurs in several dimensions: con-
sistency within the architecture and architectural styles,
Sequential A r c h i t e c t u r e Parallel A r c h i t e c t u r e consistency of the architecture with the requirements,
has-all-tokens will-be-no-more-tokens and consistency of the design with the architecture. In
has-all-phrases will-be-no-more-pharses the same way that Inscape [14] formally and automat-
has-all-correlated-phrases all-phrases-correlated ically manages the interdependencies between interface
specifications and implementations, we also want to be
In this case, the correlations indicate common points able to manage the interdependencies between require-
of processing, leading, for instance, to a better under- ments, architecture, and design.
standing of the possible reusability of the processing Therefore, we want to provide and support at least
elements. the following kinds of analysis:
The important points of this example can be summa-
rized as follows: • consistency of architectural style constraints;

• satisfaction of architectural styles by an architec-

• the processing elements are much the same as in ture;
the previous architecture, but with different "locus
of control" properties; consistency of architectural constraints;

• the form of this architecture is more complex satisfaction of the architecture by the design;
than that of the previous one - - there are more
application-oriented properties and those proper- establishment of dependencies between architec-
ties require a richer notation to express them and ture and design, and architecture and require-
their interrelationships; ments; and

determination of the implications of changes in ar-

• we still benefit from the processing/data/connector
chitecture or architectural style on design and re-
view interdependence, albeit with more complexity;
quirements, and vice versa.
and

• application-oriented properties are useful in relat- 5.2 Architecture and the Problems of
ing similar architectures. Use and Reuse

An important aspect in improving the productivity

5 Some Benefits Derived from Software of the designers and the programmers is that of being
Architecture able to build on the efforts of others - - that is, using
and reusing components whether they come as part of
We have previously mentioned the use of software ar- another system or as parts from standard components
chitecture in the context of requirements and design. catalogs.
Software architecture provides the framework within There has been much attention given to the problem
which to satisfy the system requirements and provides of finding components to reuse. Finding components
both the technical and managerial basis for the design may be important in reducing the duplication of effort
and implementation of the system. There are two fur- and code within a system, but it is not the primary
ther benefits that. we wish to discuss in detail: the kinds issue in attaining effective use of standardized compo-
of analysis that software architecture specifications will nents. For example, finding the components in a math
enable us to perform and the kinds of reuse that we gain library is not an issue. The primary issue is under-
from our approach to software architecture. standing the concepts embodied in the library. If they
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 51

are understood, then there is usually no problem find- the necessary features of architectural description tech-
ing the appropriate component in the library to use. If niques and their supporting infrastructure. In so doing,
they are ndt understood, then browsing will help only we have set a direction for future research that should
in conjunction with the acquisition of the appropriate establish the primacy of software architecture.
concepts. Others have begun to look at soft'rare architecture.
The primary focus in architecture is the identification Three that are most relevant are Schwanke, et al., Zach-
of important properties and relationships - - constraints man, and Shaw.
on the kinds of components that are necessary for the Schwanke, et al., [20] define architecture as the per-
architecture, design, and implementation of a system. mitted or allowed set of connections among components.
Given this as the basis for use and reuse, the architect, We agree that that aspect of architecture is important,
designer, or implementer may be able to select the ap- but feel that there is much more to architecture than
propriate architectural element, design element, or im- simply components and connections, as we demonstrate
plemented code to satisfy the specified constraints at in this paper.
the appropriate level. Zachman [23] uses the metaphor of building architec-
Moreover, the various parts of previously imple- ture to advantage in constructing an architecture for
mented software may be teased apart to select that information systems. He exploits the notion of differ-
which is useful from that which is not. For example, ent architectural documents to provide a vision of what
the design of a component from another system may the various documents ought to be in the building of
have just the right architectural constraints to satisfy an information system. The architect is the mediator
a particular architectural element, but the implementa- between the user and the builders of the system. The
tion is constrained such that-it conflicts with other sys- various documents provide the various views of different
tem constraints. The solution is to use the design but parts of the product - - the users view, the contractors
not the implementation: This becomes possible only by views, etc. His work differs from ours in that he is
indentifying the architectural, design, and implemen- proposing a specific architecture for a specific applica-
tation constraints and use them to satisfy the desired tion domain while we are attempting to define the philo-
goals of the architecture, design, and implementation. sophical underpinnings of the discipline, to determine a
The important lesson in reusing components is that notation for expressing the specification of the various
the possibilities for reuse are the greatest where specifi- architectural documents, and determine how these doc-
cations for the components are constrained the least - - uments can be used in automated ways.
at the architectural level. Component reuse at the im-
Shaw [21] comes the closest in approach to ours. She
plementation level is usually too late because the imple-
takes the view of a programming language designer and
mentation elements often embody too many constraints.
abstracts classes of components, methods of composi-
Moreover, consideration of reuse at the architectural
tion, and schemas from a wide variety of systems. These
level may lead development down a different, equally
correspond somewhat to our notions of processing and
valid solution path, but one that results in greater reuse.
data elements, connecting elements, and architectural
style, respectively. One major difference between our
6 Conclusions work and Shaw's is that she is taking a traditional type-
based approach to describing architecture, while we
Our efforts over the past few years have been directed are taking a more expressive property-based approach.
toward improving the software process associated with Our approach appears better able to more directly cap-
large, complex software systems. We have come to be- ture notions of weighted properties and relationships.
lieve that software architecture can play a vital role in Shaw's approach of abstracting the various properties
this process, but that it has been both underutilized and and relationships of existing architectures and embody-
underdeveloped. We have begun to address this sit- ing them in a small set of component and composition
uation by establishing an intuition about and context types appears rather restrictive. Indeed, she is seeking
for software architecture and architectural style. We to provide a fixed set of useful architectural elements
have formulated a model of software architecture that that one can mix and match to create an architecture.
emphasizes the architectural elements of data, process- Shaw's approach is clearly an important and useful one
ing, and connection, highlights their relationships and and does much to promote the understanding of basic
properties, and captures constraints on their realization and important architectural concepts. Our approach,
or satisfaction. Moreover, we have begun to delineate on the other hand, emphasizes the importance of the
 ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 52

underlying properties and relationships as a more gen- [14] D.E. Perry, The lnscape
eral mechanism that can be used to describe the partic- Environment, Proc. Eleventh Inter. Conf. on Soft-
ular types of elements and compositions in such a way ware Engineering, Pittsburgh, PA, IEEE Computer
Society Press, May 1989, pp. 2-12.
that provides a latitude of choice.
In conclusion, we offer the following conjecture: per- [15] D.E. Perry, Industrial Strength Software Development
haps the reason for such slow progress in the develop- Environments, Proe. I F I P Congress '89, T h e 11th
W o r l d C o m p u t e r Congress, San Francisco, CA,
ment and evolution of software systems is that we have Aug. 1989.
trained carpenters and contractors, but no architects.
[16] J.L. Peterson, Petri Nets, A C M C o m p u t i n g Sur-
veys, Vol. 9, No. 3, Sept. 1977, pp. 223-252.
REFERENCES [17] W.E. Riddle and J.C. Wileden, T u t o r i a l on Software
System Design: Description and .Analysis, Com-
[1] G.S. Avrulfin, L.K. Dillon., J.C. Wfleden, and puter Society Press, 1980.
W.E. Riddle, Constrained Expressions: Adding Anal-
[18] W.R. Rosenblatt, J.C. Wfleden, and A.L. Wolf, OROS:
ysis Capab~ties to Design Methods for Concurrent
Systems, I E E E Trans. on Software Engineering, Towards a Type Model for Software Development
Vol. SE-12, No. 2, Feb. 1986, pp. 278-292. Environments, Proe. O O P S L A ~89, New Orleans,
Louisiana, October 1989.
[2] J.L. Bentley, 'Writing Efficient P r o g r a m s , Addison-
[19] E. Sandewall, C. StrSmberg, and H. SSrensen, Software
Wesley, Reading, MA, 1982.
Architecture Based on Communicating Residential En-
[3] G.D. Bergland, A Guided Tour of Program Design vironments, Proc. F i f t h Inter. Conf. on Software
Methodologies, I E E E C o m p u t e r , Vol. 14, No. 10, Engineering, San Diego, CA, IEEE Computer Society
Oct. 1981, pp. 13-37. Press, Mar. 1981, pp. 144-152.
[4] B.W. Boehm, Software Engineering Economics, [20] R.W. Schwanke, R.Z. Altucher, and M.A. Platoff, Dis-
Prentice-Hail, Englewood Cliffs, N J, 1981. covering, Visualizing and Uontrolling Software Struc-
ture, Proe. Fifth Inter. W o r k s h o p on Soft-
[5] F.P. Brooks, Jr.,. T h e M y t h i c a l Man-Month, ware Specification and Design, Pittsburgh, PA,
Addison-Wesley, Re~ding, MA, 1972. May 1989, appearing in A C M S I G S O F T Notes,
[6] R.H. Campbell and A.N. Habermann, The Specifica- Vol. 14, No. 3, May 1989, pp. 147-150.
tion of Process Synchronization by Path Expressions, [21] M. Shaw, Larger Scale Systems R e q u i r e Higher-
L e c t u r e Notes in C o m p u t e r Science, No. 16, Level Abstractions, Proc. Fifth Inter. Workshop on
Apr. 1974, pp. 89-102. Software Specification and Design, Pittsburgh, PA,
[7] E.J. Chikofsky (ed.), Software D e v e l o p m e n t - - May 1989, appearing in A C M S I G S O F T Notes,
Vol. 14, No. 3, May 1989, pp. 143-146.
C o m p u t e r - a i d e d Software Engineering, Technol-
ogy Series, IEEE Computer Society Press, 1988. [22] A.Z. Spector, Modu]ar Architectures for Distributed
and Database Systems, P r o e . E i g h t h A C M
[8] G. Estrin, R.S. Fenchel, R.R. Razouk, and M.K. Ver-
SIGACT-SIGMOD-SIGART Symp. on Princi-
non, SARA (System ARchitects Apprentice), I E E E ples of Database Systems, Philadelphia,PA, A C M
Trans. on Software Engineering, Vol. SE-12, No. 2, Press, Mar. 1989, pp. 217-224.
Feb. 1986, pp. 293-277.
[23] J.A. Zachman, A Framework for Information Sys-
[9] P. Freeman and A.I. Wasserma~, Tutorial on Soft- tems Architecture, I B M Systems J o u r n a l , Vol. 26,
ware Design Techniques, IEEE Computer Society No. 3, 1987.
Press, 1976.
[10] D. Ja~ckson, Composing Data and Process Descriptions
in the Design of Software Systems, LCS Tech. Re-
p o r t 419, Massachusetts Institute of Technology, Cam-
bridge, MA, May 1988.
[11] F.C. Mish, x~rebster~s N i n t h New Collegiate Die-
tlonary, Merfiam Webster, Springfield, MA, 1983.
[12] J.E.B. Moss ~md A.L. Wolf, Toward Principles of In-
heritance and Subtyping for Programming Languages,
C O I N S Tec]~. R e p o r t 88-95, COINS Dept., Univ.
of Mass., Amherst, MA, Nov. 1988.
[13] J.D. Musa, Software Reliability: M e a s u r e m e n t ,
P r e d i c t i o n , Application, McGraw-Hill, New York,
NY, 1990.