Class Diagrams

Class diagrams are probably the most important diagrams of UML. They can be used for various purposes and at different times in the development life cycle. Class diagrams are often applied to analyze the application domain and to pin down the terminology to be used. In this stage they are usually taken as a basis for discussing things with the domain experts, who cannot be expected to have any programming nor computer background at all. Therefore they remain relatively simple like this typical example, the Entity Class Model Overview Class Diagram.

Please note that graphical elements have been added to this diagram simply to highlight different regions.

Figure 7-2. A Class diagram.

Once the domain has been established, the overall architecture needs to be developed. Class Diagrams are used again, but now implementation-specific classes are expressed in addition to the terms of the domain.

If a class is shown in a diagram of a different package, the text (from package.subpackage) is displayed just under the class name in the diagram. You can turn it off with the Context menu of the class. Move the mouse over the class, right-click, and select Display - Hide Package display.

Classes

Classes are the core elements in an object-oriented model. They are represented by rectangles divided into three sections that display class information in the topmost portion, attribute information in the second, and operation information on the bottom. These compartments can be hidden via the context menu, as can package and stereotype information.

Attributes

Every class can have attributes that express some of its properties. In UML, every attribute has a name and a type. The type can be any other DataType, Class or Interface that is in the model. You can select the type from a combo box of all available types. If the type you need is not in the list, you can create it elsewhere, and then select it from the list.

Figure 7-3. Properties of an attribute.

Attribute Properties

Figure 7-4. 'Remove Attributes' setting

Operations

Figure 7-5. Properties of an operation.

For every operation, you can set several UML properties. Among them are visibility, scope (class or instance), and concurrency (with designators like sequential, synchronized, and concurrent). You can set an operation to be final, be a query, abstract, or a root method (with no parent).

The two lists on the right of the Properties tab are used to refine the operation's signature. In the list of parameters, the first parameter return is always there. This defines a return type for this operation. Similarly, you can add parameters that may be given a name, a type and the modifier 'final'. The final modifier is a special case that we introduced to handle Java.

You can define a constructor by setting the stereotype <<create>>. The code generation generates a constructor signature.

Operation Properties

Associations

Associations are very important in UML. They have properties in and of themselves, as well as consisting of other model elements. Every association has two association ends that are model elements in their own right, as defined in the UML specification. Figure 9–4 shows the Properties tab for an association, in this case between Account and Member. Notice that there is no stereotype or name for this association, but they could conceivably exist. Also note that the association is part of the Design.Use Case - Implementation.User Registration namespace.

Figure 7-6. Properties tab for an association.

An association end can also be given a name, and like an association it doesn't require one. If an association end does not have its own name, the class name at that end of the association is displayed. Look to the left hand side of Figure 9–4. In this case, both association ends have been named. Like hypertext, they link to the association end properties, not to the class properties.

Figure 7-7. Properties tab for an association end.

Associations can be specialized to an aggregation or a composition. To do this, navigate to one of the association ends and change the aggregation type from none to either aggregation or composition. They can also be created directly from the toolbar, using the 'Create Aggregation' button or the 'Create Composition' button.

Navigability

The navigability of associations is similarly changed, using the association ends properties. The check box titled 'navigable', when checked, means towards the class that this association end points to. This is a bit counter-intuitive at first, so further explanation is warranted:

Associations can be modeled as navigable in both directions, navigable in only in one direction, or without any navigability. In most cases, navigability is indicated by arrows in the diagrams. The one exception is the default association, an association which is navigable in both directions. In this case arrows are omitted. The navigability of an association occurs at the beginning of the arrow, not at the end. You can easily navigate to the opposite association end using the navigation button in the Properties tab.

When you first create an association, it is navigable in both directions. The UML standard requires that both arrows are hidden in this case, so it looks just the same as an association with no arrows at all. To distinguish these two cases, the arrows of both its ends show up in grey, if necessary, when you select an association.

Figure 7-8. Highlight hints for associations.

Hiding and Displaying Multiplicity of 1

When a multiplicity of 1 is set, some UML authors recommend hiding the 1, whereas others like to show the 1. To suit your needs, you can set the single multiplicity to be displayed or hidden. This can only be set diagram-wide in order to avoid confusion.

To change the display setting for single multiplicity:

  1. Select the diagram where you want to change the setting.

  2. Go to the Style tab.

  3. Activate or deactivate the 'Show association multiplicity of 1' check box.

Figure 7-9. Style tab with multiplicity unset and set

Self-Associations

Associations usually connect two different classes. But they can also be drawn from one class to itself. Simply use the rapid button in the lower right corner of the class.

Figure 7-10. The rapid button for self-associations

Diagram Elements

Toolbar

Select

Class

Package

Actor

Actor as Classifier

Generalization

Dependency

Association

Directed Association

Aggregation

Composition

Association Class

Interface

Realization

Collaboration

Classifier Role

Attribute

Operation

Note

Connect Note to Element

Text

Circle

Rectangle

Polygon

Polyline

Repaint