• Abstract and Figures
• Public Full-text

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 .

Load more

  13

Copy Link