Allow replacement of EA Aggregations

[Paolo F Cantoni]

In a recent topic: [size=13]UML2 Enumeration Elements[/size] I suggested the formal creation of a UML 2 Enumeration Element.

This topic is pointed in the same direction...

If you search for "Aggregation Association" under my name in the UML Forum you find me take issue with the existing EA Aggregation Element.

Some pertinent topics are: [size=13]Target Class as Aggregate[/size], [size=13]WARNING: Aggregations vs Aggregate Associations[/size] and [size=13]Association or aggregation?[/size]

Could we please have an option that forces the Aggregate and Compose tools on the Toolbox to draw EA Association Connectors instead of EA Aggregation Connectors.

This option plus the use of the Draw Aggregations Reversed and the Association default = source -> target should allow the drawing of a composite (or shared) aggregate from the source (origin) class to the target (destination) class with the AssociationKind diamond at the source end and an arrow at the target end.

Thoughts? Votes?
Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[«Midnight»]

I believe you are correct on this.

That said, I also agree this should be an option setting. While I'd personally like the default to be as you've proposed, it is probably best to have it default to current behavior, since this might prevent breaking current models.

Add my vote.

[Paolo F Cantoni]

[size=20]BUMP![/size]

In a recent post http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1253503550/5#5 David («Midnight») mentions the "seemingly permanent schizophrenia in how aggregations are handled".

He's right... This topic goes back a long way and references topics at least a year earlier than this one...

I have steadfastly managed to avoid using EA Aggregations and EA Compositions, and have so advised others.  Until now...

In order to make life easy for my user (of my developing MDG Technology) I need to allow them to create UML Aggregations (both shared and composite) using the QuickLinker.

However, I can't create proper aggregations using the QuickLinker.  So I'm forced to use the EA ones (transiently) and then retrospectively fix them up with a simple query soon after their creation.

Can we finally get some action on this?  If an option was added to use UML Associations for Aggregations (and EA did the appropriate mappings) a lot of grief would be saved.  The same functionality could be used in the Toolbox so that dragging a Composition or Aggregation onto the diagram would, in fact, create a suitably configured Association.

Reported (again)!
Thoughts? Votes?
Paolo

[Thelonius]

Agree with this request.

I wonder why Sparx does not appear to give significant feedback to legitimate feature requests on this forum. Such as this.

Among the best aspects of being a loyal advocate of the Sparx EA tool (I was using EA-created artefact examples in a TOGAF 9 course this week that I've been teaching) is the ... well there are a lot of reasons.

But one of the things that is starting to bug me a little is that feature requests from heavyweight users like you guys - who contribute a lot of knowledge to this forum - often seem to go ignored.

Goes into a black hole. No response. No "roadmap" information from Sparx such as "we've been thinking about that and it may be in a release in about a year" or "that's not such a good idea and we're never going to do that - go take a hike" or anything.

Am I wrong?

[Geert Bellekens]

I defenitely agree.
There should only be one type of Association with AggregationKind none, shared or composite.

That being said, that doesn't mean that there should be only one connector (association) in the toolbox. Aggregation (maybe, I don't use that anyway) but certainly the Composite connector button should remain in the toolbox. They should just create associations with default AggregationKinds set.

About the transparancy and feedback from Sparx, yes I would love that.
On the other hand I must say that I'm already very pleased by the way Sparx communicates with its customers. They participate in this forum, they always answer support questions/bug reports and in general bug are fixed relatively quickly thanks to their short develpment cycle.
All of that is much (MUCH) better then the experiences I had with other UML Case tool vendors (IBM, Mega).
For me all of this (next to the price) has been a deciding factor in persuading clients to go for EA.

But yes it's not because the others are worse that Sparx can't improve even more.

Geert

[Paolo F Cantoni]

This one almost warrants a Dear Geoffrey... since the effective outcome is the same, but since I've been asked not to, I won't.

As I mentioned above, I've tried to avoid Aggregations.  Here's one of the reasons why...

If you create a Shared Aggregation via the toolbox you get an Aggregation of subtype <null>.  If you create a Composition you get an Aggregation of subtype "Strong".  If you then change the Composition to a Shared Aggregation (via the dialog), you get an Aggregation of subtype "Weak".

So, once again, you get two different results for the same concept depending on which "route" you take to get there...

Will this much, at least, be fixed for build 850?  If you're going to be wrong, at least be consistently wrong!

Reported,
Paolo

[Thelonius]

In build 849 - released today, I find the following in the release notes:

Connector labels for Aggregation and Composition source and target roles will display a derived '/' symbol, if the derived option is set.

This doesn't help, does it?

[Paolo F Cantoni]

This doesn't help, does it?

Hi Thelonius,

No.  I believe this fix this is related to the relationship ends (and I suspect that this fix will ONLY apply to UMLAssociations ends and EAAggregations ends).

Every relationship type is derivable but EA only allows the IsDerived custom property on the (I think) UMLAssociation and EAAggregation relationships.  However, just because the relationship is derivable, doesn't mean the ends are.  I must admit I haven't thought deeply about the end-calculus given the derivability (canonicity) of the relationship itself.  However, I'll be getting to that shortly as derivable relationships are showing up on our models with increasing frequency.

HTH,
Paolo

[Paolo F Cantoni]

[size=20]BUMP![/size]

Can we finally get some action on this?  If an option was added to use UML Associations for Aggregations (and EA did the appropriate mappings) a lot of grief would be saved.

AS mentioned in: [size=13]Target Class as Aggregate[/size], [size=13]WARNING: Aggregations vs Aggregate Associations[/size] and [size=13]Association or aggregation?[/size]

The EA Aggregation connector is fundamentally broken (as a technology).  Now that I'm forced to use them (for QuickLinker purposes), I've found:  While Association honours the AggregationKind (at both ends) - so that you CAN create an anomalous arc with a shared aggregation at one end and a composite aggregation at the other, when you convert the Association to an Aggregation, it will throw one of the them away.  In addition, the model validation says all is fine in all cases...

Since it now seems that we users need to submit multiple feature/bug requests to get any action, could I suggest that you support me by doing so?

The title of the feature request/bug report - I guess it's your choice of what you use... - should be: "Allow replacement of EA Aggregations"

Reported (again)!
Paolo

[Paolo F Cantoni]

See: AggregationKind - client end concept? for additional, related, concepts...

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

[beginner]

Though I fall on my knees every evening to pray for the fulfillment of your wishes - I doubt Sparxians will hear you. Not even the spelling of Realiz/sation has been corrected until now. Nor speaking of this BUMP 3 years yo-yo.
 
b.