. Architectural Styles, Design Patterns, and Objects ROBERT T. M ONROE, ANDREW KOMPANEK, RALPH MELTON, and DAVID GARLAN Carnegie Mellon University oftware system builders increasingly recognize the importance of exploiting design knowledge in the Architectural styles, engineering of new systems. Several distinct but object-oriented design, related approaches hold promise. and design patterns One approach is to focus on the architectural level all hold promise as of system design—the gross structure of a system as a composition of interacting parts. Architectural approaches that simplify Sdesigns illuminate such key issues as scaling and portability, software design and the assignment of functionality to design elements, interaction reuse by capturing and protocols between elements, and global system properties such exploiting system design as processing rates, end-to-end capacities, and overall perfor- mance.1 Architectural descriptions tend to be informal and idio- knowledge. This article syncratic: box-and-line diagrams convey essential system struc- explores the capabilities ture, with accompanying prose explaining the meaning of the and roles of the various symbols. Nonetheless, they provide a critical staging point for determining whether a system can meet its essential require- approaches, their ments, and they guide implementers in constructing the system. strengths, and their More recently, architectural descriptions have been used for limitations. codifying and reusing design knowledge. Much of their power comes from use of idiomatic architectural terms, such as “client- server system,” “layered system,” or “blackboard organization.” IEEE SOFTWARE 0740-7459/97/$10.00 © 1997 IEEE 43 . These convey widespread if informal ance for combining design elements in are often described by a more detailed understanding of the descriptions and principled and proven ways. architecture at a lower level. let engineers quickly communicate Each of these often complementary Architectural descriptions are pri- approaches to capturing software marily concerned with the following Each approach has design knowledge and software designs basic issues: themselves has both benefits and draw- ♦ System structure. Architectural something to offer: backs. To effectively use these ap- descriptions characterize a system’s proaches, we need to understand their structure in terms of high-level compu- a collection of terminologies, capabilities, similarities, tational elements and their interactions. and differences. Further, we need to That is, an architecture frames its design representational understand the roles that each can play solution as a configuration of interacting models and in successful software design. components. It is specifically not about requirements (for example, abstract rela- mechanisms. tionships between elements of a prob- WHAT IS SOFTWARE lem domain) nor implementation details ARCHITECTURE DESIGN? (such as algorithms or data structures). their designs to others. Such architec- ♦ Rich abstractions for interaction. tural idioms represent what have been In practice, an architectural design Interactions between architectural termed architectural styles.2 fulfills two primary roles. First, it pro- components—often drawn as connect- The object-oriented paradigm vides a level of abstraction at which soft- ing lines—provide a rich vocabulary for offers another approach to describing ware system designers can reason about system designers. Although interactions system designs. In its simplest form, system behavior: function, performance, may be as simple as procedure calls or object-oriented design lets us encapsu- reliability, and so on. By abstracting shared data variables, they often repre- late data and behavior in discrete away from implementation details, a sent more complex forms. Examples objects that provide explicit interfaces good architectural description makes a include pipes (with conventions for to other objects; groups of objects system design intellectually tractable handling end-of-file and blocking), interact by passing messages among and exposes the properties most crucial client-server interactions (with rules themselves. OOD has proven to be to its success. It is often the key techni- about initialization, finalization, and quite popular in practice, and sophisti- cal document used to determine exception handling), event-broadcast cated OOD methodologies offer sig- whether a proposed new system will connections (with multiple receivers), nificant leverage for designing soft- meet its most critical requirements. and database accessing protocols (with ware,2-3 including ease of decomposing Second, an architectural design protocols for transaction invocation). a system into its constituent elements serves as the “conscience” for a system ♦ Global properties. Architectural and partitioning system functionality as it evolves. By characterizing the cru- designs typically describe overall sys- and responsibility among those ele- cial system design assumptions, a good tem behavior. Thus the problems they ments. However, it is not by itself well architectural design guides the process address are usually system-level ones, suited to describing complex interac- of system enhancement—indicating such as end-to-end data rates and tions between groups of objects. what aspects of the system can be easily latencies, resilience of one part of the Likewise, although individual objects changed without compromising system system to failure in another, or system- can often be reused in other imple- integrity. As with building blueprints, a wide propagation of changes when one mentations, capturing and reusing well-documented architectural design part of a system is modified (such as common design idioms involving mul- makes explicit the software’s “load- changing the platform on which the tiple objects can be difficult. bearing walls,”6 a fact that helps not system runs). Design patterns have become an only at design time but also throughout increasingly popular choice for a system’s life cycle. To satisfy its mul- addressing OOD’s limitations. Al- tiple roles over time, an architectural ARCHITECTURAL STYLE though the principles underlying description must be simple enough to design patterns are not inherently tied permit system-level reasoning and pre- As with any design activity, a central to OOD, much recent work in this diction; practically speaking, it should question is how to leverage past experi- area has focused on design patterns for fit on a page or two. Consequently, it is ence to produce better designs. In cur- composing objects.4,5 Like architectur- usually hierarchical: atomic architectur- rent practice, architectural designs al styles, design patterns provide guid- al elements at one level of abstraction have been codified and reused primari- 44 JANUARY 1997 . SOFTWARE ARCHITECTURE DESCRIPTION specification. ACME is an emerging generic architecture LANGUAGES description language that is designed to facilitate the inter- change of architectural designs between different ADLs and A variety of architectural design languages have been cre- toolsets.9 ated to provide software architects with notations for specify- The notations used to express the architectural diagrams ing and reasoning about architectural designs. ADLs focus on and style specifications in this article’s examples reflect termi- various aspects of architectural design, and the analyses they nology and notations commonly found in these architecture support vary in flavor from rather informal to highly formal. description languages. Here are some examples: ♦ 1 The UniCon system focuses on compilation of architec- REFERENCES tural descriptions and modules into executable code. 1. M. Shaw et al., “Abstractions for Software Architecture and Tools to 2 ♦ Rapide emphasizes behavioral specification and the simu- Support Them,” IEEE Trans. Software Eng., Apr. 1995, pp. 314-335. lation of architectural designs. 2. D.C. Luckham et al., “Specification and Analysis of System Architecture ♦ Wright3 provides a formal basis for specifying component using Rapide,” IEEE Trans. Software Eng., Apr. 1995, pp. 336-355. 3. R. Allen and D. Garlan, “Formalizing Architectural Connection,” Proc. interactions (via connectors) and architectural styles. 16th Int’l Conf. Software Eng., IEEE Computer Soc. Press, Los ♦ The Aesop System4 supports the explicit encoding and use Alamitos, Calif., pp. 71-80. of a wide range of architectural styles. 4. D. Garlan, R. Allen, and J. Ockerbloom, “Exploiting Style in Architectural Design Environments,” Proc. SIGSOFT ’94, ACM Press, New York, 1994, 5 ♦ Various domain-specific software architecture languages pp. 179-185. support architectural specification tailored to a specific appli- 5. W. Tracz, “DSSA Frequently Asked Questions,” Software Eng. Notes, Apr. cation domain. 1994, pp. 52-56. In addition to the ADLs described above, which were 6. J.M. Spivey, The Z Notation: A Reference Manual, Prentice-Hall, Englewood Cliffs, N.J., 1989. developed specifically for describing software architectures, 7. C.A.R. Hoare, Communicating Sequential Processes, Prentice-Hall, several more general formal specification languages have also Englewood Cliffs, N.J., 1985. been used. Examples include Z,6 Communicating Sequential 8. P. Inverardi and A. Wolf, “Formal Specification and Analysis of Software Processes,7 and the Chemical Abstract Machine.8 Architectures Using the Chemical Abstract Machine Model,” IEEE Trans. Software Eng., Apr. 1995, pp. 373-386. The