A Conceptual Model of the UML
To understand the UML, you need to form a conceptual model of the language, and this requires learning three major elements: the UML's basic building blocks, the rules that dictate how those building blocks may be put together, and some common mechanisms that apply throughout the UML. Once you have grasped these ideas, you will be able to read UML models and create some basic ones. As you gain more experience in applying the UML, you can build on this conceptual model, using more advanced features of the language.
Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building blocks:
- Things
- Relationships
- Diagrams
Things in the UML
There are four kinds of things in the UML:
- Structural things
- Behavioral things
- Grouping things
- Annotational things
Structural Things
Structural things are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. Collectively, the structural things are called classifiers.
Classes are discussed in Chapters 4 and 9 . |
Figure 2-1. Classes

Figure 2-2. Interfaces

Interfaces are discussed in Chapter 11 . |
Figure 2-3. Collaborations

Collaborations are discussed in Chapter 28 . |
Figure 2-4. Use Cases

Use cases are discussed in Chapter 17 . |
Figure 2-5. Active Classes

Active classes are discussed in Chapter 23 . |
Figure 2-6. Components

Components and internal structure are discussed in Chapter 15 . |
Artifacts are discussed in Chapter 26 . |
Figure 2-7. Artifacts

Figure 2-8. Nodes

Nodes are discussed in Chapter 27 . |
Behavioral Things
Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. In all, there are three primary kinds of behavioral things.
Use cases, which are used to structure the behavioral things in a model, are discussed in Chapter 17; interactions are discussed in Chapter 16 . |
Figure 2-9. Messages

Figure 2-10. States

State machines are discussed in Chapter 22 . |
Figure 2-11. Actions

Grouping Things
Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. There is one primary kind of grouping thing, namely, packages.A package is a general-purpose mechanism for organizing the design itself, as opposed to classes, which organize implementation constructs. Structural things, behavioral things, and even other grouping things may be placed in a package. Unlike components (which exist at run time), a package is purely conceptual (meaning that it exists only at development time). Graphically, a package is rendered as a tabbed folder, usually including only its name and, sometimes, its contents, as in Figure 2-12.
Figure 2-12. Packages

Packages are discussed in Chapter 12 . |
Annotational Things
Annotational things are the explanatory parts of UML models. These are the comments you may apply to describe, illuminate, and remark about any element in a model. There is one primary kind of annotational thing, called a note. A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements. Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment, as in Figure 2-13.
Figure 2-13. Notes

Notes are discussed in Chapter 6 . |
Relationships in the UML
There are four kinds of relationships in the UML:dependency is a semantic relationship between two model elements in which a change to one element (the independent one) may affect the semantics of the other element (the dependent one). Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label, as in Figure 2-14.
Figure 2-14. Dependencies

Dependencies are discussed in Chapters 5 and 10 . |
Figure 2-15. Associations

Associations are discussed in Chapters 5 and 10 . |
Figure 2-16. Generalizations

Generalizations are discussed in Chapters 5 and 10 . |
Figure 2-17. Realizations

Realizations are discussed in Chapter 10 . |
Diagrams in the UML
A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and paths (relationships). You draw diagrams to visualize a system from different perspectives, so a diagram is a projection into a system. For all but the most trivial systems, a diagram represents an elided view of the elements that make up a system. The same element may appear in all diagrams, only a few diagrams (the most common case), or in no diagrams at all (a very rare case). In theory, a diagram may contain any combination of things and relationships. In practice, however, a small number of common combinations arise, which are consistent with the five most useful views that comprise the architecture of a software-intensive system. For this reason, the UML includes thirteen kinds of diagrams:
- Class diagram
- Object diagram
- Component diagram
- Composite structure diagram
- Use case diagram
- Sequence diagram
- Communication diagram
- State diagram
- Activity diagram
- Deployment diagram
- Package diagram
- Timing diagram
- Interaction overview diagram
The five views of an architecture are discussed later in this chapter. |
Class diagrams are discussed in Chapter 8 . |
Object diagrams are discussed in Chapter 14 . |
Component diagrams and internal structure are discussed in Chapter 15 . |
Use case diagrams are discussed in Chapter 18 . |
Interaction diagrams are discussed in Chapter 19 . |
State diagrams are discussed in Chapter 25 . |
Activity diagrams are discussed in Chapter 20 . |
Deployment diagrams are discussed in Chapter 31 . |
Artifact diagrams are discussed in Chapter 30 . |
Package diagrams are discussed in Chapter 12 . |
Rules of the UML
The UML's building blocks can't simply be thrown together in a random fashion. Like any language, the UML has a number of rules that specify what a well-formed model should look like. A well-formed model is one that is semantically self-consistent and in harmony with all its related models.The UML has syntactic and semantic rules for
What you can call things, relationships, and diagrams | |
The context that gives specific meaning to a name | |
How those names can be seen and used by others | |
How things properly and consistently relate to one another | |
What it means to run or simulate a dynamic model |
Certain elements are hidden to simplify the view | |
Certain elements may be missing | |
The integrity of the model is not guaranteed |
Common Mechanisms in the UML
A building is made simpler and more harmonious by the conformance to a pattern of common features. A house may be built in the Victorian or French country style largely by using certain architectural patterns that define those styles. The same is true of the UML. It is made simpler by the presence of four common mechanisms that apply consistently throughout the language.
- Specifications
- Adornments
- Common divisions
- Extensibility mechanisms
Specifications
The UML is more than just a graphical language. Rather, behind every part of its graphical notation there is a specification that provides a textual statement of the syntax and semantics of that building block. For example, behind a class icon is a specification that provides the full set of attributes, operations (including their full signatures), and behaviors that the class embodies; visually, that class icon might only show a small part of this specification. Furthermore, there might be another view of that class that presents a completely different set of parts yet is still consistent with the class's underlying specification. You use the UML's graphical notation to visualize a system; you use the UML's specification to state the system's details. Given this split, it's possible to build up a model incrementally by drawing diagrams and then adding semantics to the model's specifications, or directly by creating a specification, perhaps by reverse engineering an existing system, and then creating diagrams that are projections into those specifications.The UML's specifications provide a semantic backplane that contains all the parts of all the models of a system, each part related to one another in a consistent fashion. The UML's diagrams are thus simply visual projections into that backplane, each diagram revealing a specific interesting aspect of the system.
Adornments
Most elements in the UML have a unique and direct graphical notation that provides a visual representation of the most important aspects of the element. For example, the notation for a class is intentionally designed to be easy to draw, because classes are the most common element found in modeling object-oriented systems. The class notation also exposes the most important aspects of a class, namely its name, attributes, and operations.
Notes and other adornments are discussed in Chapter 6 . |
Figure 2-18. Adornments

Common Divisions
In modeling object-oriented systems, the world often gets divided in several ways.First, there is the division of class and object. A class is an abstraction; an object is one concrete manifestation of that abstraction. In the UML, you can model classes as well as objects, as shown in Figure 2-19. Graphically, the UML distinguishes an object by using the same symbol as its class and then simply underlying the object's name.
Figure 2-19. Classes and Objects

Objects are discussed in Chapter 13 . |
Figure 2-20. Interfaces and Implementations

Interfaces are discussed in Chapter 11 . |
Figure 2-21. Part with role and type

Extensibility Mechanisms
The UML provides a standard language for writing software blueprints, but it is not possible for one closed language to ever be sufficient to express all possible nuances of all models across all domains across all time. For this reason, the UML is opened-ended, making it possible for you to extend the language in controlled ways. The UML's extensibility mechanisms include
- Stereotypes
- Tagged values
- Constraints
The UML's extensibility mechanisms are discussed in Chapter 6 . |
Figure 2-22. Extensibility Mechanisms
