Chapter 2. The Unified Modeling Language

Before we dive into the design patterns themselves, it's worth stepping back and thinking about the framework they fit into. Design patterns are just one part of the much broader discipline of software engineering. Building any application involves requirements gathering, design, implementation, testing, and deployment. While design patterns provide developers with a library of proven techniques and allow teammates to apply labels to concepts, the patterns don't begin to address every aspect of enterprise development. Most importantly, perhaps, design patterns can't tell you where to apply a design pattern. That's why we have design.

Design patterns describe the implementation strategies for particular areas of the application, and even the overall design. Enterprise applications in particular need effective engineering practices, given their complexity and business importance. As object-oriented languages take hold in business environments, a need has emerged for a common language to discuss and describe object-oriented software, as well as the problems and business processes the software serves.

Software and process-modeling languages were created to meet this need for common vocabulary to describe software structure. The various leading modeling languages have blended together over the last few years into the Unified Modeling Language, generally abbreviated as the UML.^[1]

^[1] Since UML is an acronym, convention is to use the acronym as you would use the full phrase. Hence "the UML" rather than simply "UML" in much literature.

UML supports all aspects of the software development life cycle, from requirements gathering to design to deployment. In particular, the UML can be extremely helpful in documenting the object structure underlying an application, known as the domain model; but UML models can represent use cases, class structures, program interactions, process flows, physical deployments, packages, and more. Often, simply creating UML diagrams uncovers subtle flaws in system design, saving huge quantities of effort later on in a project. For our immediate purposes in this book, the UML also provides an excellent way to describe design patterns, both in terms of class structures and program processes.

Thorough requirements gathering, design, and documentation are part of the overall pattern of effective enterprise development, and an understanding of UML is necessary in order to follow the current literature on both enterprise design patterns and best practices. We're not going to cover all of the UML in this chapter. The UML is a language in and of itself, and so far nobody has managed to write a comprehensive treatment that's less than 150 pages. However, we are going to attempt a relatively encompassing fly-over of the main features of the UML.

If you've ever used UML in real life, you can probably skip this chapter, although you might find the first few sections helpful. If your previous exposure to UML is minimal, make sure you at least read the sections on use cases, class diagrams, and interaction diagrams. Each section builds on the one before. For a longer (but still high-level) overview of the UML, check out UML Distilled, Second Edition, by Martin Fowler and Kendall Scott (Addison-Wesley), as well as the UML User's Guide and UML Reference Manual, both by Grady Booch, James Rumbaugh, and Ivar Jacobson, the creators of UML (also published by Addison-Wesley).