Pattern-Oriented Software Architecture, A System of Patterns

Frank Buschmann

Mentioned 10

Pattern - Oriented Software Architecture A System of Patterns Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal of Siemens AG, Germany Pattern-oriented software architecture is a new approach to software development. This book represents the progression and evolution of the pattern approach into a system of patterns capable of describing and documenting large-scale applications. A pattern system provides, on one level, a pool of proven solutions to many recurring design problems. On another it shows how to combine individual patterns into heterogeneous structures and as such it can be used to facilitate a constructive development of software systems. Uniquely, the patterns that are presented in this book span several levels of abstraction, from high-level architectural patterns and medium-level design patterns to low-level idioms. The intention of, and motivation for, this book is to support both novices and experts in software development. Novices will gain from the experience inherent in pattern descriptions and experts will hopefully make use of, add to, extend and modify patterns to tailor them to their own needs. None of the pattern descriptions are cast in stone and, just as they are borne from experience, it is expected that further use will feed in and refine individual patterns and produce an evolving system of patterns. Visit our Web Page

More on

Mentioned in questions and answers.

Can you please suggest some books on Software Architecture, which should talk about how to design software at module level and how those modules will interact. There are numerous books which talks about design patterns which are mostly low level details. I know low level details are also important, but I want list of good design architecture book.

Please also suggest some books which talks about case studies of software architecture.

I think this is the book that came to mind when I first read this question. It talks about various architectural styles like pipes-and-filters, blackboard systems, etc. It's an oldie, and I'll let you judge whether it's a 'goodie'.

Pattern Oriented Software Architecture

I also particularly like these two, especially the first. The second starts to dig into lower level design patterns, but it's still awesome in various spots:

Enterprise Integration Patterns

Patterns of Enterprise Application Architecture

I hope these are what you had in mind.

Where can you get knowledge about software architecture? One place is your experience building systems. Another is conversations with other developers or reading their code. Yet another place is books. I am the author of a book on software architecture (Just Enough Software Architecture) but let me instead point you to some classics:

  • Software Architecture in Practice (Bass, Clements, Kazman). This book from the Software Engineering Institute (SEI) describes how architects should think about problems. It describes the importance of quality attributes (performance, security, modifiability, etc.) and how to make tradeoffs between them, since you cannot maximize all of them.
  • Documenting Software Architectures (lots of SEI/CMU authors). The title of this book is a bit scary, because many people are trying to avoid writing shelfware documents. But the wonderful thing about the book is that it describes the standard architectural styles / patterns, notations for describing structure and behavior, and a conceptual model of understanding architectures. All these are valuable even if you only ever sketch on a whiteboard.
  • Software Systems Architecture (Rosanski and Woods). Goes into detail about how to think about a system from multiple perspectives (views). What I like particularly is that it gives checklists for ensuring that a particular concern (say security) has been handled.
  • Essential Software Architecture (Gorton). Small, straightforward book on IT architecture. Covers the different kinds of things you'll see (databases, event busses, app servers, etc.)

That's just a short list and just because I didn't list something doesn't mean it's a bad book. If you are looking something free to read immediately, I have three chapters of my book available for download on my website.

This is entirely a best practices type question, so the language is irrelevant. I understand the basic principles of MVC, and that there are different, subtle flavors of it (i.e. views having a direct reference to models vs. a data delegate off the controller).

My question is around cross MVC communication, when those MVCs are nested. An example of this would be a drawing program (like Paint or something). The Canvas itself could be an MVC, but so could each drawn entity (e.g. Shapes, Text). From a model perspective, it makes sense for the CanvasModel to have a collection of entities, but should the CanvasView and CanvasController have corresponding collections of entity views and controllers respectively?

Also, what's the best/cleanest way to add a new drawn entity? Say the user has the CircleTool active, they click in the Canvas view and start drawing the shape. The CanvasView could fire relevant mouse down/move/up events that the CanvasController could listen to. The controller could then basically proxy those events to the CircleTool (state pattern). On mouse down, the CircleTool would want to create a new Circle. Should the Tool create a new CircleEntityController outright and call something like canvasController.addEntity(circleController)? Where should the responsibility of creating the Circle's model and view then lie?

Sorry if these questions are somewhat nebulous :)


Here's a pseudo-codish example of what I'm talking about:

CircleTool {
    onCanvasMouseDown: function(x, y) {
        // should this tool/service create the new entity's model, view, and controller?
        var model = new CircleModel(x, y);
        var view = new CircleView(model);
        var controller = new CircleController(model, view);

        // should the canvasController's add method take in all 3 components
        // and then add them to their respective endpoints?
        this.canvasController.addEntity(model, view, controller);

CanvasController {
    addEntity: function(model, view, controller) {
        // this doesn't really feel right...

If I were you I would opt for Composite pattern when working with shapes. Regardless of whether you have circles, squares, rectangles, triangles, letters, etc, I would treat everything as a shape. Some shapes can be simple shapes like lines, other shapes can be more complex composite shapes like graphs, pie charts, etc. A good idea would be to define a base class that has a reference to basic shapes and to advanced (complex) shapes. Both basic shapes and advanced shapes are the same type of object, its just that advanced shapes can have children that help define this complex object.

By following this logic, you can use the logic where each shape draws itself and each shape knows its location, and based on that you would apply certain logic and algorithm to ask which shape was clicked and each shape could respond to your event.

According to the GoF book:


Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.


Graphics applications like drawing editors and schematic capture systems let users build complex diagrams out of simple components. The user can group components to form larger components. [...]

The key to composite pattern is an abstract class that represents both primitives and their containers. For the graphics system, this class is Graphics. Graphic declares operations like Draw that are specific to graphical objects. It also declares operations that all composite objects share, such as operations for accessing and managing its children.

Now, back to your problem. One of the base functions, as previously mentioned, is a Draw method. This method could be implemented as an abstract method in the base class with a following signature:

public virtual void Draw(YourDrawingCanvas canvas);

Each shape would implement it's own version of Draw. The argument that you pass them is a reference to the drawing canvas where each shape will draw itself. Each shape could store a reference of itself in its internal structure and it can be used to compare mouse click location with these coordinates to inform you which shape was clicked.

Wow, well I have perhaps a surprising answer to this question: I have a long-standing rant about how MVC is considered this beatific symbol of perfection in programming that no one sees any issues with. A favorite interview question is 'what are some problems, or challenges that you might encounter in MVC?' It's amazing how often the question is greeted with a puzzled, queasy look.

The answer is really quite simple: MVC relies on the notion of multiple consumers having their needs met from a single shared model object. Things really start to go to hell when the various views make different demands. There was an article a few years ago where the authors advanced the notion of Hierarchical MVC. Someone else came on in the comments and told them that what they thought they were inventing already existed: a pattern called Presentation-Abstraction-Controller (PAC). Probably the only place you see this in the pattern literature is in the Buschmann book, sometimes referred to as the Gang of Five, or POSA (Pattern-Oriented Software Architecture). Interestingly, whenever I explain PAC, I use a paint program as the perfect example.

The main difference is that in PAC, the presentation elements tend to have their own models, that's the A of the PAC: for each component, you don't have to, but can have an abstraction. Per some of the other responses here, then what happens is you have a coordinating controller, in this case, that would rule over the canvas. Let's say we want to add a small view to the side of the canvas that shows the count of various shapes (e.g. Squares 3, Circles 5, etc.). That controller would register with the coordinating controller to listen on a two events: elementAdded and elementRemoved. As it received each notification, it would simply update a map it had in its own Abstraction. Imagine how absurd it would be to alter a shared model that a bunch of components are using to add support for such a thing. Furthermore, the person who did the ShapesSummary component didn't have to learn about anything, but the event protocols, and of course all its interactions with collaborators are immutable.

The hierarchical part is that there can be layers of controllers in PAC: for instance, the coordinating one at the Canvas level would not know about any of the various components with specialized behaviors. We might make a shape that can contain other things, which would need logic for accepting drags, etc. That component would have its own Abstraction and Controller, and that Controller would coordinate its activities with the CanvasController, etc. It might even become necessary at some point for it to communicate with its contained components.

Here's the POSA Book.

Can anyone point to any websites or web applications that are using the Presentation-Abstraction-Control design pattern rather than MVC? Desktop applications are easy to find like this (e.g.; GIMP) but I'm looking for something on the web.

Can you please educate me on what are the software architecture design patterns that are available?

To elaborate my question, I want to read through different architecture design patterns and decide what suits my project requirements?

For example, there are Enterprise application design patterns, Enterprise Integration design patterns, ESB patterns, SOA patterns etc..

Thank you for your help.

Regards Sandeep

Patterns occur at many levels. Architecture patterns (i.e., architectural styles) are generally the largest in scope and cover the fundamental organization of the system. Design patterns are at the level of several collaborating objects. Bernd's suggestion of Fowler's and other enterprise patterns is a good one. Just recognize that those patterns tend to be more specific than these architectural patterns:

  • Layered (i.e., virtual machine pattern)
  • Big Ball of Mud
  • Pipe and Filter
  • Batch-Sequential
  • Model-Centered (Shared Data)
  • Publish-Subscribe
  • Client-Server (and N-Tier)
  • Peer-to-peer
  • MapReduce

Architecture patterns most often apply to the runtime structure of the system, but can also apply to its modules or its hardware allocation. One common mistake is to think that the Layered pattern applies to the runtime when it really applies to a system's modules (i.e., its compile-time dependencies). You can, of course, mirror your module structure in the runtime

These patterns are discussed in detail in my book, Just Enough Software Architecture, Fairbanks (2010). Most of them are also covered in other books including Garlan & Shaw (1996), Taylor, Medvidovic, & Dashovy (2009), and Documenting Software Architectures (SEI, 2010).

With the list of pattern names, you should be able to find plenty of web pages (I've marked this as a community Wiki so that we can add those links). The books are helpful too because they give you more insight on how to use the patterns.

For architectural patterns, read Pattern-Oriented Software Architecture Volume 1: A System of Patterns. patterns discussed are:

  • Layers
  • Pipes & Filters
  • Blackboard
  • Broker
  • Model-View-Controller (MVC)
  • Presentation-Abstraction-Control (Hierarchical MVC)
  • Microkernel
  • Reflection

As a new grad attending interviews, I feel that the sections I do the worst are in system design questions like How will you design a search engine? Or How do you support google like instant responses

I make answers and it sounds convincing to me, but I feel I can do better by studying such systems themselves to get an understanding of the problems that arise and needs to be solved. Can the community point me to resources (blogs, online classes, text books, white papers, academic publications anything.,) to help me along this task?

Some articles and books about architecture:

And of course the regular design pattern books.

I am learning C++ I don't know much about this stuff except the fact that programming design pattern is neccesary when actually working in large projects.I hope its correct to some extent.

Is this common to all object oriented languages or do I need to look specifically into C++ design patterns.

Also How does it helps you.Is this realy important to learn as a C++ programmer.

Please suggest

You will hear discording opinions about design patterns, in the programming community at large.

In my opinion, it is sure that there are abstractions that patterns encapsulate that are really useful (factory, singleton, delegate, etc.). I use patterns a lot, but I myself am sometime puzzled by the apparent lack of depth or level of insight that you get by reading a pattern description. This is also in tune with the proliferation of design patterns that specialize for any kind of things.

When the design hey are useful, they are a very good means of communication and certainly they guide you through the process of designing or defining the architecture of your app. They are useful both for small project and for large ones, and they can be applied at different granularity levels.

Patters are a generic concept and all programming languages support them. Anyway, if you work in C++, a book focusing on it is best, because you will get the pattern adapted to the characteristics of the language.

In my opinion, the really fundamental book about design patterns are:

GoF, Design Patterns: Elements of Reusable Object-Oriented Software

VV.AA., Pattern-Oriented Software Architecture Volume 1: A System of Patterns

VV.AA., Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects

Design patterns are solutions to commonly occuring problems in Design phase of a project.These patterns provide the solutions which we can use independent of programming language.For e.g. there is Singleton design pattern which ensures that there is only one instance of a class.Now there are numerous occaions on which this may be required.You can use the solution of these pattern and use in your code.

They provide the re usability in Software development .Put simply, design patterns help a designer get a design right faster.

For more better understanding you could refer Design Patterns: Elements of Reusable Object-Oriented Software

I am reading a book on design patterns (an old edition) "Pattern-oriented software architecture". In the chapter dedicated to Client-Dispatcher-Server, SunRPC is cited as a Client-Dispatcher-Server architecture, with portmapper acting as Dispatcher in the Client-Server negotiation. I never used SunRPC practically, although I know more or less how it works.

I have three questions:

  • What are the software limitations (in terms of interfaces and features) of SunRPC as a Client-Dispatcher-Server mechanism ?
  • What are similar better systems today to achieve the same Client-Dispatcher-Server architecture (regardless of language) ?
  • What are the intrinsic differences between a Broker architecture and a Client-Dispatcher-Server architecture ?

I do realize the questions are many and complex. I considered splitting into independent questions, but the point of this submission is about general architecture principles and limitations, with a specific example (SunRPC) as a typical case. Due to these considerations I preemptively announce that I will put a 100 rep bounty as soon as I have the chance, regardless of my level of satisfaction with answers during the grace period.

This terminology is unusual (to me at least), maybe that's the reason why you aren't getting many responses. Judging by the diagram on page 327, client-dispatcher-server means that a redirection to the real server occurs at connection time, while broker interposes in the whole communication (page 109)? Assuming that, modern-day terms would be "redirect" (or "name service" or "directory service" etc), and "proxy", respectively. The main difference is a trade-off between latency and availability, ie brokers are in a position to patch things up when a server dies, which dispatchers aren't; but brokers add a modicum of processing time to the pipeline.

Modern-day instances of both patterns can be found on high-volume Web sites: they will typically employ a round-robin or more sophisticated load-balancing DNS service (the dispatcher) as well as caching reverse proxies (brokers).

I don't know much about SunRPC and its limitations, and I have no idea if it can possibly be used in a round-robin kind of way (searching Google for "portmap load balancing" turns up nothing FWIW). An entry in the portmapper's table will typically point to a single server running on the same host, ie mostly this mechanism serves to avoid allocating well-known TCP ports to SunRPC services.

I had to clean up code for an online college application. There's nothing particularly wrong with it, but it was complicated. Different degree programs had different prequisites, fees, required documentation, and questions. On top of that, students coming from the military get different fees, and previous students pay no fees and skip steps.

Obviously all this logic can get pretty complex - and cause bugs. I'm wondering if there's a design pattern or coding method that would help with organizing the logic. I'm using PHP, not that it matters.

The strategy pattern seems to have the most potential, but it seems to me I'd need strategies on top of strategies for this.

I imagine the field of "Business Logic" might cover this at least partially, but searches haven't turned up indications of any elegant coding methods to use.

I think a combination of patterns would be helpful. Fowler's Domain Model pattern aims to tame complex domain logic. Using a Layered architectural pattern is another option, as described in POSA1. Strategy pattern also seems to be a good idea for defining a family of related algorithms.

I need to extend a class (in C++, but this question is language-agnostic I think), with functionality that can be implemented in two different ways:

  • by simply adding the logic to the class itself
  • by adding observer logic to the class and putting the logic in an observer, outside the class

There are advantages and disadvantages in both alternatives:

  • since the code might be used for other classes as well, it seems more logical to add the logic in an observer. Future classes then only need to support observers.
  • on the other hand, the impact of observers in calculation-intensive code is hard to foresee. New observers added later in the code, might have a negative impact in the calculation-intensive code.

Has anyone clear rules on when to add new functionality within the class, as opposed to putting it in an observer outside the class?

A popular way to extend functionality is the Extension Interface pattern, as described in POSA1.

Another pattern you might consider is the Proxy pattern. If the logic is discrete, you can chain proxy objects to each other and solely refer to them through an interface. This should allow you to spread the logic out nicely over several independent and interchangeable objects.

It's kind of hard for me to give more advice on the design, given that I don't know a whole lot about your situation. But I hope this helps.

is there any new design patterns available other than the patterns covered by GoF book and Head First Design Patterns? Have any one of you used your own design patterns in your projects? Please let me know. if possible give some UML Diagrams. Thanks in advance.

The "sequel" to the GoF book is Pattern Hatching by John Vlissides. It does not publish really new patterns, but variations of some included in the original GoF book. Its great value is rather in that it shows the thought and design process involved in applying the patterns.

Although this is not an answer to your question in the strict sense, there are also lots of other kinds of patterns relevant to our field: