Pattern-Oriented Software Architecture, A System of Patterns

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal

• Publisher: Wiley
• Year: 2013
• ISBN:
  9781118725269
• Edition: 1
• Topic: Computer Science
• Subtopic: Object Oriented Programming
• Index: Computer Science

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 http://www.wiley.com/compbooks/

Chapter 1
Patterns

…Somewhere in the deeply remote past it seriously traumatized a small random group of atoms drifting through the empty sterility of space and made them cling together in the most extraordinarily unlikely patterns. These patterns quickly learnt to copy themselves (this was part of what was so extraordinary about the patterns) and went on to cause massive trouble on every planet they drifted on to. That was how life began in the Universe …

Douglas Adams, The Hitchhiker’s Guide to the Galaxy

Patterns help you build on the collective experience of skilled software engineers. They capture existing, well-proven experience in software development and help to promote good design practise. Every pattern deals with a specific, recurring problem in the design or implementation of a software system. Patterns can be used to construct software architectures with specific properties.

In this chapter we give an in-depth explanation of what patterns for software architecture are, and how they help you build software.

1.1 What is a Pattern?

When experts work on a particular problem, it is unusual for them to tackle it by inventing a new solution that is completely distinct from existing ones. They often recall a similar problem they have already solved, and reuse the essence of its solution to solve the new problem. This kind of ‘expert behavior’, the thinking in problem-solution pairs, is common to many different domains, such as architecture [Ale79], economics [Etz64] and software engineering [BJ94]. It is a natural way of coping with any kind of problem or social interaction [NS72].

Here is an elegant and intuitive example of such a problem-solution pair, taken from architecture:

Example

Window Place [AIS77]:

Everybody loves window seats, bay windows, and big windows with low sills and comfortable chairs drawn up to them…A room which does not have a place like this seldom allows you to feel comfortable or perfectly at ease…

If the room contains no window which is a “place”, a person in the room will be torn between two forces:

1. He wants to sit down and be comfortable.
2. He is drawn toward the light.

Obviously, if the comfortable places—those places in the room where you most want to sit—are away from the windows, there is no way of overcoming this conflict…

Therefore: In every room where you spend any length of time during the day, make at least one window into a “window place”

Abstracting from specific problem-solution pairs and distilling out common factors leads to patterns: These problem-solution pairs tend to fall into families of similar problems and solutions with each family exhibiting a pattern in both the problems and the solutions’ [Joh94]. In his book The Timeless Way of Building [Ale79] (p. 247), the architect Christopher Alexander defines the term pattern as follows:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.

As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing.

We also find many patterns in software architecture. Experts in software engineering know these patterns from practical experience and follow them in developing applications with specific properties. They use them to solve design problems both effectively and elegantly. Before discussing this in detail, let us look at a well-known example:

Example

Model-View-Controller (125)

Consider this pattern when developing software with a human-computer interface.

User interfaces are prone to change requests. For example, when extending the functionality of an application, menus have to be modified to access new functions, and user interfaces may have to be adapted for specific customers. A system may often have to be ported to another platform with a different ‘look and feel’ standard. Even upgrading to a new release of your window system can imply changes to your code. To summarize, the user interface of a long-lived system is a moving target.

Building a system with the required flexibility will be expensive and error-prone if the user interface is tightly interwoven with the functional core. This can result in the development and maintenance of several substantially different software systems, one for each user interface implementation. Ensuing changes then spread over many modules. In summary, when developing such an interactive software system, you have to consider two aspects:

• Changes to the user interface should be easy, and possible at run-time.
• Adapting or porting the user interface should not impact code in the functional core of the application.

To solve the problem, divide an interactive application into three areas: processing, output and input:

• The model component encapsulates core data and functionality. The model is independent of specific output representations or input behavior.
• View components display information to the user. A view obtains the data it displays from the model. There can be multiple views of the model.
• Each view has an associated controller component. Controllers receive input, usually as events that denote mouse movement, activation of mouse buttons or keyboard input. Events are translated to service requests, which are sent either to the model or to the view. The user interacts with the system solely via controllers.

The separation of the model from the view and controller components allows multiple views of the same model. If the user changes the model via the controller of one view, all other views dependent on this data should reflect the change. To achieve this, the model notifies all views whenever its data changes. The views in turn retrieve new data from the model and update their displayed information.

This solution allows you to change a subsystem of the application without causing major effects to other subsystems. For example, you can change from a non-graphical to a graphical user interface without modifying the model subsystem. You can also add support for a new input device without affecting information display or the functional core. All versions of the software can operate on the same model subsystem independently of specific ‘look and feel’.

The following OMT class diagram¹ illustrates this solution:

We can derive several properties of patterns for software architecture from this introductory example²:

A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it. In our example here the problem is supporting variability in user interfaces. This problem may arise when developing software systems with human-computer interaction. You can solve this problem by a strict separation of responsibilities: the core functionality of the application is separated from its user interface.

Patterns document existing, well-proven design experience. They are not invented or created artificially. Rather they ‘distill and provide a mea...