10.2 Every Picture Tells a Story: The UML as a Modeling Language

A good place to start with the UML is to think about the difference between a programming language and a modeling language.

Unlike a programming language, which derives its effectiveness from syntax (the orderly and correct arrangement of its elements), a modeling language relies on its semantics, the meaning implicit in each element, and the way elements connect conceptually to achieve a useful end result.

A program is just so many pieces of text; every piece of text has a functional meaning defined by rules of usage. The syntax is critical: a word used in the wrong place is meaningless, or (worse) an error. The semantics is only local source code can call an apple an orange and still execute properly, as long as the intent is to uniquely name an object and the naming is consistent. The name has nothing to do with the underlying operations. Naming and labeling are quite separate.

Because a program does something, like a machine, only the instructions have to be correct. However, there's no room for clever interpretation. Any cleverness is left to the program creator, by means of algorithmic and organizational compression rather than clever abstraction. But because a programming language is prescriptive and we don't expect prescriptions to be interpreted, even logical compression itself is regarded as bad style in programming because it forces maintenance programmers to interpret and puzzle out meaning that should be explicit, even obvious.

Models are different less focused on the machine. One way to look at a model is as a structured collection of collaborating symbols an architecture of abstractions. The syntax is important, but because a model exists to communicate, not do, interpretation is the key.

A model has no life on its own; it lives only through the meaning that its human interpreters provide collectively: in a model, unlike a program, calling an apple an orange will confuse or perhaps be taken as poetic. In presenting models, graphical syntax is important but not critical the location of symbols or the shape of their connections is as much a result of style or convenience as anything else.

This distinction goes to the heart of the purpose of modeling and is critical to achieving a level of comfort with the UML.

UML models are not formal specifications by themselves; they are analysis, design, and management tools. Trying to equate them with blueprints muddies the metaphorical waters for modeling practitioners in an effort to tie modeling to one ultimate end product constructed software systems. Blueprints are working drawings; they are, hopefully, rigorous specifications for constructing a physical reality in an unambiguous fashion. Their purpose is translation, not interpretation and communication, so syntax is more important than semantics. The real architectural analogy is to architectural drawings as a whole, not just to blueprints. J.A. Zachmann made this point in his seminal paper on architectural frameworks for information systems back in 1987. Zachman emphasized that each standard architectural representation used in the design and construction of a building "differs from the others in essence, not merely in level of detail" (1999, 460). He made those differences an important part of his explanation of system architecture.

The difference isn't just in content and level of detail; it's also in purpose and the way the act of drawing (or modeling, in the case of software systems) impacts the process. In Why Architects Draw, Edward Robbins talks about the different types of drawings an architect produces, ranging from those that are very personal and conceptual to working drawings, "conventionalized representations produced at the end of the design process" for the builders and lawyers. "[W]ith the exception of the working drawings, how one chooses to draw suggests a whole series of complex viewpoints" that are selectively rendered in different kinds of drawings (1994, 27). The art and the usefulness are in the selection as well as in the result; the act of drawing shapes is the end result beyond the content of the drawings. Only working drawings are conventional and, therefore, not situated in the particular culture and context of the design.

The UML Specification says something similar: "The choice of what models and diagrams one creates has a profound influence upon how a problem is attacked and how a corresponding solution is shaped" (Rational Software Corporation 1999, 1 3). Interestingly enough, the UML as a collective product recognizes a distinction that individual interpreters usually don't. It goes on to identify other considerations that echo the way drawings are used in architecture:

Every complex system is best approached through a small set of nearly independent views of a model. No single view is sufficient.
Every model may be expressed at different levels of fidelity.

There are other similarities between architectural drawings and system models; in particular, both are used as the basis for the planning of work and, more importantly, for conceptual experimentation. "Models give us the opportunity to fail under controlled conditions" (Booch 1994, 22).

There are dissimilarities. Unlike the free-form conceptual compositions of architectural drawing, in a model every element has some meaning; the UML does impose rules about what can and can't appear in presenting a model element in a diagram. But still, like a drawing, each diagram and model is meant to be taken as a whole, with the context playing a primary role in telling the story. The context for a model is the view it realizes. In the UML, each model is a reflection of the user and the uses of the model. It represents the system from a particular viewpoint.

Every picture tells a story, as one rock-and-roll song suggests. Sometimes, the story is meant to be creative and informal, sometimes it is formal, sometimes it is about organizing work. Regardless, with the UML, it is always a story with a point of view.