aggregation/composition/containment navigability

[robinch]

Hi,

By default, EA creates relationships which are navigable from the source to the target. Unfortunately, for aggregation/composition/containment (and perhaps other) relationships, the definition of the source & target elements are the opposite of what we would intuitively expect, e.g. for composition the whole is the target and the part is the source, thereby creating a relationship which is navigable from the part to the composite by default. However, in most cases, a composition defines links which are navigable from the whole to the part.

Instead of having to manually undo the default navigability, I wish EA could either define relationships which by default are navigable from target to source for these cases or even just leave the navigability undefined in both ends.

(Using EA 12.0.1215, same behavior observed in previous versions)

[qwerty]

Hmm. EA offers to create them in both directions when choosing from the quick linker.

q.

[robinch]

Yes, it is possible to select the gesture direction but the diamond (or "+ in a circle" in case of a composite relationship) is always set at the target of the relationship and the navigable end is therefore always set at the diamond end of it.

Basically you can choose to draw from target to source or from source to target but it does not change the final result, model-wise.

[Eve]

In UML aggregations don't have a source or target. It's better to read them that way despite the fact that in EA they do.

You can swap the aggregation easily enough, including defining it on an association. That may create unintuitive behavior in other areas such as locking though.

[robinch]

True, it is possible to create association first and define an end as an aggregation afterwards. However, EA groups the target ends when using tree style representations, so the notion of source & target ends cannot be completely ignored.

My suggestion was more to not assign navigability by default than to find a workaround. Pepole usally use the fastest way to create relationships (quick linker comes first) but they do not always remember to unset the navigability at the target end. And all those links with inverted navigability look very odd in reports.

[Geert Bellekens]

I think you can turn the default navigability on and off in the options.

But I agree with you. It feels wrong to always have the source at the part and the target at the whole end, even though in UML these notions (source/target) don't exist.

Geert

[robinch]

I think you can turn the default navigability on and off in the options.

Thanks Geert, that would be quite useful to us. The only one I found is the tick box "Links->General->Association default = source-->target" and made sure it is not ticked, but aggregation/composition/... relationships still get the inverted navigability. Perhaps there is another option somewhere (EAUI I think it is called here)? I'll have a look.

[Geert Bellekens]

That was the option I was referring to. I expected it to control the navigability in the aggregations as well.

Geert

[robinch]

That was the option I was referring too. I expected it to control the navigability in the aggregations as well.

Ok, thanks. I'll stop searching then  .

[Geert Bellekens]

See http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1447767256/4#4
I wrote a little script that switches source and target to make sure the composite end is always on the source.

Geert

[robinch]

Hi Geert,

I wrote a little script that switches source and target to make sure the composite end is always on the source.

Thanks for the link, I will definitely have a look into it. I am still pondering whether changing the source<->target ends or just inverting the navigability attributes is the best.

Apparently, when using tree style representations, EA always considers the target ends as the tree root and the source ends as the tree leaves (works well with e.g. generalization relationships). However, most of the times we are using tree style representations for aggregation-like relationships, the root is actually at the diamond ends, hence requiring the diamonds to be kept at the target ends.

[Paolo F Cantoni]

Hi Rob?,

It is now (fairly) common modelling convention that relationships are drawn from the client (origin) end to the supplier (destination) end.  This provides "directionality".  Navigability on the other hand, is about the ability to traverse the relationship to the navigable end.  EA conflates Directionality and Navigability.  However, if you apply the convention above, it doesn't really matter.

For the majority of relationships, the end with a glyph (Arrow, Triangle, Lozenge etc.) is at the supplier end.  In the case of aggregation, EA allows you to determine which way you like to "Draw" as opposed to "Store" aggregations.  The combination of the directionality of your drawing and the [] Draw Aggregations Reversed option, allow you to "choose your poison".  If you prefer to draw an aggregation from the meronym to the holonym, keep the option box unchecked.  If you like to draw from the holonym to the meronym, then check the box.  Either way, you end up with the lozenge at the supplier (destination) end.

HTH,
Paolo

[Geert Bellekens]

Apparently, when using tree style representations, EA always considers the target ends as the tree root and the source ends as the tree leaves (works well with e.g. generalization relationships)

Robin,

I'm pretty sure tree style is not UML compliant for associations. The problem is that you then don't have a place to put your multiplicity/rolename etc.. anymore.
This is different from things like a Generalization or Realization where there are no properties at the relationship end.
I would advise against using it for associations.

Geert

[robinch]

Hi Paolo, Geert,

It is now (fairly) common modelling convention that relationships are drawn from the client (origin) end to the supplier (destination) end.  This provides "directionality".  Navigability on the other hand, is about the ability to traverse the relationship to the navigable end.  EA conflates Directionality and Navigability.  However, if you apply the convention above, it doesn't really matter.

Not sure to understand what you mean by "it doesn't really matter". My initial request was to change the default behavior of having navigability towards the end with the diamond because, usually, this end is at the client side. A concrete example would be, say, a C++ application class containing an std::vector<T>. The  diamond would be at the application class end and obviously navigability should go from the application class to the vector<T> rather than the opposite.

For the majority of relationships, the end with a glyph (Arrow, Triangle, Lozenge etc.) is at the supplier end.

This is where I tend to disagree, perhaps because I am missing something, what you are saying stands for simple dependencies (Arrow) and generalizations/realizations (Triangle). For diamonds, it is exactly the opposite, i.e. the diamonds are at the client ends rarther than the supplier ends. Therefore, EA systematically assigning navigability to the target end of relationships is not optimal in my opinion.

I'm pretty sure tree style is not UML compliant for associations. The problem is that you then don't have a place to put your multiplicity/rolename etc.. anymore.
This is different from things like a Generalization or Realization where there are no properties at the relationship end.
I would advise against using it for associations.

Makes a lot of sense, very good advice which I will follow to the letter.

Robin

[KP]

OK, so a little bit of history. UML 1.5 specification, page 2-22, said the following about "aggregation":

When placed on one end (the “target” end), specifies whether the class on
the target end is an aggregation with respect to the class on the other end
(the “source”end). Only one end can be an aggregation. Possibilities are:
• none - The target class is not an aggregate.
• aggregate - The target class is an aggregate; therefore, the source class
is  a part and must have the aggregation value of none. The part may be
contained in other aggregates.
• composite - The target class is a composite; therefore, the source class
is a part and must have the aggregation value of none. The part is
strongly owned by the composite and may not be part of any other
composite.

This clearly stated that the end with the diamond was the target, and that is how we implemented it, i.e. correctly. Then when UML 2 came along and didn't even have a metaclass for aggregation or composition, there didn't seem to be a case for changing it, so we didn't.

My advice to anyone who is concerned about the directionality of aggregations and compositions would be to use associations instead. They are essentially non-directional, and you can draw them in whichever direction you like.