Diagramming a System's Parts






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: 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.


Figure: A class box with a name.

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 shows several sample objects with different name forms.


Figure: 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 shows the use of an arrow to indicate the object’s class.


Figure: 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 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 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: A class's compartments.
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}


 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows