Chapter 3. UML Essentials, Elements, and Artifacts

There aren't enough symbols to cover all the subtly different things we want to say.

Desmond D'Souza and Alan Wills (1998, 371)

This chapter provides you with a high-level summary of the main elements and artifacts of the UML enough to get started with the pattern language.

Obviously, a single chapter is scarcely adequate to even begin the exercise of learning about the UML. But there are many good books out there that can provide an introductory service for those not already using the UML, and this book isn't meant to cover their territory. Anyone with a working knowledge of the UML can skim this chapter with the proviso that it provides information based on the 1.3 beta version of the UML Specification(Rational Software Corporation 1999), and so it may be useful as an update.

Also, I take a somewhat different approach than is typical for introductions. One difference is that this chapter, like this book and the UML itself, is process-independent. And, where it's important to illustrate anomalies and differences that come from the different ways that processes can interpret the UML, I use Rational's Unified Process and Desmond D'Souza and Alan Wills' book, Objects, Components and Frameworks with UML: The Catalysis Approach (1998) as examples of almost orthogonal processes. I've tried to distinguish between process-specific uses and notations and those that are "vanilla" UML. Where there are notable anomalies, I draw attention to them.

The other way that this chapter is different is that I focus on the packaging and notational side of the UML rather than the detailed semantics of the UML constructs. I do this for two reasons:

The packaging, organizing, and drawing side of the UML seems to be underrepresented in the literature. How to go about making a model has taken a back seat to using the UML in creating development artifacts a subtle but significant difference.
For a book like this, which is aimed at modeling rather than programming, understanding packaging and notation is crucial to using the UML effectively as a tool, just as knowing the syntax is crucial to using a programming language effectively. This chapter aims to clarify what has been a notable amount of confusion in this area, in writings about the UML.

For the most part, the semantics of the UML are sufficiently object-oriented to present little difficulty to anyone with a programming background in any of the object-oriented languages. Of course, some aspects of the UML semantics that are specific to modeling or that are idiomatic to the UML need to be explained, and I'll cover these as well.

Like patterns, a summary such as this one doesn't benefit from inspired originality or novel insights. So, I relied on tried-and-true sources, and I reworked existing material, rather than providing a new way of looking at the innards of the UML. The description that follows is primarily drawn from the UML Specification, Version 1.3(Rational Software Corporation 1999), fleshed out by readings from UML Distilled: Applying the Standard Object Modeling Language (Fowler, Scott, and Jacobson 1997) and Objects, Components and Frameworks with UML: The Catalysis Approach (D'Souza and Wills 1998).