Aggregation and navigability at the same end

Question

In UML, is it possible to draw an aggregation where the component object can access the composite object? Like in this image, but with only one association line, so the association end touching A would have a diamond and an arrow. If that isn't possible, the diagram I drawn is valid? If not, why?

Answer 1

Of course that's possible.

If you want to save space, you can use a single line for the association:

Here's my personal opinion about navigability: The navigational arrow is not needed as the existence of the property owner implies that already.

P. 110 of the specs:

When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.

P. 200:

Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the Association whereas navigable ends were assumed to be owned by the Classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are separate concepts, each with their own explicit notation. Association ends owned by classes are always navigable, while those owned by associations may be navigable or not.

---

But what is an association that is just named? It's a useless construct so far. What you intend is to finally create attributes in either classes - by means of properties in which case you add this (new) dot. To me this is simply over-constructed and impractical. Who is really using those dots? In EA you have to open sub-menus to make them appear. For me (and probably most UML readers) a role name represents a property and this an attribute in the other side. That's just "(my) human logic" behind that proposition. So, my practical approach:

• Use simple connectors for association
• Eventually add (non-) navigability (crosses and) arrows
• Later add role names to indicate the use of attributes at the other end (rather than adding a typed attribute to the class' list).

And that's it. Just forget that silly dot that's a) hard to produce (in EA) and b) even harder to recognize.

Once again: this last part here is my recommendation for practical modeling.

Answer 2

Another point of view, navigability is important to show how is it possible to navigate in the model and how to access to instances.

Another point is about OCL, if navigability is not defined some OCL queries will be hard to write.

Specification describes (p 198): Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.

And about Property class (p 149): The query isNavigable() indicates whether it is possible to navigate across the property. body: not classifier->isEmpty() or association.navigableOwnedEnd->includes(self).

So to model or not navigability is important.

If you want to have navigability in both side, the following image shows that:

But in section 6 of the specifiation, it is written:

• An association with neither end marked by navigability arrows means that the association is navigable in both directions.

• Arrow notation is used to denote association end navigability. By definition, all class-owned association ends are navigable. By convention, all association owned ends in the metamodel are not navigable.

So the following schema is the same than the above one. This is tricky but it seems true.