Levels and Shared Idioms

The patterns included in this book are all derived from pattern-mining, a term coined by the self-described patterns community that surfaced in the last few years among software developers. Pattern-mining is a variation on the original approach taken by Alexander and his colleagues when they created the first set of architectural patterns.

I use patterns to document the successful approaches to working with the UML from the existing literature. The software literature was scoured for repeated examples of good modeling and good uses of models. These examples were evaluated, validated, filtered, factored and refactored, and then documented.

Some patterns are reworked versions of existing patterns; some are first drafts that are based on proven practices or common approaches to solving modeling problems. Some patterns are stronger than others. All of them are open to further evolution.

The pattern language has multiple dimensions and levels. I loosely follow the example set by Alexander. His patterns for building human structures range from the level of the region to that of the components of a house. The subtitle of Alexander's A Pattern Language identifies the three key organizing ideas he uses: towns, buildings, and construction (1977).

I've taken the liberty of adopting and freely adapting three of the key organizing ideas that are becoming important in quality software development: domain, products, and components. These are the levels in our pattern language network; they provide the context for the work of modeling.

For the purposes of this book, a domain is the combination of technical and business constructs and concepts that provides the immediate context for software development. It brings together a high-level business model with a high-level technology architecture. Domain is the highest level of modeling for this pattern language. Domains define the context, scope, and business vocabulary for engineering, modeling, and management. For a software developer, a domain may be a "family of systems" (Jacobson, Griss, and Jonsson 1997, 19), that is, a collection of products; for someone doing business re-engineering, it may be the overall enterprise.

Products are what are planned, managed, and delivered to the end user as a unit. They have a life and a lifecycle that is separate from the development lifecycle, especially now with iterative design and incremental delivery. They are born, introduced, evolved, matured, and theoretically have a sunset. Whether internal to an organization or sold on the open market, products need to managed and modeled beyond the boundaries of a single development project, and they provide the context for each development spurt.

For the purposes of this book, a product goes beyond just the software itself. It is the total package, what Geoffrey Moore, the technology marketing guru, called a "whole product": the supporting services, the documentation, and the ongoing management (1991, 110 35).

As short-cycle development replaces the protracted development style of the mainframe era, products become the ongoing reality of software development, replacing projects as the collective fetish in the management heart of darkness. The UML is especially endowed with artifacts to support the modeling of products.

Components are what is deployed. To start with, they are the executables delivered to the end user on processors and devices. In the UML, they are also the documentation, the source code, the help files, and any other supporting artifact needed to make the executable solution useful and maintainable.

This interpretation straddles the definition gap between everything is a component, with its emphasis on reuse, and components are parts (that is, only binary code a portion of a system). As with products, the pattern language looks not just at all the things that make up a component, but it also covers problems that are not strictly development issues (although they are critical for long-term success).

I don't limit these patterns to the problems faced by a developer. I also include patterns useful to management, to operations, and to the deployment team although they are patterns that an architect and designer should keep in mind because they provide a basis for communication with management.

Some patterns are idiomatic, specifically about making diagrams and creating UML artifacts. Others are more concerned with packaging, making choices about artifacts, and management and organizational considerations that are critical to modeling success.

Most, but not all, of the idiomatic patterns are separated from the pattern language levels described previously. These are the patterns of style and patterns of substance, addressed to any UML modeling effort. For anyone new to modeling or the UML, they provide some basic guidelines for formatting models and using the UML artifacts effectively. Look there for guidance on the best way to set up a diagram or model a particular situation with the UML. They also help explain how to make use of some of the specific features of the UML that differentiate the UML from other modeling languages, past or present. These patterns can be applied at any level of modeling, from the conceptual to the detailed.