UML Class diagram: difference between Navigation and Ownership

6
votes

I read the posts in

but the difference between "navigation" and "ownership" of associations of UML class diagrams is still unclear to me. Moreover, UML 2.5 was released in the meantime.

The specification states the following:

Association ends owned by classes are always navigable, while those owned by associations may be navigable or not.

  1. This means, that the example c below is invalid. Examples a and b are valid, in both cases the right end is navigable. However, in example b the left end is not navigable.

    Am I right?

  2. What is the semantic difference between navigation and ownership? Is navigation a "generic" way of accessing the opposite class while ownership enforces a class to have an attribute?

enter image description here

1
associationsumlclass-diagram

1 Answers

3
votes

The specs say

Dot notation is used to denote association end ownership, where the dot shows that the Class at the other end of the line owns the Property whose type is the Class touched by the dot.

So a and b are valid and c is strange. Assuming left begin class A and right being class B. In case a A owns a property that is of type B and thus it can navigate to it. Case b explicitly adds the information that A can navigate to B which is already obvious by using the dot. In case c B owns a property of type A (and therefore can navigate). Additionally you indicate navigation from A to B without showing ownership. So that's strange.

Ownership just says there is something (a pointer) to navigate to the other object. To cite the specs (p. 126):

Navigation arrows may be shown, but if shown, they shall agree with the navigation of the Association’s ends.

and later (p. 201):

In practice, it is often convenient to suppress some of the arrows and crosses that signify navigability of association ends. A conforming tool may provide various options for showing navigation arrows and crosses. As with dot notation, these options apply at the level of complete diagrams.

  • Show all arrows and crosses. Navigation and its absence are made completely explicit.
  • Suppress all arrows and crosses. No inference can be drawn about navigation.
  • Suppress all crosses. Suppress arrows for Associations with navigability in both directions, and show arrows only for Associations with one-way navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation at all; however, the latter case occurs rarely in practice.

Navigation does not have a real use (in most cases). You show navigation by adding role names which make clear that A sees B as role. There's a notation with a cross near the end which explicitly forbids navigation. This might be useful in some cases.

It might be noted that the specs are rather silent about "navigation" (just grep the occurrences) compared to "ownership" (which is used quite a bit more). This is probably to account to the fact that the ownership had been introduced recently.