.
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 software architecture research community is realizing 9. D. Garlan, R.T. Monroe, and D. Wile, “ACME: An Architecture that these notations overlap considerably, particularly with Description and Interchange Language,” tech. report, Carnegie Mellon respect to the structural aspects of a software architecture Univ., Pittsburgh, 1996.
ly through informal transmission of n-to-one relationship, or define a spe- pipe-filter style might reuse Unix oper- architectural idioms. For example, a cific compositional pattern such as a ating system primitives to handle task system architecture might be defined pipelined decomposition of a compiler. scheduling, synchronization, and com- informally as a client-server system, a ♦ Semantic interpretation, whereby munication through pipes. Similarly, a blackboard system, a pipeline, an inter- compositions of design elements, suit- client-server style can take advantage preter, or a layered system. While ably constrained by the design rules, of existing RPC (remote procedure these characterizations rarely have for- have well-defined meanings. call) mechanisms and stub generation mal definitions, they convey much ♦ Analyses that can be performed capabilities. Third, it is easier for oth- about a system’s structure and underly- on systems built in that style. Examples ers to understand a system’s organiza- ing computational model. include schedulability analysis for a tion if conventionalized structures are An important class of architectural style oriented toward real-time pro- used. For example, even without giving idioms constitutes what some re- cessing, and deadlock detection for details, characterizing a system as a searchers have termed architectural client-server message passing. An client-server organization immediately styles. An architectural style character- important special case of analysis is sys- conveys a strong image of the kinds of izes a family of systems that are related tem generation: many styles support pieces present and how they fit togeth- by shared structural and semantic application generators (for example, er. Fourth, use of standardized styles properties.2 An architectural style pro- parser generators), or lead to reuse of a supports interoperability. Examples vides a specialized design language for certain shared implementation base include CORBA object-oriented archi- a specific class of systems. Specifically, (such as user interface frameworks and tectures, the OSI (Open Systems styles typically provide the following support for communication between Interconnection) protocol stack, and four things: distributed processes). event-based tool integration. Fifth, as ♦ A vocabulary of design elements: The use of architectural styles has a we noted earlier, by constraining the component and connector types such number of significant benefits. First, it design space, an architectural style as pipes, filters, clients, servers, parsers, promotes design reuse: routine solu- often permits specialized, style-specific and databases. tions with well-understood properties analyses. For example, we can analyze ♦ Design rules, or constraints, that can be reapplied to new problems with systems built in a pipe-filter style for determine which compositions of those confidence. Second, it can lead to sig- throughput, latency, and freedom from elements are permitted. For example, nificant code reuse: often the invariant deadlock, but this might not be mean- the rules might prohibit cycles in a aspects of an architectural style lend ingful for another system that uses a particular pipe-filter style, specify that themselves to shared implementations. different style or an arbitrary, ad hoc a client-server organization must be an For example, systems described in a architecture.
I E E E SOFTWARE 45 .
first-stage: Filter . p : Pipe first-stage: Filter input: output: source: sink: input: output: DataInput DataOutput DataOutput DataInput DataInput DataOutput
Figure 1. A simple system in the pipe-and-filter style is specified using an architec- tural notation. tools and notations. As the following examples illustrate, software architec- ture concepts allow an architect to describe multiple, rich interfaces to a Style pipe-and-filter component and to describe and encap- Interface Type DataInput = (read → (data?x → DataInput sulate complex protocols of component interaction that are difficult to describe [] end-of-data → close → √)) using traditional object-oriented con- [] ( → √) close cepts and notations. → [] → √ Interface Type DataOutput = write DataOutput close To illustrate the different capabilities of style-based software architecture Connector Pipe design and state-of-the-practice object- Role Source = DataOutput oriented design, consider the simple sys- Role Sink = DataInput tem presented in Figures 1 through 5. Figures 1 and 2 use common architectur- Glue = Buf<> where al notations (see the boxed text on archi- tecture description languages on page Buf = Source.write?x → Buf [] Source.close → Closed <>
46 JANUARY 1997 .
type and protocol specifications given design to determine emergent sys- is therefore not capable of supporting an in the Wright specification. Thus, the temwide properties such as freedom explicit, sophisticated protocol descrip- graphical diagram actually has a firm from deadlock (provided that the sys- tion like the pipe in the architectural semantic grounding for specification tem contains no cycles), throughput example. Rather, this is a generic associ- and analysis. rates, and potential system bottlenecks. ation, implying that the upstream filter The sample system has two primary In contrast to the stylized architec- can invoke any public method of the components, labeled stage 1 and stage tural design shown in Figures 1 and 2, downstream filter. Although objects can 2, each of which transforms a data Figures 3 through 5 present different be sophisticated entities in the OMT stream and then sends it to the next OODs of the same system in progres- paradigm, the vocabulary for determin- component downstream. The compo- sively more sophisticated descriptions. ing interactions between objects is rela- nents interact via the pipe protocol The first OMT diagram, in Figure 1, tively impoverished for use in architec- specified in Figure 2. For simplicity, provides a simple class diagram that says tural descriptions. Figures 1 and 2 show only two trans- each filter may be associated with other Any object that can send a message formations and ignore system input filters by a pipe association. Each pipe to another object can request that the and output. association has a source and a sink role target object invoke any of its public We can make three observations to indicate directionality. The instance methods. There is effectively a single, about this architectural design, espe- diagram in Figure 1 depicts the example flat interface provided by all objects to cially with respect to the OMT-based system using this class structure. all objects. As a result, it is difficult for design of the same system in Figures 3 The association between the first- an architectural object to limit the ser- through 5. First, the protocol of inter- stage and second-stage filters is not truly vices it can provide based on which action between the filters is rich, a first-class entity like the Filter class and aspects of the interface a requester is explicit, and well specified. The Wright specification in Figure 2 is associated with the pipe connector between two filters (and with all con- nectors of type pipe). This specifica- Filter source tion defines the protocol for transmit- (Filter) pipe (Filter) pipe ting data through a pipe, the ordering source sink first-stage second-stage behavior of the pipe, and the various sink interfaces that the pipe can provide to its attached filters. Because a primary focus of software architecture is to describe interactions among compo- Figure 3. The same system shown in Figure 1 is depicted here using a naive object- nents, this capability is important. oriented notation (OMT). Second, both the components and con- nectors—filters and pipes in this style—have multiple, well-defined interfaces. As a result, a pipe can limit the services that it provides to the fil- Filter ters on each end. Likewise, a filter can specify whether each of its interfaces will provide input or output, as well as (Filter) (Filter) the type of data passing through. In source sink (Pipe) source sink this example, the upstream filter can first-stage second-stage only write to the pipe, and the down- Pipe stream filter can only read from the pipe, preventing inappropriate access read_from() to connector functionality (such as the write_to() upstream pipe reading from the pipe). Finally, because there is a rich notion of connector semantics built into the Figure 4. An OMT specification is used to define the same system architecture style definition, we can evaluate the shown in Figure 1. Pipe is now a first-class design entity.
I E E E SOFTWARE 47 .
using and the type of connection responsibility to the pipe. providing intermediary objects with between the two objects. However, there is still a significant limited interfaces. Finally, it is difficult to determine limitation to this design. Because the By itself, however, this design does emergent system properties with an pipe object has to offer its full method not completely mitigate the problem of interface to both of its attached filters, access to inappropriate methods. It The pattern either filter can use the write_to() or simply shifts the problem from the fil- read_from() methods. To maintain ter objects accessing inappropriate pipe approach lets us proper dataflow direction, however, we methods to the source and sink objects must be able to specify that the improperly accessing pipe methods. describe relatively upstream filter, annotated by the Because the pipe, source, and sink source role, will use only the write_to() methods are all encapsulated by the complex protocols method, and that the downstream fil- pipe-connector pattern, however, it is of interactions ter, annotated by the sink role, will use possible to describe a protocol by only the read_from() method. Unfor- which the three objects agree to inter- between objects. tunately, the OMT notation does not act according to an appropriate pipe let us formally specify these con- protocol; that is, straints. The directionality and well- ♦ the pipe object takes care of all impoverished vocabulary of connec- defined pipe behavior are thus lost, queuing and buffering issues, tions and interface constraints. For along with the design analyses and ♦ only the source role may invoke example, the ability to invoke any assurances that go with them. It is cer- the pipe’s enqueue_data() method, and method of an associated object at any tainly possible to create filters that ♦ only the sink role may invoke the time makes it difficult to determine abide by this protocol, but it is difficult pipe’s dequeue_data() method. dataflow characteristics and freedom to specify and enforce this constraint Further details of this protocol can also from deadlock, which are both calcu- generally and explicitly using standard be encoded in the pattern and its objects. lated relatively easily using the soft- OOD notions. The pattern approach lets us ware architecture and architectural describe relatively complex protocols of style constructs described earlier. Design patterns. An object-oriented interactions between objects that we Figure 4 shows an attempt to approach to specifying an architectural want to encapsulate, but don’t want to address some of the issues raised by the pipe connector for use in pipe-and-fil- encapsulate within a single class. We design in Figure 3. It does so by mak- ter style systems, along with rules for could have described many of the con- ing the pipe connector a first-class how a pipe can be properly instantiated straints that the source and sink objects object. In this diagram, we use a pipe in a design, apparently will require the satisfy in the Filter class, but doing so object to connect two filter objects. cooperation of multiple objects. The would have added constraints to the Using the OMT notation, it is now emerging concept of design patterns class that may not be generally appro- possible to add behavioral semantics to addresses this issue. priate, and might have significantly the Pipe class by associating dynamic Figure 5 presents a third and final decreased reusability. It would also have and functional models with it. The revision of the simple pipe-and-filter spread the interaction protocol among a Pipe class also introduces two new architecture. This time, the pipe con- wider variety of constructs, when we methods, read_from() and write_to(), struct has been broken into three inter- really want to be able to encapsulate it that filters must call to send data on acting objects: to clarify the design and ease the process the pipe or read data from it. ♦ a pipe object controls dataflow of reasoning about the design. The need One effect of placing a pipe entity and buffering, to use three different types of objects, between two filters is that the upstream ♦ a source object attaches to the interconnected with a pattern specifica- filter no longer knows which down- upstream filter and provides only a tion, significantly hinders the goal of stream filter is receiving and process- write_to() interface to the pipe, and simplicity. Although we could model a ing its data. As a result, the upstream ♦ a corresponding sink object pipe connection using OMT and design filter no longer has access to the down- attaches to the downstream filter and patterns, much of the simplicity and ele- stream filter’s methods. It can only provides only a read_from() interface gance that came from specifying a sim- access the pipe that connects them, to the pipe. ple type-annotated arrow with the archi- ensuring a significant degree of inde- This solution solves the problem of tectural notation is lost when connectors pendence from the downstream filter both filters having access to both are no longer first-class entities, as in the and transferring communication read_from() and write_to() methods by OOD paradigm.
48 JANUARY 1997 .
Summary. As these examples illustrate, architectural designs involve abstractions that may not necessarily be best mod- Filter eled as a system of objects, at least in the narrow sense of objects as encapsulated accept_input() data types that interact through method invocation. This point is not limited to Source Sink dataflow styles such as pipe-and-filter. We can easily make similar arguments (Filter) (Filter) about architectural design done in a lay- write_to() read_from() (Source) (Pipe) (Sink) ered style, a client-server–based style, a first-stage second-stage distributed-database style, or many Pipe Pipe pattern instance other styles of architectural design. Given that architectural styles can describe a broad range of different design enqueue() dequeue() families, it is tempting to view object- oriented design as a style of architectural design in which all components are Pipe pattern objects and all connections are simple associations or aggregations (to use the OMT vocabulary). Indeed, it is possible Figure 5. In this OMT-based specification of the system shown in Figure 1, the pipe to define object-based architectural styles connector is represented as a design pattern. Connector interfaces (source and sink) that provide the typical primitive system are now first-class entities. construction facilities supported by many OOD toolsets. This view is quite reason- able for the subset of OOD that deals important constrasts with object-orient- connector in an architectural design. with architectural abstractions. There ed design. Although both are concerned The fundamental issues that the two are, on the other hand, a number of with system structure in general, archi- approaches address and the abstraction design issues addressed directly by OOD tectural design involves a richer collec- mechanisms that they provide, how- that are generally considered outside the tion of abstractions than is typically pro- ever, are not the same. scope of architectural design. Examples vided by OOD. These abstractions sup- include ways of modeling problem port the ability to describe new kinds of domains and requirements, and imple- potentially complex system glue (or con- ARCHITECTURAL STYLES mentation issues such as designing data nectors). In addition to the pipe connec- AND DESIGN PATTERNS structures and algorithms. These con- tor illustrated earlier, it is also possible to cerns are relevant to software develop- define n-ary connectors such as an event Two of the primary limitations of ment and should probably be considered system, an RPC-based SQL query, or a traditional OOD, as described in the when a system architecture is being two-phase-commit transaction protocol. previous examples, are the difficulty in designed; it should not, however, be nec- Architectural abstractions also let a specifying how groups of objects interact essary to directly express and address all designer associate multiple interfaces and in specifying and packaging related of them in an architectural description. with components and to express topo- collections of objects for reuse. As Architectural design is concerned logical and other semantically based Figure 5 shows, design patterns can mit- with composing systems from compo- constraints over a design. igate these problems. The basic idea nents, and the interactions between Thus neither architectural design behind design patterns is that common these components. Such compositions nor object-oriented design subsumes idioms are found repeatedly in software provide an abstract view of a system, so the other. They are both appropriate at designs and that these patterns should be that the designer can do system-level various times in the development made explicit, codified, and applied analyses and reason about system process and they share some common appropriately to similar problems. integrity constraints. Examples include notions and concepts. Just as you can Several approaches to expressing these throughput rates and freedom from specify an OO-based architectural style, patterns have arisen over the past four or deadlock. These distinctive aspects of you can use an OOD to implement or five years, most of which have focused architectural design highlight several refine a sophisticated component or on patterns for OOD.4,5 The utility of
I E E E SOFTWARE 49 .
Primitive vocabulary:
Primitive Informal description Interface constraints Properties vocabulary Components: (ports define typed component interfaces) OS Process. Processes read input messages, at least 1 async-input port processing-cost, rate, Process send results to output interfaces. at least 1 async-output port input-message-type(s), at least 0 sync-caller ports output-message-type(s) Component for which processes contend. exactly 0 async ports resource-cost Resource at least 1 sync-callee port
Send messages into the system at a exactly 0 sync ports output-rate, Device predefined rate. exactly 0 async-input ports output-message-type at least 1 async-output port
Connectors: (roles define typed connector interfaces) Asynchronous message channel for typed exactly 1 async-input role message-type async-msg-pass messages. exactly 1 async-output role Like async-msg-pass, but requires rendevous at least 1 async-input role message-type async-msg-pass- before sending message. N-ary connector. exactly 1 async-output role rendevous Binary synchronous request channel, exactly 1 sync-caller role message-type sync-request typed messages. exactly 1 sync-callee role
Design rules (list is a subset of all RTP/C style design rules): • Async-msg-pass connectors may only connect (process, process) or (device, process) pairs of components. • Sync-request connectors may only connect (process, resource) pairs of components. • All processes must have an attached input interface. • Each connector's input message type must match its output message type. • ... Style-based design analyses: Analysis Description
Message path Insures only valid message types are passed along each message channel. Provides early detection of message typechecking type mismatch. Rate calculation Determines how often each process can be given control and resources.
Schedulability Calculates whether this design could be scheduled on a uniprocessor with user-specified performance characteristics. Repair heuristics If the system cannot be scheduled, this analysis identifies bottlenecks and suggests likely repairs and improvements.
Figure 6. An informal specification of the Real-Time Producer/Consumer (RTP/C) style.
design patterns, however, extends design pattern requires, however, a descriptive and analytical capabilities beyond this. There are three fundamen- rather broad definition of the scope of along with proven mechanisms for tal requirements for specifying and design patterns. An architectural style is addressing specific design challenges in reusing software design patterns: the probably better thought of as a design the form of design patterns. design domain must be well understood, language that provides architects with a We see patterns and architectural it must support the encapsulation of vocabulary and framework with which styles as complementary mechanisms design elements, and it must have they can build useful design patterns to for encapsulating design expertise. An evolved a collection of well-known and solve specific problems—much as OMT architectural style provides a collection proven design idioms. Pattern languages provides a framework and notation for of building-block design elements, rules then let knowledgeable designers codify working with objects. Second, for a and constraints for composing the proven designs, design fragments, and given style there may exist a set of building blocks, and tools for analyzing frameworks for subsequent reuse. idiomatic uses. These idioms act as and manipulating designs created in the Architectural styles relate closely to microarchitectures, or architectural style. Styles generally provide guidance design patterns in two ways. First, design patterns, designed to work with- and analysis for building a broad class of architectural styles can be viewed as in a specific architectural style. By pro- architectures in a specific domain, kinds of patterns8—or perhaps more viding a framework within which these whereas patterns focus on solving small- accurately as pattern languages.9 patterns work, the designer using the er, more specific problems within a Describing an architectural style as a pattern can leverage style’s the broad given style (or perhaps multiple styles).
50 JANUARY 1997 .
Shared-resource architectural pattern Message-Replicator architectural pattern Intent: Avoid deadlock when processes share common resources. Intent: Send identical messages to a dynamically changing group Motivation: System deadlock can occur when architectural of other components using a principled protocol. components lock shared resources in an inappropriate order. Motivation: A component's output may need to be sent to a Applicability: Architectural designs done in the RTP/C style, where variable set of components. The set of receiving components may process components share resource components and freedom from change as the system runs, and constraints on the order in which deadlock is more important than run-time performance. recipients receive the messages may be important (as in the case of a stock-quote and trading system). Structure: sr : Applicability: Architectural designs done in the RTP/C style 1 where the set of applicable recipients for the output of a specific P : resource 1 component may vary as the system runs. RTP/C process sr : 2 Structure: resource Msg-replicator: RTP/C process Pn: RTP/C process srm: Participants: The Msg-replicator process is an RTP/C process resource component with a single input port and a variable array of output ports. There is a single async-msg-pass connector providing input and Participants: N RTP/C process components, each connected to m a set of async-msg-pass connectors that send output to the recipients. or fewer RTP/C resource components. All connectors used are Collaborations: When this pattern is instantiated the designer needs RTP/C sync-request connectors from processors to resources. to select a protocol by which the messages will be sent to the outputs. Collaborations: In order to avoid deadlock, a process P can only Options include sequentially, whereby messages are written in a k user-specified order to each output connector one at a time; parallel, send a request on resources sri (locking sri) if i > j, where sj is the highest numbered resource currently held by P . whereby all messages are written to their output connectors k concurrently; or a user-specified variation on one of these. Consequences: Using the ordered access protocol to prevent deadlock will not generally lead to optimal resource access or allocation. Other Consequences: The dynamic nature of this pattern can make some protocols may lead to better average-case performance. static analyses, such as dataflows and delivery guarantees, difficult or impossible to perform.
Figure 7. Two sample architectural design patterns in the RTP/C style.
It is also important to note that patterns RTP/C primitive design elements and to specify architectural patterns also. In need not be architectural. Indeed, many guidelines form a language that can be fact, several of the design patterns that patterns in recent handbooks4,5 deal used to capture more detailed, concrete Gamma and his colleagues describe with solutions to lower-level program- solutions to specific problems. This appear to apply to architectural design.8 ming mechanisms, rather than system- style provides a well-understood and Examples include the Facade pattern structuring issues. well-defined vocabulary framework for that provides a single interface to a col- composing individual design elements lection of objects, the Observer pattern Pattern and style examples. To illus- in principled ways that support real- that specifies a mechanism for main- trate the scope and purpose of architec- time analyses. Figure 7 shows two sim- taining consistency among objects (or tural styles, as well as how they relate to plified design patterns done in the components), and the Strategy pattern design patterns, consider the architec- RTP/C style—the forked-memory pat- that specifies how to separate algorith- tural style specification given in Figure tern and the message-replicator pattern. mic choices from interface decisions. 6. This style, described as the Real- Along with a diagram, each pattern pro- None of the listed patterns are limited Time Producer/Consumer style, is vides information describing its applica- to being only architectural patterns. All designed to assist architects putting bility, consequences of use, and so on. have applicability at lower levels of together real-time multimedia systems We have shown these patterns using the design (such as detailed design or running on uniprocessor computers.10 structure provided in a 1995 book by implementation code). In addition to Figure 6 provides an informal descrip- Erich Gamma and his colleagues.4 This the architectural patterns listed here, tion of the RTP/C style, emphasizing framework works well for architectural several patterns in the Gamma et al. the types of (primitive) design vocabu- patterns as well as for OO patterns, with book, for example, fail to address archi- lary used by designs constructed in the the primary difference being that archi- tectural issues. The Factory Method style, design rules and constraints that tectural patterns address a more specific and Flyweight patterns. Both of these specify how the elements may be com- set of design issues (as described earlier patterns, for instance, deal with lower- posed, and analyses that can be per- under “What is software architecture?”) level implementation issues than archi- formed on the design. The RTP/C than do OO patterns. Just as OMT and tectures generally specify. style definition describes a set of primi- objects are used to show the design pat- Thus, architectural design patterns tive building blocks and guidelines for terns in most OOD patterns hand- and object-oriented design patterns are putting together a fairly broad range of books, the vocabulary and rules of simply instances of the more general systems within a reasonably well under- architectural style can be used to specify class of all design patterns. Unlike stood domain. architectural design patterns. design patterns proper, however, an Even with such a well-defined style, It follows, then, that OMT and the architectural style provides a language however, relatively concrete design pat- design patterns notations from the and framework for describing families terns play an important role. The OOD patterns handbooks can be used of well-formed software architectures.
I E E E SOFTWARE 51 .
The role of style is to provide a lan- design patterns such as those given by ture complementary aspects of soft- guage for expressing both architectural Gamma and his colleagues.4 A specific ware design. Although the issues and instances and patterns of common architectural style is better thought of as aspects of software design addressed by architectural design idioms. As a result, a language for building patterns than as these four approaches overlap some- the constructs and concepts underlying an instance of a design pattern itself. what, none completely subsumes the architectural style are comparable to other. Each has something to offer in those underlying an OOD methodolo- rchitectures, architectural styles, the way of a collection of representa- gy like OMT, rather than a set of A objects, and design patterns cap- tional models and mechanisms. ◆
ACKNOWLEDGMENTS We thank Robert Allen for his helpful comments. This research was sponsored by the National Science Foundation under grant no. CCR- 9357792 and a graduate research fellowship; by the Wright Laboratory, Aeronautical Systems Center, Air Force Materiel Command, USAF; by the Advanced Research Projects Agency under grant no. F33615-93-1-1330; and by Siemens Corporate Research.
REFERENCES 1. M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall, Englewood Cliffs, N.J., 1996. 2. G. Abowd, R. Allen, and D. Garlan, “Using Style to Give Meaning to Software Architecture,” Proc. SIGSOFT ’93: Foundations Software Eng., ACM, New York, 1993. Also in Software Eng. Notes, Dec. 1993, pp. 9-20. 3. J. Rumbaugh et al., Object-Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, N.J., 1991. 4. E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Design, Addison-Wesley, Reading, Mass., 1995. 5. W. Pree, Design Patterns for Object-Oriented Software Development, Addison-Wesley, Reading, Mass., 1995. 6. D. Perry and A. Wolf, “Foundations for the Study of Software Architecture,” ACM Software Eng. Notes, Vol. 17, No. 4, Oct. 1992, pp. 40-52. 7. R. Allen and D. Garlan, “Formalizing Architectural Connection,” Proc. 16th Int’l Conf. Software Eng., IEEE Computer Soc. Press, Los Alamitos, Calif., 1994, pp. 71-80. 8. M. Shaw, “Some Patterns for Software Architecture,” in Pattern Languages of Program Design, Vol. 2, J. Vlissides, J. Coplien, and N. Kerth, eds., Addison- Wesley, Reading, Mass., 1996, pp. 255-269. 9. N.L. Kerth, “Caterpillar’s Fate: A Pattern Language for Transformations from Analysis to Design,” in Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley, Reading, Mass., 1995. 10. K. Jeffay, “The Real-Time Producer/Consumer Paradigm: A Paradigm for the Construction of Efficient, Predictable Real-Time Systems,” Proc. 1993 ACM/SIGAPP Symp. Applied Computing, ACM Press, New York, 1993, pp. 796-804.
Robert T. Monroe is a doctoral candidate in the Ralph Melton is a graduate student in the Department Department of Computer Science at Carnegie Mellon of Computer Science at Carnegie Mellon University. University. He holds an MS in computer science from He holds a BS from Stanford University. His research Carnegie Mellon and a BS from the University of interests include software architecture and the use of Michigan. His research interests include software formal methods to describe design fragments and their design tools, software architecture, and languages for composition. expressing software design expertise. He is a member of the IEEE Computer Society and ACM.
Andrew Kompanek is a research programmer with David Garlan is associate professor of computer science the ABLE research group in Carnegie Mellon at Carnegie Mellon University, where he heads the University’s School of Computer Science. He recently ABLE Project. His research focuses on software archi- received his BS in mathematics and computer science tecture, the application of formal methods to the con- from Carnegie Mellon. His current work includes the struction of reusable designs, and software development design and development of visualization and automated environments. He completed his PhD at Carnegie layout tools for software architectures. Mellon, and holds a BA from Amherst College and an MA from the University of Oxford, England. He is member of the IEEE Computer Society and ACM.
Address questions about this article to Robert Monroe, School of Computer Science, Carnegie Mellon University, 5000 Forbes Ave., Pittsburgh, PA 15213; [email protected].
52 JANUARY 1997