The road to UML
- By Ivar Jacobson, Grady Booch, James Rumbaugh
- June 11, 2001
All well-structured systems are full of patterns. A pattern provides
a common solution to a common problem in a given context. A mechanism is a design pattern that applies to a society
of classes; a framework is typically an architectural pattern that provides an extensible template for applications
within a domain.
You use patterns to specify mechanisms and frameworks that shape the architecture of your system. You make a
pattern approachable by clearly identifying the slots, tabs, knobs, and dials that a user of that pattern may adjust
in order to apply the pattern in a particular context.
It's amazing to think of the various ways you can assemble a pile of lumber to build a house. In the hands of
a master builder in San Francisco, you might see that pile transformed into a Victorian-style house, complete with
a gabled roof line and brightly colored, storybook siding. In the hands of a master builder in Maine, you might
see that same pile transformed into saltbox house, with clapboard siding and rectangular shapes throughout.
From the outside, these two houses represent clearly different architectural styles. Every builder, drawing
from experience, must choose a style that best meets the needs of his or her customer, and then adapt that style
to the customer's wishes and the constraints of the building site and local covenants.
For the inside, each builder must also design the house to solve some common problems. There are only so many
proven ways to engineer trusses to support a roof; there are only so many proven ways to design a load-bearing
wall that must also handle openings for doors and windows. Every builder must select the appropriate mechanisms
that solve these common problems, adapted to an overall architectural style and the constraints of local building
Building a software-intensive system is just like that. Every time you raise your eyes above individual lines
of code, you'll find common mechanisms that shape the way you organize your classes and other abstractions. For
example, in an event-driven system, using the chain of responsibility design pattern is a common way to organize
event handlers. Raise your eyes above the level of these mechanisms, and you'll find common frameworks that shape
your system's entire architecture. For example, in information systems, using a three-tier architecture is a common
way to achieve a clear separation of concerns among the system's user interface, its persistent information, and
its business objects and rules.
In the UML, you will typically model design patterns -- also called mechanisms --which you can represent as
collaborations. Similarly, you will typically model architectural patterns as frameworks, which you can represent
as stereotyped packages.
The UML provides a graphical representation for both kinds of patterns.
Dr. Ivar Jacobson is a thought leader in the software world. He has written several influential books about components and component architecture, use cases, modern business engineering, UML and RUP.