Patterns and the UML

At their simplest, patterns are structured, packaged problem solutions in literary form.

Patterns are a new literary form, the first to originate from the software community. As you will see, this form has its roots in architecture especially in the work of Christopher Alexander, a visionary architect who first achieved prominence for his work on architectural design in the 1970s. In systems development, the idea of patterns is very much a "bastard stepchild" appropriated by software developers in response to communication frustrations and to the need for a medium that goes beyond objects as a way of organizing the complex thinking behind design.

Pattern languages are collections of related patterns that have a common domain. They have many advantages over methodologies and courses for explaining how to go about modeling software today. They are descriptive, not prescriptive (the bane of methodologies). Although they capture experience, pattern languages are not didactic nor the expression of a single perspective. They are loose and open-ended.

At their best, patterns enhance creativity. At their worst, they allow for interpretation, and thus support agility and grace in decision-making. They facilitate structured learning through links that are "hypertextual" and dynamic, not sequential. The learning they support is better suited to the "just in time" approach that many find more sensible for software work than traditional training.

The domain for the pattern language in this book is system modeling software-intensive system modeling, as the UML puts it. Although patterns are becoming the conceptual lingua franca of the software world, this book focuses not on patterns per se, but rather on the emerging operational lingua franca of the shop floor: the UML.

The UML is as revolutionary in its way as patterns, and not as just another modeling facility. Its importance for the software practitioner is as much a result of its role and how it evolved as it is a result of what it provides.

Up until recently, software modeling has been a Balkanized domain, in which the intellectual and practical cost of entry was determined by proprietary and often conflicting standards. Tools and training were expensive, and a typical software developer had to gain useful experience doing work on big projects for big organizations.

This cost of entry was affordable for big organizations focused on internal standardization. They paid because it was in their interest to use standardized models internally. These models helped to establish a common corporate picture of their information technology assets, both for control and planning. The results of modeling were, frequently, of questionable value to users and of limited utility for programmers.

Then, client/server, a variety of new programming languages, and finally the Internet entered the picture. The old ways of modeling structured modeling and information engineering, for example ceased to be relevant. They were aimed at building internal, self-contained operational systems residing on mainframes in one form or another the so-called monolithic or stovepipe systems in a relatively homogeneous computing environment. They didn't scale up well to a more complex world of dynamic interactions between organizations and interactions with customers, suppliers, competitors, and partners.

Meanwhile, the new environment of objects and components was immature. It had captured most of the elusive "mindshare," (the intellectual equivalent of market share) among software developers that so often determines what happens next in information technology. Development approaches that made models a critical element in the development process were being seen as essential if object technology was to mature. But object modeling was as much of a dog's breakfast as mainstream modeling.

The UML emerged from this combination of opportunity and need. Unlike previous efforts to define a toolset for software modeling, the UML has been a group effort. So, it has escaped the dead end of being proprietary. It is intentionally built to evolve and respond to new needs as they emerge. These differences reflect the different landscape that software modeling has to fit into today and that the UML serves.

The notion of model-driven development has taken hold for all sizes and types of software projects. Iterative, incremental development that is planned with the help of models is replacing the all-at-once crapshoot of mainframe style development. The availability of inexpensive personal productivity software has nurtured expectations among developers for development tools that are personally affordable. The mantra of reuse has encouraged the notion of sharable solutions, which is documented in models and implemented in components. The Iron Curtains and Berlin Walls around organizations are being replaced by firewalls with interfaces, responsibilities, and collaborations that need to be modeled.

Modeling is now at center stage, and the UML is perhaps the lever that is needed to move the world. It provides the starting point for inexpensive tools, shareable models, and a manageable development process. It has been shaped or embraced by all the significant players in the systems industry.

And with a focus on modeling using the UML, I specifically chose patterns as media because they fit the dynamic landscape of software development in the same way as the UML. The two are complementary, not orthogonal, artifacts of the same culture.

Patterns compress experience, whereas models filter and abstract relationships and conceptual structures. Patterns are literary; models are architectural. Both are ways of managing complexity. Both emerged out of a volatile consensus that reflects a bigger tendency away from the proprietary and the closed, and toward the standard and the open. Both reflect the success of a philosophy of piecemeal growth, team-based development, and what might be called permeable organizations: organizations without walls.