Poseidon for UML: User Guide
Prev |  | Next

# Chapter 12. Element Reference

# 12.1. Relationships

Relationships 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 12-1. 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. Beginning with Poseidon version 3.0, association ends may now have an initial value entered in the Properties tab.

Figure 12-2. 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.

## 12.1.1. Types of Relationships

- Generalization

- Dependency

- Association

- Directed Association

- Aggregation

- Composition

## 12.1.2. 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 12-3. Highlight hints for associations.

## 12.1.3. 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 12-4. Style tab with multiplicity set

## 12.1.4. 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 12-5. The rapid button for self-associations

Prev | Home | Next
Editing Diagrams |  | Classes