1.3 Interpreting the Patterns in This Book

The way I formatted the two previous example patterns, which I squeezed out of the idea of Seven Plus or Minus Two, is a version of the way Alexander formats and writes patterns. However, the software developers who first popularized patterns didn't adopt his format. They opted for a form that was more formal and more precisely attuned to what they were trying to accomplish. The book, Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma and others helped to popularize their format as well as patterns for software (1995). For simplicity, I'll call the format GammaForm after one of the book's authors and the originator of this type of pattern.

Since the publication of Design Patterns, Jim Coplien (another patterns guru and object-oriented expert) has become the most visible spokesperson for a looser format, which I'll call CoplienForm (1995). Although more extended than a minimal format would be, it is still succinct; the results tend to be less verbose and less didactic than GammaForm patterns. Many software patterns follow some version of this generic format or the GammaForm format.

An extended explanation of the GammaForm format can be found in Chapter 9. My pattern language uses a slight modification of CoplienForm. Here's how Seven Plus or Minus Two (one of the example patterns above) would look expressed this way. I've included this pattern in the body of the language. An explanation of the pattern's sections follows the pattern.

Seven Plus or Minus Two (formalized)

NAME	Seven Plus or Minus Two
PROBLEM	How to make diagrams that can be grasped easily.
CONTEXT	Building diagrams that are themselves part of an overall model. In this case, we are specifically concerned with software models, but the pattern could apply to any type of potentially complex model using standardized modeling elements and syntax.
FORCES	Models are made up of diagrams. Diagrams have to communicate usefulviews of the real world. A model must be comprehensive but focused. The real world can be complex, messy, and unfocused. Diagrams are not inherently limited in the number of elements they can contain. Human understanding of diagrams is constrained by the limits of human cognitive capabilities, such as short-term memory.
SOLUTION	Limit the number of elements in any given diagram to the magic number of seven, give or take two elements. These elements should be logically related; the diagram structure should express a sensible pattern connecting the diagram elements.
RESULTING CONTEXT	Diagrams that are easy to understand at a glance and can be organized in a logical fashion into more complex models.
DISCUSSION	Humans have limited cognitive resources. That is, they can only attend to so many things and perform a limited amount of activities at once. Too many elements in adiagram can be confusing and are hard to retain in short term memory all at once. This pattern provides a simple way of ensuring that the number of elements is reasonable for most people. The related pattern, Chunking, explains how and why the process of decomposing a model into logical diagrams works.

1.3.1 This Book's Pattern Format

Coplien suggests that the name for a pattern should be chosen with as much care as the name for a first born child. Pattern names should be succinct, memorable, and relevant. Naturally, this is much more difficult to do than to say. At the very least, I've tried to make the names of the patterns in this book expressive of their possible usage.

The problem is the easiest statement of what the pattern is a response to, providing the potential user with a quick way of assessing the usefulness of the pattern. (Remember that the kind of problems this language deals with are those connected with modeling, using models, or managing models.)

The context provides more help in determining the applicability of a pattern. It situates the pattern, providing information about where the results might fit into a typical UML-based development effort.

Forces are where any remaining uncertainties about the applicability of a pattern may be resolved. I've tried to be explicit about the conditions, constraints, and considerations that the pattern tries to resolve.

The solution is a straightforward explanation of how a modeler using the UML would solve the modeling problem that the problem, context, and forces present. It leads to the resulting context, summarizing the effects of applying the pattern, and it is explained in more detail in the discussion, which may also provide additional pattern and/or literature references.

Where appropriate, example diagrams will be provided to clarify a pattern. However, in the same way that the UML is not only about diagrams, some UML patterns do not lend themselves to diagram examples.

This format is meant to be useful with a minimum of overhead. As with the UML, which the next chapter introduces, it (and the patterns in this book) is a convenient compromise between the theoretical and the practical.