UML Aggregation with and without arrow head

Question

I always thought that the UML aggregate is defined as a black (filled) diamond at the beginning of a path and no arrow head that the end:

|--------|        |--------|
| :MyA   |<>------| :MyB   |
|--------|        |--------|

Today I came across a notation like <>-----> (with an explicit arrow head on the right end). So I looked it up in the UML 2.4 specification and actually found references for both versions.

My favourite reference: "UML and Patterns" by Craig Larman only mentions the first version without the arrow. In the UML specification I found a notice about navigable ends, but I am not sure if this is related and if whats the difference?

Could someone explain this more thoroughly and give an example for the use of each version?

Answer 1

Any association end can be designated to be "navigable" with the help of a navigability arrow. However, UML's notion of "navigability" does not have a precise meaning and people confused it with the concept of an association end being owned by the class at the other end. This concept of association end ownership by a class means that the association end corresponds to a reference property of that class. This issue has only been clarified in last year's new UML version 2.5, which has introduced a new visual notation for association end ownership, a "dot" as in . This is most likely the intended meaning of what you came across, namely , and what it really means is the following reference property:

For more explanation see this tutorial.

Additional answer to the comment: If your class model specifies the ownership of all association ends, and your class diagram displays them, and there is no ownership dot (nor a navigability arrow), as in , then, according to UML 2.5, the association end is "owned" by the association itself. Since we do neither have an ownership dot at the MyA end, both ends are "owned" by the composite association. In terms of the code to write/generate, this would mean that the composite association is not implemented by means of reference properties in either MyA or MyB, but has to be implemented with the help of a separate class, say "MyA-has-MyB", which has two reference properties for referencing both the aggregate and the component of any composition link, as in the following class rectangle:

Answer 2

One arrow means the association is navigable this way. No arrows means the association is navigable BOTH ways. Two arrows are omitted.

It could be a problem, because two ends with undefined navigability look out the same way, but it is the standard.

You can read more thoroughly about associations/navigability/aggregations in this my answer https://stackoverflow.com/a/21478862/715269

Answer 3

Direction implies a client/server or master/slave relationship. In the case of aggregation, the usual situation is the programmer uses the aggregate to find the sub-components for that object (e.g., use the car to find the car parts). Directionality towards the part class makes this relationship explicit, though in most cases it is redundant.

Answer 4

An association has two ends. An association’s end is modeled by means of a UML Property which can be owned by the classifier involved at the related end of the association, in that case the association is said to be navigable as the source classifier can directly refer to the target instance (the instance at the other end of the association) by means of that property. Otherwise the property representing the association end may be owned by the association instance itself

see http://lowcoupling.com/post/47802411601/uml-diagrams-and-models-with-papyrus