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

Foundations for the Study of Software Architecture

Alexander L. Wolf Dewayne E. Perry

Department of Computer Science AT&T Bell Lab oratories

University of Colorado 600 Mountain Avenue

Boulder, Colorado 80309 Murray Hill, New Jersey 07974

[email protected] [email protected]

c

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

ABSTRACT more toward integrating designs and the design pro cess

into the broader context of the software pro cess and

its management. One result of this integration was that

The purp ose of this pap er is to build the foundation

many of the notations and techniques develop ed for soft-

for software architecture. We rst develop an intuition

ware design have b een absorb ed by implementation lan-

for software architecture by app ealing to several well-

guages. Consider, for example, the concept of supp ort-

established architectural disciplines. On the basis of

ing \programmming-in-the-large". This integration has

this intuition, we present a mo del of software architec-

tended to blur, if not confuse, the distinction b etween

ture that consists of three comp onents: elements, form,

design and implementation.

and rationale. Elements are either pro cessing, data, or

The 1980s also saw great advances in our abilityto

connecting elements. Form is de ned in terms of the

describ e and analyze software systems. We refer here to prop erties of, and the relationships among, the elements

| 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

e ectively ab out software systems. For example, we are

from the system requirements. We discuss the comp o-

able to reason ab out \consistency" and \inconsistency"

nents of the mo del in the context of b oth architectures

more e ectively and we are able to talk ab out \typ e

and architectural styles and present an extended exam-

1

conformance" rather than just \typ e equivalence".

ple to illustrate some imp ortant architecture and style

The 1990s, we b elieve, will b e the decade of software

considerations. We conclude by presenting some of the

architecture.We use the term \architecture", in con-

b ene ts of our approach to software architecture, sum-

trast to \design", to evoke notions of co di cation, of

marizing our contributions, and relating our approach

to other currentwork.

abstraction, of standards, of formal training of soft-

ware architects, and of style. While there has b een

some work in de ning particular software architectures

1 Intro duction

e.g., [19,22], and even some work in developing gen-

eral supp ort for the pro cess of developing architectures

Software design received a great deal of attention by

notably Sara [8], it is time to reexamine the role of ar-

researchers in the 1970s. This research arose in resp onse

chitecture in the broader context of the software pro cess

to the unique problems of developing large-scale soft-

and software pro cess management, as well as to marshal

ware systems rst recognized in the 1960s [5]. The

the various new techniques that have b een develop ed.

premise of the researchwas that design is an activity

Some of the b ene ts we exp ect to gain from the emer-

separate from implementation, requiring sp ecial nota-

gence of software architecture as a ma jor discipline are:

tions, techniques, and to ols [3, 9, 17]. The results of

1 architecture as the framework for satisfying require-

this software design research has now b egun to make in-

ments; 2 architecture as the technical basis for design

roads into the marketplace as computer-aided software

engineering CASE to ols [7].

1

In the 1980s, the fo cus of software engineering re-

Conformance is used to describ e the relationship b etween

searchmoved away from software design sp eci cally and typ es and subtyp es.

ACM 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 e ective basis for

There are several di erent approaches to hardware

reuse; and 4 architecture as the basis for dep endency

architecture that are distinguished by the asp ect of the

and consistency analysis.

hardware that is emphasized. RISC machines are ex-

Thus, the primary ob ject of our research is supp ort

amples of a hardware architecture that emphasizes the

for the development and use of software architecture

instruction set as the imp ortant feature. Pipelined ma-

sp eci cations. This pap er 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 con gura-

b egin in Section 2 by developing an intuition ab out

tion of architectural pieces of the hardware.

software architecture against the background of well-

There are twointeresting features of the second ap-

established disciplines such as hardware, network, and

proach to hardware architecture that are imp ortantin

building architecture, establish the context of software

our consideration of software architecture:

architecture, and provide the motivation for our ap-

 there are a relatively small numb er of design ele-

proach. In Section 3, we prop ose a mo del for, and a

ments; and

characterization of, software architecture and software

architectural styles. Next, in Section 4, we discuss an

 scale is achieved by replication of these design ele-

easily understo o d example to elicit some imp ortant as-

ments.

p ects 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 elab orate on two of the ma jor b ene ts of our ap-

an exceedingly large numb er of p ossible design elements.

proach to software architecture. We conclude, in Sec-

Further, scale is achieved not by replicating design el-

tion 6, by summarizing the ma jor p oints made in this

ements, but by adding more distinct design elements.

pap er and considering related work.

However, there are some similarities: we often organize

and con gure software architectures in ways analogous

to the hardware architectures mentioned ab ove. For ex-

2 Intuition, Context, and Motivation

ample, we create multi-pro cess software systems and use

pip elined pro cessing.

Before presenting our mo del of software architecture,

Thus, the imp ortant insight from this discussion is

welay the philosophical foundations for it by: 1 devel-

that there are fundamental and imp ortant di erences

oping an intuition ab out software architecture through

between the two kinds of architecture. Because of these

analogies to existing disciplines; 2 prop osing a con-

di erences, it is somewhat ironic that we often present

text for software architecture in a multi-level pro duct

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 ab out Soft- design elements of a network into no des and connec-

tions, and by naming the kinds of relationships that

ware Architecture

these two elements havetoeach 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. Wehave some intuition that

works as examples of named network architectures.

there are di erent kinds of software architectures, but

The twointeresting architectural p oints ab out net-

wehave not formalized, or institutionalized, them. It is

work architecture are:

our claim that it is b ecause there are so many software

 there are two comp onents | no des and connec-

architectures, not b ecause there are so few, that the

tions; and

present state of a airs exists. In this section welookat

several architectural disciplines in order to develop our

 there are only a few top ologies that are considered.

intuition ab out software architecture. We lo ok at hard-

ware and network architecture b ecause they have tra- It is certainly the case that we can abstract to a similar

ditionally b een considered sources of ideas for software level in software architecture | for example, pro cesses

architecture; we lo ok at building architecture b ecause it and intepro cess communication. However, rather than

is the \classical" architectural discipline. a few top ologies to consider, there are an exceedingly

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

large numb er of p ossible top ologies and those top olo- view. Descriptively, architectural style de nes a partic-

gies generally go without names. Moreover, we empha- ular co di cation of design elements and formal arrange-

size asp ects di erent from the top ology of the no des and ments. Prescriptively,style limits the kinds of design

connections. We consider instead such matters as the elements and their formal arrangements. That is, an

placement of pro cesses e.g., distributed architectures architectural style constrains b oth the design elements

or the kinds of interpro cess communication e.g., mes- and the formal relationships among the design elements.

sage passing architectures. Analogously,we shall nd this a most useful concept in

software architecture.

Thus, we do not b ene t much from using networks

Of extreme imp ortance is the relationship b etween

as an analogy for software architecture, even though we

engineering principles and architectural style and, of

can lo ok at architectural elements from a similar level

course, architecture itself . For example, one do es not

of abstraction.

get the light, airy feel of the p erp endicular style as ex-

empli ed in the chap el at King's College, Cambridge,

2.1.3 Building Architecture

from romanesque engineering. Di erent engineering

The classical eld 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 p erp endicular. It is

While the sub ject matter for the two is quite di erent,

not just a matter of aesthetics. This relationship b e-

there are a number of interesting architectural p oints

tween engineering principles and software architecture

in building architecture that are suggestive for software

is also of fundamental imp ortance.

architecture:

Finally, the relationship b etween architectural style

and materials is of critical imp ortance. The materi-

 multiple views;

als have certain prop erties that are exploited in pro-

viding a particular style. One may combine structural

 architectural styles;

with aesthetic uses of materials, such as that found in

the p ost and b eam construction of tudor-style houses.

 style and engineering; and

However, one do es not build a skyscrap er with wo o den

 style and materials.

p osts and b eams. The material asp ects of the design

elements provide b oth aesthetic and engineering bases

A building architect works with the customer by

for an architecture. Again, this relationship is of critical

means of a numb er of di erent views in which some

imp ortance in software architecture.

particular asp ect of the building is emphasized. For

Thus, we nd in building architecture some funda-

example, there are elevations and o or plans that give

mental insights ab out software architecture: multiple

the exterior views and \top-down" views, resp ectively.

views are needed to emphasize and to understand dif-

The elevation views may b e supplemented by contextual

ferent asp ects of the architecture; styles are a cogent

drawings or even scale mo dels to provide the customer

and imp ortant form of co di cation that can b e used

with the lo ok of the building in its context. For the

b oth descriptively and prescriptively; and, engineering

builder, the architect provides the same o or plans plus

principles and material prop erties are of fundamental

additional structural views that provide an immense

imp ortance in the development and supp ort of a partic-

amount of detail ab out 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

di erent views of the software architecture for the var-

Before discussing our motivation for software archi-

ious uses and users. At presentwe make do with only

tecture sp eci cations, we p osit a characterization of ar-

one view: the implementation. In a real sense, the im-

chitecture in the context of the entire software pro duct.

plementation is like a builders detailed view | that is,

Note that we do not mean to imply anything ab out the

like a building with no skin in which all the details are

particular pro cess by which this pro duct is created |

visible. It is very dicult to abstract the design and ar-

though of course there may b e implications ab out the

chitecture of the system from all the details. Consider

pro cess that are inherent in our view. Our purp ose 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 b e considered a fairly standard software pro duct.

ful from b oth descriptive and prescriptive p oints of Wecharacterize the di erent parts of the software

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

pro duct by the kinds of things that are imp ortant for to software architecture are evolution and customiza-

that part | the kinds of entities, their prop erties and tion. Systems evolve and are adapted to new uses, just

relationships that are imp ortant 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 prop ertyofevolu-

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, pro cessing, and the character-

tural problems: architectural erosion and architectural

istics of that information and pro cessing needed by

drift. Architectural erosion is due to violations of the ar-

2

the user of the system;

chitecture. These violations often lead to an increase in

problems in the system and contribute to the increasing

 architecture is concerned with the selection of archi-

brittleness of a system | for example, removing load-

tectural elements, their interactions, and the con-

b earing walls often leads to disastrous results. Architec-

straints on those elements and their interactions

tural drift is due to insensitivity ab out the architecture.

necessary to provide a framework in which to sat-

This insensitivity leads more to inadaptability than to

isfy the requirements and serve as a basis for the

disasters and results in a lack of coherence and clarity

design;

of form, which in turn makes it much easier to violate

 design is concerned with the mo dularization and

the architecture that has now b ecome more obscured.

detailed interfaces of the design elements, their

Customization is an imp ortant factor in software ar-

algorithms and pro cedures, and the data typ es

chitecture, not b ecause of problems that it causes, but

needed to supp ort the architecture and to satisfy

b ecause of the lackofarchitectural 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. Wehave not yet arrived at the stage

tions of the algorithms and data typ es that satisfy

where wehave a standard set of architectural styles

the design, architecture, and requirements.

with their accompanying design elements and formal

arrangements. Each system is, in essence, a new ar-

The di erent parts of a particular pro duct are byno

chitecture, a new architectural style. The presense of

means as simple as this characterization. There is a

ubiquitous customization indicates that there is a gen-

continuum of p ossible choices of mo dels, abstractions,

eral need for co di cation | that is, there is a need for

transformations, and representations. We simplify this

architectural templates for various architectural styles.

continuum into four discrete parts primarily to provide

For the standard parts of a system in a particular style,

an intuition ab out how architecture is related to the

the architect can select from a set of well-known and

requirements and design of a software system.

understo o d elements and use them in ways appropriate

It should b e noted that there are some development

to the desired architecture. This use of standard tem-

paradigms to which our characterization will not apply

plates for architectural elements then frees the architect

| for example, the exploratory programming paradigm

to concentrate on those elements where customization

often found in AI research. However, our characteriza-

is crucial.

tion represents a wide varietyofdevelopment and evo-

Given our characterization of architecture and moti-

lutionary paradigms used in the creation of pro duction

vating problems, there are a numb er of things that we

software, and delineates an imp ortant, and hitherto un-

want to b e able to do with an architectural sp eci cation:

derconsidered, part of a uni ed software pro duct [15].

 Prescribe the architectural constraints to the desired

2.3 Motivation for Architectural Sp eci-

level | that is, indicate the desired restrictiveness

cations

or p ermissiveness, determine the desired level of

generality or particularity, de ne what is necessity

There are a numb er of factors that contribute to the

and what is luxury, and pin-p oint the degree of rel-

high cost of software. Two factors that are imp ortant

ativeness and absoluteness. Wewant a means of

supp orting a \principle of least constraint" to b e

2

Note that the notion of requirements presented here is an ide-

able to to express only those constraints in the ar-

alistic one. In practice, requirements are not so \pure"; they often

chitecture that are necessary at the architectural

contain constraints on the architecture of a system, constraints on

the system design, and even constraints on the implementation. level of the system description. This is an imp or-

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

tant departure from current practice that, instead  pro cessing elements;

of sp ecifying the constraints, supplies sp eci c solu-

 data elements; and

tions that emb o dy those desired constraints.

 connecting elements.

 Separate aesthetics from engineering | that is, in-

The pro cessing elements are those comp onents that sup-

dicate what is \load-b earing" from what is \dec-

ply the transformation on the data elements; the data

oration". This separation enables us to avoid the

elements are those that contain the information that is

kinds of changes that result in architectural erosion.

used and transformed; the connecting elements which

 Express di erent aspects of the architectureinan

at times may b e either pro cessing or data elements,

appropriate manner | that is, describ e di erent

or b oth are the glue that holds the di erent pieces

parts of the architecture in an appropriate view.

of the architecture together. For example, pro cedure

calls, shared data, and messages are di erent examples

 Perform dependency and consistency analysis |

of connecting elements that serve to \glue" architectural

that is, determine the interdep endencies b etween

elements together.

architecture, requirements and design; determine

Consider the example of water p olo as a metaphor for

interdep endencies b etween various parts of the ar-

the di erent classes of elements: the swimmers are the

chitecture; and determine the consistency,orlack

pro cessing elements, the ball is the data element, and

of it, b etween architectural styles, b etween styles

water is the primary connecting element the \glue".

and architecture, and b etween architectural ele-

Consider further the similarities of water p olo, p olo, and

ments.

so ccer. They all have a similar \architecture" but dif-

fer in the \glue" | that is, they have similar elements,

3 Mo del of Software Architecture

shap es and forms, but di er mainly in the context in

which they are played and in the way that the elements

In Section 2 we use the eld of building architecture

are connected together. We shall see b elow that these

to provide a numb er of insights into what software ar-

connecting elements play a fundamental part in distin-

chitecture might b e. The concept of building architec-

guishing one architecture from another and mayhave

ture that we app eal to is that of the standard de nition:

an imp ortant e ect on the characteristics of a particu-

\The art or science of building: especial ly designing and

lar architecture or architectural style.

building habital structures" [11]. Perhaps more relevant

The architectural form consists of weighted prop er-

to our needs here is a secondary de nition: \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 imp ortance of the prop ertyorthe

architecture | providing a unifying or coherent form

relationship, or the necessity of selecting among alterna-

or structure | that infuses our mo del of software archi-

tives, some of whichmay b e preferred over others. The

tecture.

use of weighting to indicate imp ortance enables the ar-

We rst present our mo del of software architecture,

chitect to distinguish b etween \load-b earing" and \dec-

intro duce the notion of software architectural style, and

orative" formal asp ects; the use of weighting to indicate

discuss the interdep endence of pro cessing, 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 Mo del

Properties are used to constrain the choice of archi-

tectural elements | that is, the prop erties are used to

By analogy to building architecture, we prop ose the

de ne constraints on the elements to the degree desired

following mo del of software architecture:

by the architect. Prop erties de ne the minimum de-

sired constraints unless otherwise stated | that is, the

Software Architecture =

default on constraints de ned by prop erties is: \what

f Elements, Form, Rationale g

is not constrained by the architect may takeany form

That 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 di erent classes of architectural the di erent elements mayinteract and how they are

elements : organized with resp ect to each other in the architecture.

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

As with prop erties, relationships de ne the minimum 3.3 Pro cess/Data/Connector

desired constraints unless otherwise stated.

Interdep endence

An underlying, but integral, part of an architecture is

As mentioned ab ove, an imp ortant insight from build-

the rationale for the various choices made in de ning an

ing architecture is that of multiple views. Three im-

architecture. The rationale captures the motivation for

p ortant views in software architecture are those of pro-

the choice of architectural style, the choice of elements,

cessing, data, and connections. We observe that if a

and the form. In building architecture, the rationale

3

pro cess view of an architecture is provided, the result-

explicates the underlying philosophical aesthetics that

ing emphasis is on the data ow though the pro cessing

motivate the architect. In software architecture, the

elements and on some asp ects of the connections b e-

rationale instead explicates the satisfaction of the sys-

tween the pro cessing elements with resp ect to the data

tem constraints. These constraints are determined by

elements. Conversely, if a data view of an architecture

considerations ranging from basic functional asp ects to

is provided, the resulting emphasis is on the pro cess-

various non-functional asp ects such as economics [4],

ing ow, but with less an emphasis on the connecting

p erformance [2] and reliability [13].

elements than wehave in the pro cess view. While the

current common wisdom seems to put the emphasis on

3.2 Architectural Style

ob ject-oriented that is, data-oriented approaches, we

If architecture is a formal arrangementofarchitec-

b elieve that all three views are necessary and useful at

tural elements, then architectural style is that which

the architectural level.

abstracts elements and formal asp ects from various sp e-

We argue informally, in the following way, that there

ci c architectures. An architectural style is less con-

is a pro cess and data interdep endence:

strained and less complete than a sp eci c architecture.

For example, we might talk ab out a distributed style or

 there are some prop erties that distinguish one state

a multi-process style . In these cases, we concentrate on

of the data from another; and

only certain asp ects of a sp eci c architecture: relation-

ships b etween pro cessing elements and hardware pro-

 those prop erties are the result of some transforma-

cessors, and constraints on the elements, resp ectively.

tion pro duced by some pro cessing element.

Given this de nition of architecture and architectural

style, there is no hard dividing line b etween where ar-

These two views are thus intertwined | each dep endent

chitectural style leaves o and architecture b egins. We

on the other for at least some of the imp ortantcharac-

have a continuum in which one p erson's architecture

teristics of b oth data and pro cessing. For a more gen-

may b e another's architectural style. Whether it is an

eral discussion of pro cess and data interdep endence, see

architecture or a style dep ends in some sense on the

[10].

use. For example, we prop ose in Section 2.3 that archi-

tectural styles b e used as constraints on an architecture.

The interdep endence of pro cessing and data up on the

Given that wewant the architectural sp eci cation to b e

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 happ en that one p erson's architecture

cessor to pro cessor. Because of this activity up on the

mightwell b e less constrained than another's architec-

data, the connecting elements will necessarily have some

tural style.

of the prop erties required by the data elements in pre-

The imp ortant thing ab out an architectural style

cisely the same way that pro cessing elements have some

is that it encapsulates imp ortant decisions ab out the

of the prop erties required by the data elements.

architectural elements and emphasizes imp ortant con-

At the architectural level, we need all three views

straints on the elements and their relationships. The

and the abilitytomove freely and easily among them.

useful thing ab out style is that we can use it b oth to

Our example in the next section provides illustrations

constrain the architecture and to co ordinate co op erat-

of this interdep endence and howwe might provide three

ing architects. Moreover, style emb o dies those decisions

di erent, but overlapping, views.

that su er erosion and drift. An emphasis on style as

a constraint on the architecture provides a visibilityto

3

We use the dichotomyof process and data instead of function

certain asp ects of the architecture so that violations of

and object b ecause these terms seem to b e more neutral. The

those asp ects and insensitivity to them will b e more

latter terms seem to suggest something more sp eci c in terms of

programming than the former. obvious.

ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 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 ob ject co de.

achieved widespread acceptance is that of the multi-

Notice that wehave not sp eci ed connecting elements.

phase compiler. It is practically the only style in

It is simply the case that this style do es not dictate

whichevery software engineer is exp ected to have b een

what connecting elements are to b e used. Of course, the

trained. We rely on this familiarity to illustrate some

choice of connecting elements has a profound impact on

of the insights that wehave gained into software archi-

the resulting architecture, as shown b elow.

tectures and their descriptions.

The form of the architectural style is expressed by

In this section welookattwo compiler architectures

weighted prop erties and relationships among the archi-

of the multi-phase style:

tectural elements. For example, the optimizer and an-

 a compiler that is organized sequentially; and

notated phrases must b e found together, but they are

b oth only preferred elements, not necessary. As an-

 a compiler that is organized as a set of parallel pro-

other example, there are linear relationships b etween

cesses connected by means of a shared internal rep-

the characters constituting the text of the program, the

resentation.

tokens pro duced by the lexer, and the phrases pro duced

Because of space limitations and for presentation pur-

by the parser. In particular, tokens consist of a sequence

p oses, our examples are somewhat simpli ed 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 b ecause they are convenient for illustrative

between phrases and correlated phrases. These relation-

purp oses; prop osals for sp eci c architectural notations

ships are depicted in Figure 1. As a nal example, each

are b eyond the scop e of this pap er. In each case we fo cus

of the pro cessing elements has a set of prop erties that

on the architectural considerations that seem to b e the

de nes 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 pro duces as output a sequence of

chitectures exist and we make no claims of exhaustive

tokens. Moreover, there is an ordering corresp ondence

coverage of this architectural landscap e. Before explor-

between the tokens and the characters that must b e

ing these examples, we provide a brief review of their

preserved by the lexer. A go o d architectural descrip-

common architectural style.

tion would capture these and other such prop erties and

relationships.

4.1 The Multi-phase Architectural

Let us illustrate this by formally describing the rela-

Style

tionship b etween characters and tokens and describing

the order-preserving prop erty of the lexer. We b egin

Our simpli ed mo del of a compiler distinguishes ve

the description with a data view stated in terms of se-

phases: lexical analysis, syntactic analysis, semantic

quences and disjoint subsequences.

analysis, optimization, and co de generation. Lexical

analysis acts on characters in a source text to pro duce

Let C = fc ;c ;...;c g b e a sequence of char-

1 2 m

i

tokens for syntactic analysis. Syntactic analysis pro-

acters representing a source text, C i  j be a

j

duces phrases that are either de nition phrases or use

subsequence of C whose elements are all the el-

phrases. Semantic analysis correlates use phrases with

ements in C between c and c inclusive, T =

i j



ft ;t ;...;t g b e a sequence of tokens, and \ "

de nition phrases | i.e., each use of a program element =

1 2 n

indicate the corresp ondence b etween a token in T

such as an identi er is asso ciated with the de nition for

and a subsequence of C . T is said to preserve C

that element, resulting in correlated phrases. Optimiza-

if there exists an i, j , k , q , r , and s such that

tion pro duces annotations on correlated phrases that

1  i

are hints used during generation of object code. The

x

for all t 2 T there exists a C such that:

y

optimization phase is considered a preferred, but not

8

1

necessary, asp ect of this style. Thus, the multi-phase

if t = t C

1

>

i

>

j

>

style recognizes the following architectural elements:

>

if t = t C

n

m

>

<

1  u  q 1



t

=

processing elements: lexer, parser, semantor, op-

r +1  v  m

>

q

>

C if t = t , where 9 u, v

k

u r

>



>

t C

=

k1

timizer, and co de generator;

q1

>

:

r +1



t C

=

k+1

v and

CM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 47 A Characters Tokens Phrases

Correlated Phrases

Figure 1: Data Element Relationships.

The lexer is now constrained from a pro cessing p ersp ec-

e to accept a sequence of characters C , pro duce a tiv Characters Lexer

sequence of tokens T , and to preserve the ordering cor-

Tokens

ween characters and tokens:

resp ondence b et (NT)

C ! T , where T preserves C

lexer: Parser

Finally,itisinteresting to note that the connec-

tor view reveals additional constraints that should b e

Object Code Phrases

hitectural style. These constraints are

placed on the arc (NT+AST)

illustrated by the connection b etween the lexer and the

parser. In particular, connecting elements must ensure

that the tokens pro duced by the lexer are preserved for Code Correlated Phrases

Semantor

h that the order remains intact and that

the parser, suc Generator (NT+ASG) there are no losses, duplicates, or spurious additions. Annotated Cor. Phrases Correlated Phrases

(NT+AASG) (NT+ASG)

4.2 Sequential Architecture

Optimizer

If there is a \classical" multi-phase compiler archi-

tecture, then it is the sequential one, in which each

phase p erforms its function to completion b efore the

Figure 2: Pro cessing View of Se-

next phase b egins and in which data elements are passed

quential Compiler Ar-

directly from one pro cessing element to the other. Thus,

chitecture.

we add the following architectural elements to those

characterizing the overall style:

created and transformed as they ow through the sys-

connecting elements: pro cedure call and parame-

tem. Wehave found that the data view is b est captured

ters.

by a notion that we call application-orientedproperties.

Application-oriented prop erties describ e the states of a

Furthermore, we re ne tokens to include the structur-

data structure that are of signi cance to the pro cess-

ing of the identi er tokens into a name table NT, and

ing elements manipulating that structure. They can b e

re ne phrases to b e organized into an abstract syntax

used for such things as controlling the order of pro cess-

tree AST. Correlation of phrases results in an abstract

ing, helping to de ne the e ects of a pro cessing element

syntax graph ASG and optimization in an annotated

on a data structure, and even helping to de ne the op-

abstract syntax graph AASG. Figure 2 gives a pro cess-

erations needed by the pro cessing elements to achieve

ing view of the sequential architecture, showing the ow

those e ects.

of data through the system. Notice that there are two

For this example, the simpli ed application-

paths from the semantor to the co de generator, only one

oriented prop erties are as follows:

of which passes through the optimizer. This re ects the

fact that a separate optimization phase is not necessary

has-al l-tokens: a state pro duced as a result of lex- in this architecture. That is, a design satisfying this

ically analyzing the program text, architecture need not provide an optimizer.

necessary for the parser to b egin To illustrate the interdep endence of pro cessing and

pro cessing; data views, let us consider the data as a whole b eing

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

ases: a state pro duced by the parser,

has-al l-phr Lexer tor to b e- necessary for the seman has- all-

gin pro cessing; tokens-

has-al l-correlated-phrases: a state pro duced by the tor, necessary for the opti-

seman Parser

mizer and co de generator to b egin pro cessing; and has-

all- a state pro duced

has-al l-optimization-annotations: phrases

by the optimizer, preferred for the co de generator to b egin pro cess-

Semantor ing. Code Code

Generator Generator y is only preferred. Notice again that the last prop ert has- has-

all- all- ted prop er- While in this example the application-orien optimiz.- Optimizer correlated-

annota. phrases

ties may app ear obvious and almost trivial, in the next

example they are crucial to the description of the archi-

Figure 3: Data View of Sequential

tecture and in guaranteeing the compliance of designs

Compiler Architecture.

and implementations with that architecture.

An interesting question to consider is whywe evi-

dently chose to use a prop erty-based scheme for de-

view concentrates on the particular application-oriented

scribing architectural elements rather than a typ e-based

prop erties that are of imp ortance in describing each

scheme. The reason is that typ e mo dels, as they cur-

data structure, while the pro cessing view concentrates

rently exist, are essentially only able to characterize el-

on the functional prop erties of each pro cessing element.

ements and elementtyp es in terms of the relationship

These views are actually complementary. In fact, if we

of one elementtyp e 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 pro cessing view, shown in Figure 2, then

ticular elements have with other elements e.g., as in

the corresp ondence b ecomes fairly obvious.

Oros [18], and in terms of the op erations that can

The imp ortant architectural considerations that de-

b e p erformed on the elements. They are not suited to

rive from this example can b e summarized as follows:

descriptions of characteristics of elements such as the

application-oriented prop erties mentioned ab ove. For

 the form descriptions must include the relation-

example, simply knowing that there is an op eration as-

ships and constraints among the elements, includ-

so ciated with abstract syntax graphs to connect one

ing relativeweightings and preferences;

phrase to another do es not lead to an understanding

 currenttyp e-based schemes for characterizing ele-

that the abstract syntax graph must have all phrases

ments are insucient; and

correlated b efore the co de generator can access the

graph.

 there is a natural interdep endence b etween the pro-

Prop erty-based schemes, on the other hand, can b e

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 b e the set of op erations with

which it is asso ciated. It seems reasonable to consider

4.3 Parallel Pro cess, Shared Data

enhancing typ e mo dels in this regard and we see this

Structure Architecture

as a p otentially interesting area of future work. We

Supp ose that p erformance is of paramount imp or- note, however, that typ e-based schemes are already ap-

tance, such that one wants to optimize the sp eed of propriately used at the design level, as mentioned in

the compiler as much as p ossible. One p ossible solution Section 2. Further, we note that application-oriented

is to adopt an architecture that treats the pro cessing prop erties provide a go o d vehicle with which to drive

elements as indep endent pro cesses driven by a shared the design, or justify the suitability, of a set of op era-

internal representation | that is, the connecting ele- tions for an elementtyp e.

ment is the shared representation and each pro cessing Returning to the interdep endence b etween the pro-

element p erforms eager evaluation. Figure 4 depicts a cessing and data views, we can see that the data

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

sic prop erties must b e explicitly describ ed. Anum-

Characters Lexer b er of notations exist that are suitable for making

such descriptions, including paral lel path expressions

[6], constrained expressions [1], and petri nets [16]. In

this example we use parallel path expressions, where Tokens Tokens

Parser a comma indicates sequence, a plus sign indicates one

or more rep etitions, an asterisk indicates zero or more

rep etitions, and sub expressions are enclosed in paren-

Synchronization p oints o ccur where names of Phrases theses.

Internal ted prop erties are the same in di er- Representation application-orien

Phrases

ent parallel path expressions. First, the path expres-

sions for each of the data elements | tokens, phrases,

and correlated phrases | are given: Semantor

Correlated Phrases

+

1 no-tokens, has-token *,

will-b e-no-more-tokens, has-token*, no-tokens

+

Figure 4: Partial Pro cess View of

2 no-phrases, has-phrase *,

will-b e-no-more-phrases, has-phrase*, no-phrases

Parallel Pro cess, Shared

3 no-correlated-phrases, have-correlated-phrases*,

Data Structure Com-

all-phrases-correlated

piler Architecture.

Next, the path expressions relating the application-

simpli ed and partial pro cess view of this architecture,

oriented prop erties are given:

showing the relationships b etween the internal repre-

sentation and the lexer, the parser, and the semantor.

4 will-b e-no-more-tokens, will-b e-no-more-phrases,

all-phrases-correlated

We only consider these three pro cessing elements in the

+

5 has-token , has-phrase

remainder of this example.

+

6 has-phrase , has-correlated-phrase

The application-oriented prop erties of the shared in-

ternal representation in this architecture are much more

Thus, tokens are consumed to pro duce phrases, and

complicated, and interesting, than those given in the

phrases are correlated until they are all pro cessed.

previous example. In particular, a numb er of pro cess-

What wehave given so far is essentially a connector

ing elements are a ecting the state of the internal repre-

view and, in this case, e ectively a data view as well.

sentation, and doing so concurrently. This implies that

Concentrating instead on the pro cessing view allows us

the application-oriented prop erties must provide for co-

to describ e how each pro cessing element transforms the

ordination and synchronization among the pro cessing

internal representation as well as how those pro cessing

elements. We b egin by giving the basic prop erties that

elements are synchronized:

the internal representation may exhibit:

+

lexer: no-tokens, has-token *,

no-tokens

wil l-be-no-more-tokens

has-token

wil l-be-no-more-tokens

+

parser: no-phrases, has-token , has-phrase*,

no-phrases

+

wil l-be-no-more-tokens, has-token ,

has-phrase

has-phrase*, no-tokens,

wil l-be-no-more-phrases

wil l-be-no-more-phrases

no-correlated-phrases

have-correlated-phrases

+

semantor: no-correlated-phrases, has-phrase ,

al l-phrases-correlated

has-correlated-phrase*,

+

Notice that these prop erties imply that tokens and

wil l-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-

al l-phrases-correlated

correlated-phrases".

Because of the parallel b ehavior of the pro cessing 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 abilityto

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

5.1 Software Architecture and Analysis relate similar architectures is an imp ortant asp ect of the

software pro cess; an example is the evaluation of \com-

Aside from providing clear and precise do cumenta-

p eting" architectures. Certainly, the architectures b oth

tion, the primary purp ose of sp eci cations is to provide

b eing of a common style captures some p ortion of the

automated analysis of the do cuments and to exp ose var-

relationship. More can b e said, however, given the use

ious kinds of problems that would otherwise go unde-

of application-oriented prop erties. In particular, we can

tected. There are two primary categories of analysis

draw correlations among the prop erties of the di erent

that we wish to p erform: consistency and dep endency

architectures. The table b elow shows some of these cor-

analysis. Consistency o ccurs in several dimensions: con-

relations.

sistency within the architecture and architectural styles,

consistency of the architecture with the requirements,

Parallel Architecture Sequential Architecture

and consistency of the design with the architecture. In

has-al l-tokens wil l-be-no-more-tokens

the same way that Inscap e [14] formally and automat-

has-al l-phrases wil l-be-no-more-pharses

ically manages the interdep endencies b etween interface

has-al l-correlated-phrases al l-phrases-correlated

sp eci cations and implementations, we also wanttobe

able to manage the interdep endencies b etween require-

In this case, the correlations indicate common p oints

ments, architecture, and design.

of pro cessing, leading, for instance, to a b etter under-

standing of the p ossible reusability of the pro cessing Therefore, wewanttoprovide and supp ort at least

elements. the following kinds of analysis:

The imp ortant p oints of this example can b e summa-

 consistency of architectural style constraints;

rized as follows:

 satisfaction of architectural styles byanarchitec-

 the pro cessing elements are much the same as in

ture;

the previous architecture, but with di erent \lo cus

of control" prop erties;

 consistency of architectural constraints;

 satisfaction of the architecture by the design;

 the form of this architecture is more complex

than that of the previous one | there are more

 establishment of dep endencies b etween architec-

application-oriented prop erties and those prop er-

ture and design, and architecture and require-

ties require a richer notation to express them and

ments; and

their interrelationships;

 determination of the implications of changes in ar-

 we still b ene t from the pro cessing/data/connector

chitecture or architectural style on design and re-

view interdep endence, alb eit with more complexity;

quirements, and vice versa.

and

5.2 Architecture and the Problems of

 application-oriented prop erties are useful in relat-

Use and Reuse

ing similar architectures.

An imp ortant asp ect in improving the pro ductivity

of the designers and the programmers is that of b eing

5 Some Bene ts Derived from Software

able to build on the e orts of others | that is, using

Architecture

and reusing comp onents whether they come as part of

another system or as parts from standard comp onents

Wehave previously mentioned the use of software ar-

catalogs.

chitecture in the context of requirements and design.

Software architecture provides the framework within There has b een much attention given to the problem

which to satisfy the system requirements and provides of nding comp onents to reuse. Finding comp onents

b oth the technical and managerial basis for the design may b e imp ortant in reducing the duplication of e ort

and implementation of the system. There are two fur- and co de within a system, but it is not the primary

ther b ene ts that we wish to discuss in detail: the kinds issue in attaining e ective use of standardized comp o-

of analysis that software architecture sp eci cations will nents. For example, nding the comp onents in a math

enable us to p erform 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 emb o died in the library. If they

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

are understo o d, then there is usually no problem nd- the necessary features of architectural description tech-

ing the appropriate comp onent in the library to use. If niques and their supp orting infrastructure. In so doing,

they are not understo o d, then browsing will help only wehave 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 b egun to lo ok at software architecture.

The primary fo cus in architecture is the identi cation

Three that are most relevant are Schwanke, et al., Zach-

of imp ortant prop erties and relationships | constraints

man, and Shaw.

on the kinds of comp onents that are necessary for the

Schwanke, et al., [20] de ne architecture as the p er-

architecture, design, and implementation of a system.

mitted or allowed set of connections among comp onents.

Given this as the basis for use and reuse, the architect,

We agree that that asp ect of architecture is imp ortant,

designer, or implementer may b e able to select the ap-

but feel that there is much more to architecture than

propriate architectural element, design element, or im-

simply comp onents and connections, as we demonstrate

plemented co de to satisfy the sp eci ed constraints at

in this pap er.

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 b e teased apart to select that

information systems. He exploits the notion of di er-

which is useful from that which is not. For example,

ent architectural do cuments to provide a vision of what

the design of a comp onent from another system may

the various do cuments ought to b e 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 con icts with other sys-

various do cuments provide the various views of di erent

tem constraints. The solution is to use the design but

parts of the pro duct | the users view, the contractors

not the implementation. This b ecomes p ossible only by

views, etc. His work di ers from ours in that he is

indentifying the architectural, design, and implemen-

prop osing a sp eci c architecture for a sp eci c applica-

tation constraints and use them to satisfy the desired

tion domain while we are attempting to de ne the philo-

goals of the architecture, design, and implementation.

sophical underpinnings of the discipline, to determine a

The imp ortant lesson in reusing comp onents is that

notation for expressing the sp eci cation of the various

the p ossibilities for reuse are the greatest where sp eci -

architectural do cuments, and determine how these do c-

cations for the comp onents are constrained the least |

uments can b e used in automated ways.

at the architectural level. Comp onent reuse at the im-

Shaw [21] comes the closest in approach to ours. She

plementation level is usually to o late b ecause the imple-

takes the view of a programming language designer and

mentation elements often embody too many constraints.

abstracts classes of comp onents, metho ds of comp osi-

Moreover, consideration of reuse at the architectural

tion, and schemas from a wide variety of systems. These

level may lead developmentdown a di erent, equally

corresp ond somewhat to our notions of pro cessing and

valid solution path, but one that results in greater reuse.

data elements, connecting elements, and architectural

style, resp ectively. One ma jor di erence b etween our

work and Shaw's is that she is taking a traditional typ e-

6 Conclusions

based approach to describing architecture, while we

Our e orts over the past few years have b een directed are taking a more expressive prop erty-based approach.

toward improving the software pro cess asso ciated with Our approach app ears b etter able to more directly cap-

large, complex software systems. Wehave come to b e- ture notions of weighted prop erties and relationships.

lieve that software architecture can play a vital role in Shaw's approach of abstracting the various prop erties

this pro cess, but that it has b een b oth underutilized and and relationships of existing architectures and emb o dy-

underdevelop ed. Wehave b egun to address this sit- ing them in a small set of comp onent and comp osition

uation by establishing an intuition ab out and context typ es app ears rather restrictive. Indeed, she is seeking

for software architecture and architectural style. We to provide a xed set of useful architectural elements

have formulated a mo del of software architecture that that one can mix and match to create an architecture.

emphasizes the architectural elements of data, pro cess- Shaw's approach is clearly an imp ortant and useful one

ing, and connection, highlights their relationships and and do es much to promote the understanding of basic

prop erties, and captures constraints on their realization and imp ortant architectural concepts. Our approach,

or satisfaction. Moreover, wehave b egun to delineate on the other hand, emphasizes the imp ortance of the

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

underlying prop erties and relationships as a more gen- [14] D.E. Perry, The Inscap e

Environment, Pro c. Eleventh Inter. Conf. on Soft-

eral mechanism that can b e used to describ e the partic-

ware Engineering, Pittsburgh, PA, IEEE Computer

ular typ es of elements and comp ositions in suchaway

So ciety Press, May 1989, pp. 2{12.

that provides a latitude of choice.

[15] D.E. Perry, Industrial Strength Software Development

In conclusion, we o er the following conjecture: p er-

Environments, Pro c. IFIP Congress '89, The 11th

haps the reason for such slow progress in the develop-

World Computer Congress, San Francisco, CA,

ment and evolution of software systems is that we have

Aug. 1989.

trainedcarpenters and contractors, but no architects.

[16] J.L. Peterson, Petri Nets, ACM Computing Sur-

veys, Vol. 9, No. 3, Sept. 1977, pp. 223-252.

[17] W.E. Riddle and J.C. Wileden, Tutorial on Software REFERENCES

System Design: Description and Analysis, Com-

[1] G.S. Avrunin, L.K. Dillon., J.C. Wileden, and

puter So ciety Press, 1980.

W.E. Riddle, Constrained Expressions: Adding Anal-

[18] W.R. Rosenblatt, J.C. Wileden, and A.L. Wolf, OROS:

ysis Capabilities to Design Metho ds for Concurrent

Towards a Typ e Mo del for Software Development

Systems, IEEE Trans. on Software Engineering,

Environments, Pro c. OOPSLA '89, New Orleans,

Vol. SE-12, No. 2, Feb. 1986, pp. 278{292.

Louisiana, Octob er 1989.

[2] J.L. Bentley, Writing Ecient Programs, Addison-

[19] E. Sandewall, C. Stromb erg, and H. Sorensen, Software

Wesley, Reading, MA, 1982.

Architecture Based on Communicating Residential En-

vironments, Pro c. Fifth Inter. Conf. on Software

[3] G.D. Bergland, A Guided Tour of Program Design

Engineering, San Diego, CA, IEEE Computer So ciety

Metho dologi es, IEEE Computer, Vol. 14, No. 10,

Press, Mar. 1981, pp. 144{152.

Oct. 1981, pp. 13{37.

[20] R.W. Schwanke, R.Z. Altucher, and M.A. Plato , Dis-

[4] B.W. Bo ehm, Software Engineering Economics,

covering, Visualizi ng and Controlling Software Struc-

Prentice-Hall, Englewo o d Cli s, NJ, 1981.

ture, Pro c. Fifth Inter. Workshop on Soft-

[5] F.P. Bro oks, Jr., The Mythical Man-Month,

ware Sp eci cation and Design, Pittsburgh, PA,

Addison-Wesley, Reading, MA, 1972.

May 1989, app earing in ACM SIGSOFT Notes,

Vol. 14, No. 3, May 1989, pp. 147{150.

[6] R.H. Campb ell and A.N. Hab ermann, The Sp eci ca-

tion of Pro cess Synchronization byPath Expressions,

[21] M. Shaw, Larger Scale Systems Require Higher-

Lecture Notes in Computer Science, No. 16,

Level Abstractions, Pro c. Fifth Inter. Workshop on

Apr. 1974, pp. 89{102.

Software Sp eci cation and Design, Pittsburgh, PA,

May 1989, app earing in ACM SIGSOFT Notes,

[7] E.J. Chikofsky ed., Software Development|

Vol. 14, No. 3, May 1989, pp. 143{146.

Computer-aided Software Engineering, Technol-

[22] A.Z. Sp ector, Mo dular Architectures for Distributed

ogy Series, IEEE Computer So ciety Press, 1988.

and Database Systems, Pro c. Eighth ACM

[8] G. Estrin, R.S. Fenchel, R.R. Razouk, and M.K. Ver-

SIGACT-SIGMOD-SIGART Symp. on Princi-

non, SARA System ARchitects Apprentice, IEEE

ples of Database Systems, Philadelp hi a, PA, ACM

Trans. on Software Engineering, Vol. SE-12, No. 2,

Press, Mar. 1989, pp. 217{224.

Feb. 1986, pp. 293{277.

[23] J.A. Zachman, AFramework for Information Sys-

[9] P.Freeman and A.I. Wasserman, Tutorial on Soft-

tems Architecture, IBM Systems Journal, Vol. 26,

ware Design Techniques, IEEE Computer So ciety

No. 3, 1987.

Press, 1976.

[10] D. Jackson, Comp osing Data and Pro cess Descriptions

in the Design of Software Systems, LCS Tech. Re-

p ort 419, Massachusetts Institute of Technology, Cam-

bridge, MA, May 1988.

[11] F.C. Mish, Webster's Ninth New Collegiate Dic-

tionary, Merriam Webster, Spring eld , MA, 1983.

[12] J.E.B. Moss and A.L. Wolf, Toward Principles of In-

heritance and Subtyping for Programming Languages,

COINS Tech. Rep ort 88{95, COINS Dept., Univ.

of Mass., Amherst, MA, Nov. 1988.

[13] J.D. Musa, Software Reliability: Measurement,

Prediction, Application, McGraw-Hill, New York, NY, 1990.