Diagramming a System s Parts | UML 2 For Dummies

Diagramming a System’s Parts

UML is primarily a diagramming language. In this section, we show you how to take the classes and objects, along with their attributes and operations and to graphically represent them on diagrams. By capturing the elements on diagrams, you can depict and solidify your understanding of the static structure of your system, as well as communicate it to others for comment and buy-in.

Boxing in classes and objects

Figure 3-1: UML's class box.

To show a UML class box, just place the chosen class name in the center of the box, or perhaps about one third of the way from the top of the box, as shown in Figure 3-2.

Figure 3-2: A class box with a name.

Technical Stuff What’s in an icon?

The UML gurus argued for a long time on what shapes to use for the UML notation. For classes, one of the UML Three Amigos, Grady Booch, argued for an amorphous cloud-like figure (as shown in the figure)—based, of course, on his own Booch notation. Another Amigo, Jim Rumbaugh, argued for a box (based, of course, on his own Object Modeling Technique notation). Others argued for a variety of shapes, one of which was a tombstone-like icon. For a while, they even toyed with pentagons. Ultimately they settled on the rectangle box for objects and classes. Their key reasons: Objects and classes have crisp boundaries and need a crisp, solid, stable icon. And it had to be something simple to draw, not only for the developers, but for the UML tools too.

Differentiating between classes and objects

UML always tries to make similar things have similar shapes. Although this simplifies remembering the form, it can make them hard to tell apart. Objects also use boxes, just as classes do. To differentiate them, the UML gurus decided that object names must be underlined and then followed by the class name, with the two names separated by a colon.

When you show an object on a diagram, you can omit the class part of the name if its class is clear from the context (or if it’s still unknown and must be left unspecified). When you omit the class part, you’re allowed to omit the colon as long as you keep the underline. Alternatively, the object name may be omitted when you want to emphasize that any anonymous object of the class would do under the circumstances. Figure 3-3 shows several sample objects with different name forms.

Figure 3-3: Sample UML objects.

Using arrows to indicate an object’s class

Sometimes UML has more than one way of showing the same information. This doesn’t mean that you have to use them all. Even though redundancy can often improve communications, it usually makes the diagram more complicated. UML has another way of indicating that an object is an instance of a specified class—by drawing a dashed arrow from the object to the class. Avoid this arrow technique unless there is some reason to strongly emphasize that the object is a member of the class—and even then, it’s still probably better to drop the redundant class name from the objects. Figure 3-4 shows the use of an arrow to indicate the object’s class.

Figure 3-4: An object pointing to (instantiating)its class.

Using stereotypes

UML has lots of different kinds of dashed arrows that look identical. Luckily, UML allows you to label a model element to indicate exactly what kind of element it is. UML calls this label a stereotype. You show the stereotype next to the element (preceding the name of the element if there is one). UML has several predefined stereotypes or you can define your own to indicate a special kind of element for your own purposes

The syntax for a stereotype is as follows.

 «stereotype name»

A stereotype can appear before any UML element. You could label the kind of dashed arrow we used in Figure 3-4 as «InstanceOf» as the arrow indicates that the object is an instance of the class it points to.

The special characters surrounding the stereotype name are called guillemets. If you’re typographically challenged, you can use the double angle brackets << and >>, but the « and » are used in the UML standard.

Modeling forms

Following the object-oriented principles of encapsulation and co-location (as explained in the Chapter 2), UML displays each class along with its properties and behaviors together. Each type of information (class name, attribute, and operation) has its own compartment in a class-box symbol. And following the object-oriented principles of encapsulation and information hiding, the compartments may be hidden if desired. Figure 3-5 demonstrates the standard arrangement of the three compartments, and the following list describes them:

Name compartment: The name of the class goes in the Name compartment.
Attribute compartment: Place those attributes that you’ve already identified for the class in the Attribute compartment. When you look over all the attributes, you may find that there are some redundancies. It’s almost always good advice to eliminate duplication, but sometimes, there’s an attribute whose value can be calculated from some of the other attributes yet you still want the attribute to be kept. The calculated attribute is called a derived attribute and is flagged by a slash (/). For example, consider the following attributes of a Rectangle class:
```
 height: LinearUnits width: LinearUnits /area: SquareUnits 
```
In this case, the height and width are considered base attributes and the /area is the derived attribute. The base attributes are those whose values are needed to calculate the derived attribute. (See the sidebar “ Derived attributes” for more on—you guessed it—derived attributes.)

Warning Operation compartment: The operations of the class go in the Operation compartment. But don’t model all operations; some of them are automatically implied. Whenever there is an attribute on the class, there is likely to be an operation to SET the attribute’s value and an operation to GET the attribute’s value. Because these GET/SET operations (accessor operations) are relatively obvious, most UML tools generate such operations for you. If you write your own GET or SET operations, you may confuse the tools—and you’ll certainly crowd the Operation compartment.

Figure 3-5: A class's compartments.

Tip Derived attributes

Why might you keep a derived attribute if it’s really a duplicate? There are two basic reasons.

During analysis, you may find that a key customer concept, something from the customer’s basic vocabulary, is really derivable. If you eliminate that concept, you’ll have to spend a lot of effort in explaining why the customer can’t find the concept in your model. You run the risk of seeming either ignorant or arrogant if you leave it out. So leave it in—but mark it derivable.
During design, derived attributes have another purpose—efficiency. Suppose some calculated value is needed often, and quickly. If you plan ahead, you might want to precalculate the value and store it so it’s available when you need it. (Just remember to recalculate the derived attribute when the base attributes change.)

Unless it’s obvious, flag each derived attribute with the formula needed to recalculate it, as in the following example:

height: LinearUnits width: LinearUnits /area: SquareUnits  {/area = height ¥ width}

These brackets—{ }—indicate a constraint and may contain any information that limits the values of an attribute.

height: LinearUnits  {height > 0.0} width: LinearUnits  {width > 0.0} /area: SquareUnits  {/area = height ¥ width}