Navigability and aggregation

[Paolo F Cantoni]

This post is partly aimed at EA and partly at UML itself.

I've got used to drawing associations from source to destination.  (In my specialised Conceptual Modelling syntax, directionality is important - but that's another story).

Having created the association I open its properties and find source role and target (not destination) role and direction (not navigability)   as source and destination combinations.

Now, EA (in common with most tools) forces you to draw aggregation associations with the aggregation at the destination (target) end.  (I happen to prefer the other way but...)

The default direction (navigability) is shown as source->destination - but there is NO navigability arrow shown - when I draw the aggregation.  If I set the direction to other than source->destination (or unspecified) I get the expected navigability arrows.

Since one the explicit changes in UML2 was to explicitly highlight the differences beween unspecified navigability and the others, this needs to be rectified.

Now the hard bit...

Can anybody point me at where in the UML 2 specifications it says that aggregations have to be the drawn the reverse way around from all the other associations?
(I don't have access to the specifications at present - but from memory, I couldn't find it last time I looked as this is a particular peeve of mine)

How should aggregation associations be drawn so they are consistent?  This last is a genuine question (not rhetorical).  For example, should they be defaulted to aggregation at source, default navigability source->destination (my preferred option) or is there a more consistent way of doing it?

Paolo

[thomaskilian]

Has been discussed before. E.g. here http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1092740201

[Paolo F Cantoni]

Thanks Thomas for the pointers.

I see they basically refer to UML 1.x

Looking at the UML 2 Superstructure, I couldn't find any explicit reference to the kind of explicitness found in the posts you refered me to.

Have I missed something?

Paolo

[thomaskilian]

I guess pope Paul has to wait for pope Bruce

[KP]

The aggregation diamond symbol is always at the target (parent) end. This was explicitly stated in UML 1.5 and hasn't been changed in UML 2.0 which didn't seem to think it worthy of mention. (I've scoured the spec and not found it   )

UML tool vendors are free to draw aggregations in whichever direction they wish as long as the diamond symbol ends up at the end named "target". We think our way is more logical then the alternative. YMMV.

Navigability is a different issue.

[sargasso]

Yes, it is in there somewhere. Cant remember where though and IIRC its not obvious nor unequivocal.

Seriously though, there is a problem here with common usage <<elsewhere>> versus common usage <<here>>.  

There is a danger that the rest of the world approach of diamond on the source end will become the standard.  This will force EA to change.  So what's the danger?  Every model I've developed will then be "wrong"  as will my mindset.

IMNSHO EA is corrrect! (I think I said that somewhere before)  I got used to it, so should the rest of the world.

(Papal bull perhaps?)

bruce

[Paolo F Cantoni]

The aggregation diamond symbol is always at the target (parent) end. This was explicitly stated in UML 1.5 and hasn't been changed in UML 2.0 which didn't seem to think it worthy of mention. (I've scoured the spec and not found it   )

UML tool vendors are free to draw aggregations in whichever direction they wish as long as the diamond symbol ends up at the end named "target". We think our way is more logical then the alternative. YMMV.

Navigability is a different issue.

I'm not so sure that the UML 2 left it out because it was not worthy of mention.  They seemed pretty explicit in most other areas.  Although, I guess, if they had changed their mind the would have (should have) made it a deviation from 1.x

OK, if the target is the "parent end" - which I can accept and UML tends to draw it's connectors from child to parent, then conisistency (that magic word) should require that the default association should be drawn from source to target with the default navigability from destination to source.
In my opinion (not papal bull ) if the aggregation is drawn from child to parent, then the defualt navigability should be from parent to child (ie destination to source) conisistent with the above.

My real gripe is about the inconsistency... "ordinary" associations versus aggregation associations.

Paolo

[dr_shorthair]

OK, if the target is the "parent end" - which I can accept and UML tends to draw it's connectors from child to parent, then conisistency (that magic word) should require that the default association should be drawn from source to target with the default navigability from destination to source.
In my opinion (not papal bull Wink) if the aggregation is drawn from child to parent, then the defualt navigability should be from parent to child (ie destination to source) conisistent with the above.

Don't quite get this: I would have thought that if connector is drawn from child (dependant) to parent (dependency) then the default navigability should be from source (dependant) to destination (dependency). The dependant must know about the dependency, but not vice versa.

[Paolo F Cantoni]

Don't quite get this: I would have thought that if connector is drawn from child (dependant) to parent (dependency) then the default navigability should be from source (dependant) to destination (dependency). The dependant must know about the dependency, but not vice versa.

My observation was specifically about EA aggregations which are (in my view) to be avoided like the plague...  If you search for my comments on EA Aggregations you'll see what I mean.

Your general comment is correct.  However, elsewhere, I have noted that the UML "Generalization" relationship violates this rule.  Given the arrowhead at the destination end of the relationship it should (more) correctly be called a specialization relationship as the origin (child/client) specializes the destination (parent/supplier).

Paolo

[Paolo F Cantoni]

See: Aggregation and Association proposal for a proposal to provide consistent processing and rendering of EA Aggregations, Compositions and Associations.

HTH,
Paolo