MDG Compositions DON'T react to Shapescripts

[Paolo F Cantoni]

In the past I've noted the various problems with what David <<Midnight>> describes as the " permanent schizophrenia in how aggregations are handled".

Here's another one.

When you create an MDG, you need to extend a metaclass with stereotypes.  In order to create a shared  aggregation you need to extend an "Aggregation" metaclass.  To create a composite aggregation you need to extend a "Composition" metaclass.  In that way, you get the appropriate icons on the Tool box and the correct arcs drawn when you drag from the toolbox.

Unfortunately, the extensions to "Composition" DO NOT react to ShapeScripts defined for them.

I've got a fair idea why this bug is manifest and it does relate to David's point.

Reported,
Paolo

[«Midnight»]

I ran into this variation - or at least what I thought was this variation - some time ago. Back then (circa 7.1 or a bit earlier) shape scripts were a bit more approximate (for lack of a better term) than now when dealing with connectors.

At the time I had more pressing concerns, such as how shape scripts handled stereotyped "standard" UML connectors. Eventually I shelved the whole thing until EA had evolved a bit and I had time once again.

Perhaps the first of those has come to pass. Or at least is now at a point the issue Paolo raises can be addressed to good effect. [I am not sure the second event has happened yet, but that's not the point.]

Shape scripts seem to respect (at least some) built-in connector stereotypes. Is it time to solve this problem yet?

Or, to play devil's advocate, could this issue be a corollary of the "we cannot resolve the incorrect aggregation problem because it would break models that have used the incorrect paradigm" thinking?

David

[Frank Horn]

In order to create a shared  aggregation you need to extend an "Aggregation" metaclass.  To create a composite aggregation you need to extend a "Composition" metaclass.  In that way, you get the appropriate icons on the Tool box and the correct arcs drawn when you drag from the toolbox.

As of version 8, you can extend "Association" and set the "_TargetAggregation" attribute. I haven't tried it yet, but I had been sadly missing this for quite a while, and next time I put on my MDG hat I'll have a look into this.

http://www.sparxsystems.com/uml_tool_guide/sdk_for_enterprise_architect/supportedattributes_2.htm

[Paolo F Cantoni]

[size=18]...[/size]
As of version 8, you can extend "Association" and set the "_TargetAggregation" attribute. I haven't tried it yet, but I had been sadly missing this for quite a while, and next time I put on my MDG hat I'll have a look into this.

Hi Frank,

Thanks for the pointer, but my assessment (and I strongly suspect David, above, would agree) that until the whole subsystem is made consistent, we'll be just trading one set of inconsistencies for another.

Hopefully, this is just the start of a makeover - but we'll have to see.

Paolo

[Paolo F Cantoni]

[size=18]...[/size]
Or, to play devil's advocate, could this issue be a corollary of the "we cannot resolve the incorrect aggregation problem because it would break models that have used the incorrect paradigm" thinking?

Hi David,

Recognizing that this (to my mind flawed) thinking seemed to drive the response to this problem, I tried to carefully construct a proposed solution: Aggregation and Association proposal that allows existing models to remain as they are but, but appropriate settings of the various options allows a operational, consistent, mechanism for correctly handling the various forms under as many aspects of usage under EA as I could think of at the time.

Have another look at the proposal and if you think it would help, formally let Sparx know.

Paolo

Why is it flawed thinking?  Because you can't stop the existing models breaking!  The only way is to NOT change EA at all...  (and that DIDN'T happen!)    You can't make something that is fundamentally flawed work by adding more code.  You have to fix the fundamental problem!

[«Midnight»]

...
Paolo

Why is it flawed thinking?  Because you can't stop the existing models breaking!  The only way is to NOT change EA at all...  (and that DIDN'T happen!)    You can't make something that is fundamentally flawed work by adding more code.  You have to fix the fundamental problem!

Hi yourself Paolo,

I absolutely agree with Paolo's point above! Move forwards. Sparx has been doing that with some exceptions, the case in point being one.

My hours are unforgiving these days so I will follow the link later. In the meantime I hope other readers will do so. And I hope they will chime in on this on. It has been too long with us; time for a change.

David

[Paolo F Cantoni]

Reply from Sparx:

We were able to reproduce this issue and have logged it as a bug to be fixed.

Reference Number: 10045560

This issue relates to composition being a sub-type of aggregation.  The shape script effectively looks for aggregation stereotypes instead of composition stereotypes.  A possible work-around is to have your stereotype extend both aggregation and composition - you would drop stereotyped composition from toolbox as before, but the hidden aggregation stereotype will ensure the shape script lookup succeeds.

As will now be inferred from my somewhat cryptic reference in the original post, I'd already figured the work-around.  The hidden aggregation stereotype isn't actually "hidden".  The Toolbox takes NO cognizance of the «extends» connector on the Stereotypes page, but the Shapescripts does (and ignores the implied relationship on the toolbox page).  So the Stereotypes page of an MDG can say "Black is Black" and the Toolbox can say "Black is White".

Another example of an inconsistently incorrect system.  The only saving grace here was that we were able to use one form of inconsistency to get around another.  This isn't always guaranteed - and certainly takes more work than it should.

Paolo