Using This Book

The core of this book is Part II, "The Pattern Language." This is a language for building, planning, and using models of software-intensive systems. The rest of the book can be considered the theory and instructions for using the language, or for using it more efficiently. There's no need to read the book or major parts of it sequentially. The route you take should depend on what you need.

Those unfamiliar with patterns should at least read Chapter 1, "Pattern Essentials," which is an introduction to patterns. Those unfamiliar with the UML should read Chapter 2, "The Unified Modeling Language," which is an introduction to the UML, and Chapter 3, "UML Essentials, Elements, and Artifacts," which is an overview of the elements and artifacts of the UML from a modeling perspective.

Following the pattern language is Part III, "Another Starting Point." These chapters provide context and enrich the use of both the UML in particular and patterns in general. They are meant to be glosses for the main body of the book, the pattern language itself. They are both introductory and extensive providing links to other works. They can provide a starting point for exploring both patterns and the UML further.

Neither the UML nor patterns are fixed or simple. In order to make maximum use of either, move from being a user to a practitioner and eventually become professional, a lot of further work is required beyond what I offer here.

The UML received a great deal of attention as it formed and is a natural extension of previous efforts to define a modeling language. As a result, not only is the important information needed to become a serious practitioner readily available, but most of the skills needed will be extensions of existing skills for anyone with modeling experience.

In the case of patterns, there's history and background to get acquainted with as well because patterns are much more than just a form. They are also very different from anything most developers will be familiar with. Also, patterns have not been well documented for the beginning user. Very little outside attention was paid to them as they emerged, and the background material critical to working with and using patterns effectively is skimpy at best. For anyone getting involved with patterns now, the results can be confusing even frustrating.

Therefore, I dwell a bit more on patterns and provide otherwise unavailable information in the hopes that those readers looking to move beyond the limited scope of the pattern language will be armored effectively to deal with the pattern's labyrinth itself.

Because it is not a simple topic, the background to the pattern format I use is discussed in detail in Chapter 1. However, for the user of this book, the critical parts of each pattern that will help determine the applicability of a pattern and its potential as a starting point are the context and problem statements. These parts should be looked at first and looked at together. Applicability can be further refined by reading the forces statement, which details the pressures, tendencies, needs, and constraints that the solution needs to resolve.

A number of patterns within a chapter will have overlapping contexts and/ or forces. Neither is meant to be necessarily unique for each pattern. There may be related patterns to look at, especially among the patterns of usage. The pattern names are intended to be meaningful and may also provide a hook when scanning for one that is useful. And because the patterns are meant to be the basis for creative solutions, some patterns that do not specifically fit the context and forces at hand may be worth considering.