2.3 Understanding the UML

According to the UML Specification, the UML is a language

for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. (Object Management Group 1999, xi)

This official description, which appears right at the beginning of both the Preface and the Summary of the UML Specification document, emphasizes a couple of key qualities that a prospective user of the UML has to keep in mind.

First of all, it is confusing. The intended reading of this definition is that artifacts really refers to modeling artifacts, and that the UML is about modeling and building models; it is not about constructing code, project management, or production support. But appropriating the term constructing this way and abusing the term artifacts provide little mental hiccups instead of a strong declaration. The official prose of the UML frequently has a committee-built quality (sometimes resulting in unclear intentions and inconsistent interpretations). For example, more than one book on the UML has stumbled on this particular definition: the second key quality is that it is somewhat muddy and fuzzy.

Specification is a well-understood activity within software development. Visualization is a little soft, well known only as a technique. Constructing is, as I explained previously, a little confusing in this context and is typically a process. Documenting seems prosaic at best and, given the reluctance of almost anyone in software development to actually do documentation, has a well-earned last place in the list. Adding to the lack of focus is the direction that the UML can and should be used for business modeling and for creating models for systems that are not software systems.

So, aside from being an obvious result of "committee-think," the shortcomings in this section suggest that it was composed in haste, perhaps to be reworked at some future date.

What all of this textual nitpicking underlines is that the UML itself is first and foremost an evolving project with muddy areas. It has a formal specification written to accommodate the wide variety of interests that have been part of its birthing, and so it is occasionally fuzzy.

The formal specification is critical to understanding what the UML is about, especially when faced with contradictory and dated interpretations. And yet, it can itself be infuriatingly circular, self-referential, opaque, obscure, and possibly wrong-headed in spots.

Given all of this, a cautious but flexible interpretation of the specification is the best way to approach defining the UML. Too many of the books and articles that have been written about the UML mix in information about, for example, Rational Software's development process, the author's methodological biases, or specific uses without being clear about the boundaries of the UML itself.