Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: angel-o-sphere on March 08, 2004, 06:47:36 am
-
Hm,
in respect to all other CASE tools I have ever used (over 10) EA draws the aggregation into the opposite direction.
E.g. if you draw an aggregation from class A to B, all CASE tools consider A to be the container class and B to be the part and the diamond shape is drawn at the A position.
I explicitly checked e.g. in Magic Draw from nomagic.com which side they consider the source of the relation and which side they consider the target. They draw the diamond at A and consider A the source.
In EA I have "unintuitively" to draw the relation into the opposite direction; I have to click/drag/release from B to A to get the desired aggregation AND surprisingly EA considers the containing side of the relatin to be the target.
Who is right? EA or all others? I suspect an error in the UML definiton which was "ignored and fixed" by all other CASE tool vendors but not by EA ... any idea? Or is there a debate somewhere going on about this issue?
Or, more interestingly, is it a configuration option, how to draw/create aggregations? Its very inconveniant to remember to draw aggregations/compositions into the opposite way, especially when you start with associations which you morph later into aggregations where needed.
What surprises me is -- thats the reason for this long message -- that no one mentioned it in the forums.
Regards,
angel'o'sphere
-
especially when you start with associations which you morph later into aggregations where needed.
I agree with this issue - converting associations into aggregations does irk one somewhat.
However in general, I dont have a problem with the container being the target side element.
I just re-reviewed the UML 1.1 spec and it is clear that the intent is that the target is the containing element:When placed on a target end, specifies whether the target end is an aggregation with respect to the source end.
...
aggregate The end is an aggregate; the other end is therfore a part ... etc
(Semantics section 4.2 Abstract Syntax p18 )
So I suspect you're right - other tools have changed the direction as it made more sense to them.
Maybe I just got used to EA going the "correct" way, but I'd seriously hate to see it change now!
Bruce
p.s. Why the v1.1 reference - becasue I find that it is generally the best structured of the entire series, 1.5 has a very similar quote. V 1.1 has got to have the best explanation of well-formedness rules of the series - the v2 superstructure is attrocious in comparison.