Aggregation in requirement diagram

[nvtrung]

I think it's better to reverse the default direction of aggregation association in the requirement diagram as follow:
- Create a requirement diagram
- Add a new Requirement element, call it REQ1. Use the quick link of it to create another Requirement, call it REQ2, select "Aggregation"

--> it's better if aggregation direction is reverse here!

[Eve]

You mean something like Tools | Options | Links | Draw Aggregations Reversed?

[Dave.B]

Simon,
that feature in EA doesn't work as expected. See here http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1254153042/6#6 (least not in v7.5.846)

Dave B.

[Eve]

It works as intended.  I'm sorry you were expecting something different.

[Paolo F Cantoni]

It works as intended.  I'm sorry you were expecting something different.

I suspect, Simon, that if you took a poll of users (especially new ones).  They'd agree with Dave.B  it's NOT what they were expecting.

While visually the Aggregation looks OK, from a modelling perspective it's wrong.

The diagram ISN'T the model (as I've recently said in another post).  It isn't enough that it looks right on a piece of printed paper - I can do that with MS Paint.  It has to be amenable to correct interpretation within the model.

If Dave.B draws his line from A to B, then he has told the model something:  "A is my origin and B is my destination."  For his semantics, he wants the shared (or composite) aggregation to be a property of the origin NOT the destination.  He has a RIGHT not to expect that EA switches the directedness of the line on him.  This happens because EA has conflated (my favourite word this month - if you haven't noticed) the ideas of directedness and navigability.  They are two distinct concepts.

Paolo

[Paolo F Cantoni]

Simon,
that feature in EA doesn't work as expected. See here http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1254153042/6#6 (least not in v7.5.846)

Dave B.

Elsewhere, I indicated that after 5+ years of managing to avoid EAAggregations, I've started to use them (for QuickLinker purposes).  But I then run an external query to convert them to Associations with the correct semantics for my purposes.  This may be the best solution for you (in the short to medium - to long term).

[KP]

It works as intended.  I'm sorry you were expecting something different.

I suspect, Simon, that if you took a poll of users (especially new ones).  They'd agree with Dave.B  it's NOT what they were expecting.

While visually the Aggregation looks OK, from a modelling perspective it's wrong.

The diagram ISN'T the model (as I've recently said in another post).  It isn't enough that it looks right on a piece of printed paper - I can do that with MS Paint.  It has to be amenable to correct interpretation within the model.

If Dave.B draws his line from A to B, then he has told the model something:  "A is my origin and B is my destination."  For his semantics, he wants the shared (or composite) aggregation to be a property of the origin NOT the destination.  He has a RIGHT not to expect that EA switches the directedness of the line on him.  This happens because EA has conflated (my favourite word this month - if you haven't noticed) the ideas of directedness and navigability.  They are two distinct concepts.

Paolo

If you took that poll of users which you are suggesting, you would find that some prefer one way of drawing aggregations, some prefer the other way. That's why reversing aggregations is a user option, not a model option. Now supposing you want to have several users working on the same model, and they have different preferences, the most important thing is that they are able to create a consistent model, agreed? EA does that by always having the owner at one end (which happens to be the one labelled "Target" in the properties dialog, for historical reasons - [highlight]see below[/highlight]) and having the owned at the other end (labelled "Source"), regardless of which way the pencil moves over the paper. Having a preference for which direction you move your pencil is a question of taste; creating inconsistent models isn't.

If you wish to change this behaviour, I would suggest writing an add-in that implements the EA_OnPostNewConnector broadcast handler to convert aggregations to associations. Make sure everyone who edits your model has it installed.


[edit]The historical reason being UML 1 which explicitly stated that the owner is at the "target" end and the owned is at the "source" end. UML 2 doesn't talk about "source" or "target", so they just become arbitrary text labels which you may apply your own meaning to, but for consistency sake the ID of the element labelled source will always be held in the EA model in t_connector.Start_Object_ID and the ID of the element labelled "target" will always appear in the EA model in t_connector.End_Object_ID[/edit]

[Paolo F Cantoni]

[size=18]...[/size]

I didn't explain my point well enough but, with respect Neil,  I suspect you've misunderstood it a bit.

Undoubtedly, different people want to model Aggregations in different ways.  Dave.B and I have a particular view - we accept (and here I'm putting words in Dave's mouth - which I'm sure he'll fix if not correct) that others will take a different view.

That's not the point I was making.  This is: EA doesn't provide a vehicle for all the possible semantics users may wish to apply to the EAAggregations.  It only provides support for some.

In particular, the way in many people interpret the phrase "Draw Aggregations Reversed" is: "Place the Aggregation at the origin - not the destination."  Not reverse the direction of the line but retain the aggregation at the destination (I believe that's Dave.B's specific complaint).  

I concede that post-facto one can see that the EA behaviour is in accord with the definition - but I STILL contend that this implementation violates the "Principle of Least Surprise".  

The validity of that contention is, I submit, further supported by changing the type of the connector from Aggregation to Association.  The rendering you get as a result - ALWAYS elicits a WTF! from the watcher!  It's NOT what they were expecting!

(Fellow users - if you've never tried it - do so...  You, too, will get a surprise!)

Yes, I agree I can use the event within an add-in to fix it.  I WILL get around to it, it's just that I have to fix a couple of other things (of this type) with queries so it's currently easier to run the query macro.  

My point (again) is: I shouldn't have to - EA should allow me to specify how I want Aggregations to be handled and make it happen.  Besides - if you go back to my original postings over 5 years ago, you'll see I was reporting self-inconsistency bugs within the (then) current EAAggregation implementation (whether I agree with it or not- which obviously I don't).  As far as I'm aware - they haven't been fixed.  So, why should I use a broken technology?

Paolo

[edit]I note your edit, above, to put the historical rationale for some of the current EA behaviour.  I was aware of that, but most users probably aren't.  So thanks for that!  However, I believe that doesn't change anything I've said above (or in the previous posting).[/edit]

[Dave.B]

Paolo has argued my point precisely!

To extend the argument, consider this. If I draw a unidirectional (that is directed) association from class A to class B (with the arrow head pointing at B), then class A will contain a reference attribute for an instance of B. Yet class B is at the target end of the association!

An aggregation is a specialised form of association in that it specifies the ownership of associated class instance. However, I would still draw the association in the direction of default communication (which is my world is always unidirectional, and only bidirectional under special circumstances and even then I tend to prefer separate associations for this to capture the intent clearly). Hence when class A is making use of class B the association is drawn from A to B (with the arrow head pointing at B). If I decide that class A will own the life of class B then the source end of that association will show the required aggregation with a black diamond.

It is not possible to do this with the aggregation connector because it always puts the diamond at the target end, even with the draw aggregations reversed setting set.

Even if other view points are valid, EA should support this view point.

Regards
Dave B.

[Geert Bellekens]

If the source/target stuff are only (outdated) labels, then why don't we get rid of them? Call them "foo" and "bar" is you must name them.

I must admit that i was surprised as well when I first an association (in the natural (so reversed) direction).

I would love an option to "really" draw the aggregations reversed, not only visually.

Geert

[KP]

it always puts the diamond at the target end, even with the draw aggregations reversed setting set.

No, EA always puts the diamond at the parent end, and the parent ID is always stored in the same place in the database: t_connector.End_Object_ID. This means that when interrogating your model with add-ins, custom SQL queries etc, you always know which end of the relationship to look at, because the internals of the model are consistent. If you are put off by that arbitrary text label "Target" then use associations and draw them whichever direction you want but you may find yourself writing far more complex SQL queries or add-ins which have to look at both ends of the relationship. But EA is not going to be inconsistent with the way it stores aggregations, because there could be any number of existing add-ins and custom searches in user land that rely on parent IDs being stored consistently in the one place.

[Paolo F Cantoni]

it always puts the diamond at the target end, even with the draw aggregations reversed setting set.

No, EA always puts the diamond at the parent end, and the parent ID is always stored in the same place in the database: t_connector.End_Object_ID.
[size=18]...[/size]

Neil,  The concepts of parent-child and origin-destination (source-target) are not homomorphic.  As Dave.B and I are arguing, we view the "parent" end of an aggregate Association as the origin.  

I, at least, accept that EAAggregations may need to remain as they are - for the reasons you've mentioned (again, principally historical).  However, if you decide NOT to use EAAggregations - for the reasons we've noted (and, I submit, your comment about using Associations suggests you concede that EA Aggregations aren't UML 2 compliant), then we lose access to a whole pile of EA functionality that uses the "conceptual notion" of aggregations (shared and composite):  Toolbox, QuickLinker etc...

What we're arguing for is the ability to specify:
[X] Use Associations for aggregation
   Indicator at: (X) Source (  ) Target end by default.
As you say, this may lead to more complex queries, but welcome to the world of UML 2...  As for exiting add-ins - how do they handle UML 2 aggregated Associations?

"We pays our money, we takes our choice..."

What we're grumbling about is we can't even close the sale!  

Paolo

[son-of-sargasso]

+1 for what they said.  It still confuses the heck out of me and I still have to manually reverse the association every time.  By "it" I mean the UML aggregation standard and the EA options and the congruence of the two.

bruce

[MatthiasH]

I agree as well.

If it really breaks backwards compatibility to provide a good solution then at least this should be considered for the next major release (8.x), where customers might have to accept such a break.

History should not make us suffer for all eternity... :-/

Regards,
Matthias

[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