PAT --IER I -0 IE 1N - D
`SOF .~ WA
`'RE
`ARCHITEC
`A svstem of Patterns
`
`Volume 1
`
`Frank Buschmann
`
`Regine Meunier
`
`Hans Rohnert
`
`Peter Sommerlad
`
`Michael Stal
`
`@QWILEY
`
`Starbucks Corp. Exhibit 1036
`
`

`

`PATTER -ORIENTED
`SOFTWARE
`ARCHITECTURE
`Volume1 A svstem of Patterns
`
`Frank Buschmann
`Regine Meunier
`Hans Rohnert
`Peter Sommerlad
`Michael Stal
`
`Amazon.com says:
`'To get a perspective on the potential of patterns for the bigger
`picture of software engineering ... this book points out how patterns
`work on a variety of levels, from idioms used in particular computer
`languages, such as C++, to design patterns and higher level
`patterns useful for improving the entire software engineering cycle '
`
`Software patterns
`have revolutionized
`the way developers'
`think about how
`software is designed,
`built and
`documented. This
`pioneering first
`volume in the POSA
`series is an essential
`addition to any
`serious programmers
`bookshelf.
`
`@WILEY
`
`wiley.com
`
`Amazon.com customers say:
`'Excellent book on patterns. This book is a perfect companion to
`Design Patterns (the GoF book)'
`
`:4 book for evety software architect ... it allows one to really
`shorten the design time needed'
`
`'This is *the* Patterns Book ... While I have argued since it came out
`that the G of 4 books is the most important programming book of
`the decade, I have to agree ... that this is a deeper, more mature
`work.'
`
`Review in CVu 1997
`'Design Patterns (Gamma eta!) is already a widely read classic and
`I think Pattern-Oriented Software Architecture deserves to become
`one too. Whereas Design Patterns covers a single
`level of abstraction in object-oriented development,
`the present book covers three levels: the high-level
`architectural patterns, design patterns and
`language-specific idioms.'
`
`Starbucks Corp. Exhibit 1036
`
`

`

`---
`
`Frank Buschmann
`Regine Meunier
`Hans Rohnert
`Peter Sommerlad
`Michael Stal
`
`of Siemens AG, Germany
`
`JOHN WILEY & SONS
`Chichester · New York · Brisbane · Toronto · Singapore
`
`Starbucks Corp. Exhibit 1036
`
`

`

`Copyright© 1996 John Wiley & Sons Ltd,
`The Atrium, Southern Gate, Chichester,
`West Sussex P019 8SQ, England
`
`Telephone
`
`(+44) 1243 779777
`
`Email (for orders and customer service enquiries): cs-books@wiley.co.uk
`Visit our Home Page on www.wileyeurope.com or www.wiley.com
`
`Reprinted October 1996, July 1997, July 1998, April 1999, June 2000, February 2001,
`July 2001, November 2002, August 2004, September 2005, February 2006, April2007, January 2008,
`March 2008, January 2009, November 2010, October 2011, July 2013
`
`All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or
`transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or
`otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms
`of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W 1 T
`4LP, UK, without the permission in writing of the Publisher. Requests to the Publisher should be
`addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate,
`Chichester, West Sussex PO 19 8SQ, England, or emailed to permreq@wiley.co.uk, or faxed to
`(+44) 1243 770571.
`
`This publication is designed to provide accurate and authoritative information in regard to the subject
`matter covered. It is sold on the understanding that the Publisher is not engaged in rendering
`professional services. If professional advice or other expert assistance is required, the services of a
`competent professional should be sought.
`
`Other Wiley Editorial Offices
`
`John Wiley & Sons Inc., 111 River Street, Hoboken, NJ 07030, USA
`
`Jossey-Bass, 989 Market Street, San Francisco, CA 94103-1741, USA
`
`Wiley-VCH Verlag GmbH, Boschstr. 12, D-69469 Weinheim, Germany
`
`John Wiley & Sons Australia Ltd, 33 Park Road, Milton, Queensland 4064, Australia
`
`John Wiley & Sons (Asia) Pte Ltd, 2 Clementi Loop #02-01 , JinXing Distripark, Singapore 129809
`
`John Wiley & Sons Canada Ltd, 22 Worcester Road, Etobicoke, Ontario, Canada M9W ILl
`
`Cover illustration: Based upon a photograph of Chartres Cathedral.
`© Monique Jacot I Network photographers Ltd.
`
`British Library Cataloguing in Publication Data
`
`A catalogue record for this book is available from the British Library
`
`ISBN 13:978-0-471-95869-7 (H/B)
`
`Produced from camera-ready copy supplied by the authors using FrameMaker.
`Printed and bound by CPI Group (UK) Ltd, Croydon, CRO 4YY
`
`Starbucks Corp. Exhibit 1036
`
`

`

`2 Architectural Patterns
`
`Layer Cake
`
`2 cl. White Creme de Cacao
`2 cl. Apricot Brandy
`2 cl. Double cream
`
`Pour Creme de Cacao into a Pusse-Cafe glass. Add the
`Apricot Brandy by carefully letting itfiow over the back
`of a spoon that is touching the inside of the glass. Add
`the cream in the same way as the Apricot Brandy. The
`individual layers must not be mixed.
`Drink while reading the Layers pattern.
`
`Architectural patterns express fundamental structural organization
`schemas for software systems. They provide a set of predefined
`subsystems, specify their responsibilities, and include rules and
`guidelines for organizing the relationships between them.
`In this chapter we present the following eight architectural patterns:
`Layers, Pipes and Filters, Blackboard, Broker, Model-View-Controller,
`Presentation-Abstraction-Control, Microkernel, and Reflection.
`
`Starbucks Corp. Exhibit 1036
`
`

`

`26
`
`2.1 Introduction
`
`Architectural Patterns
`
`Architectural patterns represent the highest -level patterns in our
`pattern system. They help you to specify the fundamental structure
`of an application. Every development activity that follows is governed
`by this structure-for example, the detailed design of subsystems, the
`communication and collaboration between different parts of the
`system, and its later extension.
`Each architectural pattern helps you to achieve a specific global sys(cid:173)
`tem property, such as the adaptability of the user interface. Patterns
`that help to support similar properties can be grouped into categories.
`In this chapter we group our patterns into four categories:
`• From Mud to Structure. Patterns in this category help you to avoid
`a 'sea' of components or objects. In particular, they support a
`controlled decomposition of an overall system task into cooperating
`subtasks. The category includes the Layers pattern (31). the Pipes
`and Filters pattern (53) and the Blackboard pattern (71).
`• Distributed Systems. This category includes one pattern, Broker
`(99), and refers to two patterns in other categories, Microkernel
`(171) and Pipes and Filters (53). The Broker pattern provides a
`complete infrastructure for distributed applications. Its underlying
`architecture is soon to be standardized by the Object Management
`Group (OMG) [OMG92). The Microkernel and Pipes and Filters pat(cid:173)
`terns only consider distribution as a secondary concern and are
`therefore listed under their respective primary categories. Details
`about distribution aspects of both patterns are discussed in Sec(cid:173)
`tion 2.3, Distributed Systems, however.
`Interactive Systems. This category comprises two patterns, the
`Model-View-Controller pattern (125). well-known from Smalltalk,
`and the Presentation-Abstraction-Control pattern (145). Both
`patterns support the structuring of software systems that feature
`human-computer interaction.
`• Adaptable Systems. The Reflection (193) pattern and the Microker(cid:173)
`nel pattern (171) strongly support extension of applications and
`their adaptation to evolving technology and changing functional re(cid:173)
`quirements.
`
`•
`
`Starbucks Corp. Exhibit 1036
`
`

`

`Introduction
`
`27
`
`Note that this categorization is not intended to be exhaustive. It works
`for the architectural patterns we describe, but it may become
`necessary to define new categories if more architectural patterns are
`added-see Chapter 5, Pattern Systems for further discussion of this
`idea.
`The selection of an architectural pattern should be driven by the
`general properties of the application at hand. Ask yourself, for
`example, whether your proposed system is an interactive system, or
`one that will exist in many slightly different variants. Your pattern
`selection should be further influenced by your application's non(cid:173)
`functional requirements, such as changeability or reliability.
`It is also helpful to explore several alternatives before deciding on a
`the Presentation(cid:173)
`specific architectural pattern. For example,
`Abstraction-Control pattern (PAC) and the Model-View-Controller
`pattern (MVC) both lend themselves to interactive applications.
`Similarly, the Reflection and Microkernel patterns both support the
`adaptation of software systems to evolving requirements.
`Different architectural patterns imply different consequences, even if
`they address the same or very similar problems. For example, an MVC
`architecture is usually more efficient than a PAC architecture. On the
`other hand, PAC supports multitasking and task-specific user
`interfaces better than MVC does.
`Most software systems, however, cannot be structured according to a
`single architectural pattern. They must support several system
`requirements that can only be addressed by different architectural
`patterns. For example, you may have to design both for flexibility of
`component distribution in a heterogeneous computer network and for
`adaptability of their user interfaces. You must combine several
`patterns to structure such systems-in this case, suitable patterns
`are Broker and Model-View-Controller. The Broker pattern provides
`the infrastructure for the distribution of components, while the model
`of the MVC pattern plays the role of a server in the Broker
`infrastructure. Similarly, controllers take the roles of clients, and
`views combine the roles of clients and servers, as clients of the model
`and servers of the controllers.
`However, a particular architectural pattern, or a combination of
`several, is not a complete software architecture. It remains a
`
`--
`
`Starbucks Corp. Exhibit 1036
`
`

`

`28
`
`Architectural Patterns
`
`s1:nlctural framework for a software system that must be further
`specified and refined. This includes the task of integrating the
`application's functionality with the framework, and detailing its
`components and relationships, perhaps with help of design patterns
`and idioms. The selection of an architectural pattern, or a
`combination of several, is only the first step when designing the
`architecture of a software system.
`
`Starbucks Corp. Exhibit 1036
`
`

`

`2.2 From Mud to Structure
`
`29
`
`Before we start the design of a new system, we collect the require(cid:173)
`ments from the customer and transform them into specifications.
`Both these activities are more complex than is often believed. A recent
`book by Michael Jackson [Jac95) illuminates this topic.
`Being optimistic, we assume that the requirements for our new sys(cid:173)
`tem are well-defined and stable. The next major technical task is to
`define the architecture of the system. At this stage, this means finding
`a high-level subdivision of the system into constituent parts. We are
`often aware of a whole slew of different aspects, and have problems
`organizing the mess into a workable structure. Ralph Johnson calls
`this situation a 'ball of mud' [Joh96). This is usually all we have in the
`beginning, and we must transform it into a more organized structure.
`Cutting the ball along lines visible in the application domain won't
`help, for several reasons. On one hand, the resulting software system
`will include many components that have no direct relationship to the
`domain. Manager and helper functionality is a prime example of this.
`On the other hand, we want more than just a working system-it
`should possess qualities such as portability, maintainability,
`understandability, stability, and so forth that are not directly related
`to the application's functionality.
`
`We describe three architectural patterns that provide high-level
`system subdivisions of different kinds: Layers, Pipes and Filters, and
`Blackboard.
`• The Layers pattern (31) helps to structure applications that can be
`decomposed into groups of subtasks in which each group of
`subtasks is at a particular level of abstraction.
`• The Pipes and Filters pattern (53) proVides a structure for systems
`that process a stream of data. Each processing step
`is
`encapsulated in a filter component. Data is passed through pipes
`between adjacent filters. Recombining filters allows you to build
`families of related systems.
`• The Blackboard pattern (71) pattern is useful for problems for
`which no deterministic solution strategies are known.
`In
`
`Starbucks Corp. Exhibit 1036
`
`

`

`30
`
`Architectural Patterns
`
`their
`Blackboard several specialized subsystems assemble
`knowledge to build a possibly partial or approximate solution.
`The Layers pattern describes the most widespread principle of
`architectural subdivision. Many of the block diagrams we see in
`system architecture documents seem to imply a layered architecture.
`However, the real architectures all too often turn out to be either a
`mix of different paradigms-which by itself cannot be criticized-or
`concealed collections of cooperating components without clear
`architectural boundaries between them. To help with the situation,
`we try to be more rigorous in our description and list the
`characteristics of truly layered systems.
`The Pipes and Filters pattern, in contrast, is less often used, but is
`attractive
`in areas where data streams can be processed
`incrementally. Surprisingly, some system families modelled in this
`fashion turn out to be poor candidates for this paradigm, neglecting
`areas where this pattern could be used more beneficially. We expand
`this topic further in the pattern description.
`The Blackboard pattern comes from
`the Artificial Intelligence
`community. We describe this paradigm as a pattern since the idea
`behind it deserves to be seen in a wider context. In poorly(cid:173)
`structured-or simply new and immature--domains we often have
`only patchy knowledge about how to tackle particular problems. The
`Blackboard pattern shows a method of combining such patchy
`knowledge to arrive at solutions, even if they are sub-optimal or not
`guaranteed. When the application domain matures with time,
`designers often abandon the Blackboard architecture and develop
`architectures that support closed solution approaches, in which the
`processing steps are predefined by the structure of the application.
`
`Starbucks Corp. Exhibit 1036
`
`

`

`Layers
`
`31
`
`The Layers architectural pattern helps to structure applications that
`can be decomposed into groups of subtasks in which each group of
`subtasks is at a particular level of abstraction.
`
`Example Networking protocols are probably the best-known example oflayered
`architectures. Such a protocol consists of a set of rules and con(cid:173)
`ventions that describe how computer programs communicate across
`machine boundaries. The format, contents, and meaning of all
`messages are defined. All scenarios are described in detail, usually by
`giving sequence charts. The protocol specifies agreements at a variety
`of abstraction levels, ranging from the details of bit transmission to
`high-level application logic. Therefore designers use several sub(cid:173)
`protocols and arrange them in layers. Each layer deals with a specific
`aspect of communication and uses the services of the next lower
`layer. The International Standardization Organization (ISO) defined
`the following architectural model, the OSI 7-Layer Model [Tan92]:
`
`Layer 7 ProVides miscellaneous protocols
`for common actiVities
`
`Layer 6 Structures information
`and attaches semantics
`
`Layer 5 ProVides dialog control and
`synchroniza lion facilities
`
`Layer 4 Breaks messages into packets
`and guarantees delivery
`
`Layer 3 Selects a route
`from sender to receiver
`
`Layer 2 Detects and corrects errors
`in bit sequences
`
`Layer 1 Transmits bits: velocity,
`bit-code, connection. etc.
`
`Starbucks Corp. Exhibit 1036
`
`

`

`32
`
`Architectural Patterns
`
`A layered approach is considered better practice than implementing
`the protocol as a monolithic block, since implementing conceptually(cid:173)
`different issues separately reaps several benefits, for example aiding
`development by teams and supporting incremental coding and
`testing. Using semi-independent parts also enables the easier ex(cid:173)
`change of individual parts at a later date. Better implementation
`technologies such as new languages or algorithms can be in(cid:173)
`corporated by simply reWriting a delimited section of code.
`While OSI is an important reference model. TCP /IP, also known as the
`'Internet protocol suite', is the prevalent networking protocol. We use
`TCP /IP to illustrate another important reason for layering: the reuse
`of individual layers in different contexts. TCP for example can be used
`'as is' by diverse distributed applications such as telnet or ftp.
`
`Context A large system that requires decomposition.
`
`Problem
`
`that you are designing a system whose dominant
`Imagine
`characteristic is a mix of low- and high-level issues, where high-level
`operations rely on the lower-level ones. Some parts of the system
`handle low-level issues such as hardware traps, sensor input,
`reading bits from a file or electrical signals from a wire. At the other
`end of the spectrum there may be user-Visible functionality such as
`the interface of a multi-user 'dungeon' game or high-level policies
`such as telephone billing tariffs. A typical pattern of communication
`flow consists of requests moVing from high to low level, and answers
`to requests, incoming data or notification about events traveling in
`the opposite direction.
`Such systems often also require some horizontal structuring that is
`orthogonal to their vertical subdiVision. This is the case where several
`operations are on the same level of abstraction but are largely in(cid:173)
`dependent of each other. You can see examples of this where the word
`'and' occurs in the diagram illustrating the OSI 7 -layer model.
`The system specification proVided to you describes the high-level
`tasks to some extent, and specifies the target platform. Portability to
`other platforms is desired. Several external boundaries of the system
`are specified a priori, such as a functional interface to which your
`system must adhere. The mapping of high-level tasks onto the plat(cid:173)
`form is not straightforward, mostly because they are too complex to
`be implemented directly using services provided by the platform.
`
`Starbucks Corp. Exhibit 1036
`
`

`

`Layers
`
`33
`
`In such a case you need to balance the following forces:
`• Late source code changes should not ripple through the system.
`They should be confined to one component and not affect others.
`• Interfaces should be stable, and may even be prescribed by a stan(cid:173)
`dards body.
`• Parts of the system should be exchangeable. Components should
`be able to be replaced by alternative implementations without
`affecting the rest of the system. A low-level platform may be given
`but may be subject to change in the future. While such funda(cid:173)
`mental changes usually require code changes and recompilation,
`reconfiguration of the system can also be done at run-time using
`an administration interface. Adjusting cache or buffer sizes are
`examples of such a change. An extreme form of exchangeability
`might be a client component dynamically switching to a different
`implementation of a service that may not have been available at
`start-up. Design for change in general is a major facilitator of
`graceful system evolution.
`• It may be necessary to build other systems at a later date with the
`same low-level issues as the system you are currently designing.
`
`• Similar responsibilities should be grouped to help understand(cid:173)
`ability and maintainability. Each component should be coherent(cid:173)
`if one component implements divergent issues its integrity may be
`lost. Grouping and coherence are conflicting at times.
`• There is no 'standard' component granularity.
`• Complex components need further decomposition.
`• Crossing component boundaries may impede performance, for
`example when a substantial amount of data must be transferred
`over several boundaries, or where there are many boundaries to
`cross.
`• The system will be built by a team of programmers, and work has
`to be subdivided along clear boundaries-a requirement that is
`often overlooked at the architectural design stage.
`
`Starbucks Corp. Exhibit 1036
`
`

`

`34
`
`Architectural Patterns
`
`Solution From a high-level viewpoint the solution is extremely simple.
`Structure your system into an appropriate number of layers and
`place them on top of each other. Start at the lowest level of
`abstraction-call it Layer 1. This is the base of your system. Work
`your way up the abstraction ladder by putting Layer J on top of Layer
`J -1 until you reach the top level of functionality-<::all it Layer N.
`Note that this does not prescribe the order in which to actually design
`layers, it just gives a conceptual view. It also does not prescribe
`whether an individual Layer J should be a complex subsystem that
`needs further decomposition, or whether it should just translate
`requests from Layer J + 1 to requests to Layer J -1 and make little
`contribution of its own. It is however essential that within an in(cid:173)
`dividual layer all constituent components work at the same level of
`abstraction.
`Most of the services that Layer J provides are composed of services
`provided by Layer J -1. In other words, the services of each layer
`implement a strategy for combining the services of the layer below in
`a meaningful way. In addition, Layer J's services may depend on other
`services in Layer J.
`
`Structure An individual layer can be described by the following CRC card:
`
`Class
`LayerJ
`
`Collaborator
`• LayerJ -1
`
`Responsibility
`• Provides services
`used by Layer J + 1 .
`• Delegates subtasks
`to Layer J -1.
`
`The main structural characteristic of the Layers pattern is that the
`services of Layer J are only used by Layer J + 1-there are no further
`direct dependencies between layers. This structure can be compared
`
`Starbucks Corp. Exhibit 1036
`
`

`

`Layers
`
`35
`
`with a stack, or even an onion. Each individual layer shields all lower
`layers from direct access by higher layers.
`
`Client
`
`Layer N
`
`highest level of abstraction
`
`Layer 1
`
`lowest level of abstraction
`
`Examining individual layers in more detail may reveal that they are
`complex entities consisting of different components. In the following
`figure, each layer consists of three components. In the middle layer
`two components interact. Components in different layers call each
`other directly-other designs shield each layer by incorporating a
`unified interface. In such a design, Componen t_2 . 1 no longer calls
`Component_l.l directly, but calls a Layer 1 interface object that
`forwards the request instead. In the Implementation section, we
`discuss the advantages and disadvantages of direct addressing.
`
`I Component_3.1 I Layer 3
`I
`I
`
`I Component_3.2 I
`
`I
`
`l Component_2.1 I Layer 2
`
`I Component_2.2 l
`
`I Component_3.3 I
`I
`T
`
`I
`
`I
`T
`uses r
`I Component_2.3
`I
`I
`
`I
`
`l Component_!.! I Layer 1
`
`I Component_l.2 l
`
`r Component_l.3 I
`
`Starbucks Corp. Exhibit 1036
`
`

`

`36
`
`Architectural Patterns
`
`Dynamics The following scenartos are archetypes for the dynamic behavior of
`layered applications. This does not mean that you will encounter
`every scenarto in every architecture. In simple layered architectures
`you will only see the first scenario, but most layered applications
`involve Scenartos I and II. Due to space limitations we do not give
`object message sequence charts in this pattern.
`Scenario I is probably the best-known one. A client issues a request
`to Layer N. Since Layer N cannot carry out the request on its own, it
`calls the next Layer N -1 for supporting subtasks. Layer N -1 provides
`these, in the process sending further requests to Layer N -2, and so
`on until Layer 1 is reached. Here, the lowest-level services are finally
`performed. If necessary, replies to the different requests are passed
`back up from Layer 1 to Layer 2, from Layer 2 to Layer 3, and so on
`until the final reply arrives at Layer N. The example code in the
`Implementation section illustrates this.
`A characteristic of such top-down communication is that Layer J
`often translates a single request from Layer J+ 1 into several requests
`to Layer J -1. This is due to the fact that Layer J is on a higher level of
`abstraction than Layer J-1 and has to map a high-level service onto
`more primitive ones.
`Scenario n illustrates bottom-up communication-a chain of actions
`starts at Layer 1, for example when a device driver detects input. The
`driver translates the input into an internal format and reports it to
`Layer 2, which starts interpreting it, and so on. In this way data
`moves up through the layers until it arrives at the highest layer. While
`top-down information and control flow are often described as
`'requests', bottom-up calls can be termed 'notifications'.
`
`As mentioned in Scenarto I, one top-down request often fans out to
`several requests in lower layers. In contrast, several bottom-up noti(cid:173)
`fications may either be condensed into a single notification higher in
`the structure, or remain in a 1: 1 relationship.
`Scenario m describes the situation where requests only travel
`through a subset of the layers. A top-level request may only go to the
`next lower level N -1 if this level can satisfy the request. An example
`of this is where level N -1 acts as a cache, and a request from level N
`can be satisfied without being sent all the way down to Layer 1 and
`from here to a remote server. Note that such caching layers maintain
`
`Starbucks Corp. Exhibit 1036
`
`

`

`Layers
`
`37
`
`state information. while layers that only forward requests are often
`stateless. Stateless layers usually have the advantage of being
`simpler to program. particularly with respect to re-entrancy.
`Scenario IV describes a situation similar to Scenario III. An event is
`detected in Layer 1, but stops at Layer 3 instead of traveling all the
`way up to Layer N. In a communication protocol, for example, are(cid:173)
`send request may arrive from an impatient client who requested data
`some time ago. In the meantime the server has already sent the
`answer. and the answer and the re-send request cross. In this case,
`Layer 3 of the server side may notice this and intercept the re-send
`request without further action.
`Scenario V involves two stacks of N layers communicating with each
`other. This scenario is well-known from communication protocols
`where the stacks are known as 'protocol stacks'. In the following
`diagram. Layer N of the left stack issues a request. The request moves
`down through the layers until it reaches Layer 1, is sent to Layer 1 of
`the right stack. and there moves up through the layers of the right
`stack. The response to the request follows the reverse path until it
`arrives at Layer N of the left stack.
`
`Layer N
`
`For more details about protocol stacks, see the Example Resolved
`section, where we discuss several communication protocol issues
`using TCP/IP as an example.
`
`Starbucks Corp. Exhibit 1036
`
`

`

`38
`
`Architectural Patterns
`
`Implementation The following steps describe a step-wise refinement approach to the
`definition of a layered architecture. This is not necessarily the best
`method for all applications-often a bottom-up or 'yo-yo' approach is
`better. See also the discussion in step 5.
`Not all the following steps are mandatory-it depends on your
`application. For example, the results of several implementation steps
`can be heavily influenced or even strictly prescribed by a standards
`specification that must be followed.
`1 Define the abstraction criterion for grouping tasks into layers. This
`criterion is often the conceptual distance from
`the platform.
`Sometimes you encounter other abstraction paradigms, for example
`the degree of customization for specific domains, or the degree of
`conceptual complexity. For example, a chess game application may
`consist of the following layers, listed from bottom to top:
`• Elementary units of the game, such as a bishop
`• Basic moves, such as castling
`• Medium-term tactics, such as the Sicilian defense
`• Overall game strategies
`In American Football these levels may correspond respectively to
`linebacker, blitz, a sequence of plays for a two-minute drill, and finally
`a full game plan.
`In the real world of software development we often use a mix of
`abstraction criterions. For example, the distance from the hardware
`can shape the lower levels, and conceptual complexity governs the
`higher ones. An example layering obtained using a mixed-mode
`layering principle like this is as follows , ordered from top to bottom:
`• User-visible elements
`
`• Specific application modules
`• Common services level
`• Operating system interface level
`• Operating system (being a layered system itself, or structured
`according to the Microkernel pattern (171))
`
`• Hardware
`
`Starbucks Corp. Exhibit 1036
`
`

`

`2 Determine the number of abstraction levels according to your
`abstraction criterion. Each abstraction level corresponds to one layer
`of the pattern. Sometimes this mapping from abstraction levels to
`layers is not obvious. Think about the trade-offs when deciding
`whether to split particular aspects into two layers or combine them
`into one. Having too many layers may impose unnecessary overhead,
`while too few layers can result in a poor structure.
`3 Name the layers and assign tasks to each of them. The task of the
`highest layer is the overall system task, as perceived by the client. The
`tasks of all other layers are to be helpers to higher layers. If we take
`a bottom-up approach, then lower layers provide an infrastructure on
`which higher layers can build. However, this approach requires con(cid:173)
`siderable experience and foresight in the domain to find the right
`abstractions for the lower layers before being able to define specific
`requests from higher layers.
`4 Specifi.j the services. The most important implementation principle is
`that layers are strictly separated from each other. in the sense that
`no component may spread over more than one layer. Argument,
`return, and error types of functions offered by Layer J should be built(cid:173)
`in types of the programming language, types defined in Layer J. or
`types taken from a shared data definition module. Note that modules
`that are shared between layers relax the principles of strict layering.
`It is often better to locate more services in higher layers than in lower
`layers. This is because developers should not have to learn a large set
`of slightly different low-level primitives-which may even change
`during concurrent development. Instead the base layers should be
`kept 'slim' while higher layers can expand to cover a broader
`spectrum of applicability. This phenomenon is also called the
`'inverted pyramid of reuse'.
`5 Refine the layering. Iterate over steps 1 to 4 . It is usually not possible
`to define an abstraction criterion precisely before thinking about the
`implied layers and their services. Alternatively, it is usually wrong to
`define components and services first and later impose a layered
`structure on them according to their usage relationships. Since such
`a structure does not capture an inherent ordering principle, it is very
`likely that system maintenance will destroy the architecture. For
`example. a new component may ask for the services of more than one
`other layer. violating the principle of strict layering.
`
`Starbucks Corp. Exhibit 1036
`
`

`

`40
`
`Architectural Patterns
`
`The solution is to perform the first four steps several times until a
`natural and stable layering evolves. 'Like almost all other kinds of
`design, finding layers does not proceed in an orderly, logical way, but
`consists of both top-down and bottom-up steps, and certain amount
`of inspiration .. .' [Joh95). Performing both top-down and bottom-up
`steps alternately is often called 'yo-yo' development, mentioned at the
`start of the Implementation section.
`6 Specify an interface for each layer. If Layer J should be a 'black box'
`for Layer J+ 1, design a flat interface that