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

Stereotypes

One of the general patterns of an architecture is the Model-View-Controller-Pattern, or the Boundary-Control-Entity-Schema, as it is often rephrased in the UML community. According to this, an architecture is constructed in three layers.

First, the Boundary is responsible for representing information to the user and receiving his interactions. Users of the system interact with this layer only. The next layer, Control, contains the rules on how to combine information and how to deal with interaction. It is responsible for transferring control based on the input received from the Boundary layer. And finally, the Entity layer holds the data and is responsible for its persistence. To which layer a class belongs is expressed using corresponding stereotypes. You obtain these in the Properties tab of each class. An example for the usage of stereotypes is shown below.

Figure 9-3. A Class Diagram making use of Stereotypes.

The code generation functionality of Poseidon for UML can distinguish between different stereotypes for the same element type. In this way it can select the appropriate template for generation based on both of these factors.

Stereotypes can be displayed for nearly every element type.

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 9-4. 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 9-5. 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 9-6. 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.

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 9-7. The rapid button for self-associations (lower right).

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 9-8. Properties of an Attribute.

Attribute Properties

Figure 9-9. 'Remove Attributes' Setting

Operations

Figure 9-10. 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).

In the field 'Accessed Attribute', you can define whether this operation should be marked as an accessor method for an attribute. The primary use of accessor methods is to modify the attribute internally and to control access to the modifications externally. You can choose a modified attribute (if the operation is an accessor method created by Poseidon, an attribute is already selected) or select none if you want to decouple an accessor method from its attribute.

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.

The last list, 'Raised signals', is used to define whether this operation throws exceptions. Select 'Add...' from the context menu, enter a name and select a type for the thrown exception. As you know, only the type of the exception (not the name) is relevant for code generation. If you need more exception types, simply create the corresponding class in your model (e.g., MailException in your package javax.mail). Your exception type must end in ...Exception in order to be visible in the type list of exceptions.

You can define a constructor by setting the stereotype <<create>>. When you do this, the name of the operation is automatically set to the class name, and the return type is also of the class. The Java code generation respects this fact by correctly generating a constructor signature.

Diagram Elements

Toolbar

Select

Class

Package

Actor

Generalization

Dependency

Association

Directed Association

Aggregation

Composition

Interface

Realization

Collaboration

Classifier Role

Attribute

Operation

Note

Connect Note to Element