How to stop EA "hijacking" stereotypes via API?

[Eve]

My guess is that despite it being available in the metaclasses dialog, Composition isn't a real metaclass. When you try to apply your stereotype EA says something like, "Woah there! That stereotype applies to a composition, but you've got an aggregation here. I can't apply that stereotype." (Equally, it would skip over your stereotype when search without a fully qualified name)

This would explain all the behavior you have described except for it using your stereotype when a matching stereotype exists in the db.

I can't comment on what change(s) might be appropriate without further investigation about they will impact all users.

[Paolo F Cantoni]

My guess is that despite it being available in the metaclasses dialog, Composition isn't a real metaclass. When you try to apply your stereotype EA says something like, "Woah there! That stereotype applies to a composition, but you've got an aggregation here. I can't apply that stereotype." (Equally, it would skip over your stereotype when search without a fully qualified name)

This would explain all the behaviour you have described except for it using your stereotype when a matching stereotype exists in the db.

I can't comment on what change(s) might be appropriate without further investigation about they will impact all users.

So as I understand what you're saying, notwithstanding that "Composition" is on the list, and can be used in a profile using the standard generating process it should NOT be used?

So, what is the official metamodel for specifying a Composition (Composite Aggregation - "Strong" Aggregation) rather than Aggregation (Shared Aggregation - "Weak" Aggregation) in an MDG?

We now have a process that seems to fully manage the creation of Composition arcs but it has a special test for "Strong" arc subtypes and weaves some magic to make sure that the end result is what is required.  On the way through, it changes the arc type from "Composition" - which is NOT a valid Connector Type - to "Aggregation".

However, moving forward (to a metamodel based MDG) we need to sort out a more consistent (and less heavy-handed) method.

BTW, we've found new problems with Composition - now that we have a valid install and are using StereotypeEx with the fully qualified name (and so don't appear to generate a general stereotype any more).

Confused,
Paolo

[Eve]

Neither Aggregation or Composition exist in UML 2.0+, they have been preserved in EA for legacy reasons. Of those, only Aggregation exists as an actual type in EA, where Composition is more or less an alias that is often used for a type of aggregation.

In UML, they are just (binary) associations with aggregation set.

From a strict UML perspective. Cmpstn extends association.

In EA, you can set in a profile the aggregation kind at either end to be used when creating a connector. Note that this doesn't prevent the user from changing it or update any existing connectors if the value is changed.

[Paolo F Cantoni]

Neither Aggregation or Composition exist in UML 2.0+, they have been preserved in EA for legacy reasons. Of those, only Aggregation exists as an actual type in EA, where Composition is more or less an alias that is often used for a type of aggregation.

In UML, they are just (binary) associations with aggregation set.

From a strict UML perspective. Cmpstn extends association.

In EA, you can set in a profile the aggregation kind at either end to be used when creating a connector. Note that this doesn't prevent the user from changing it or update any existing connectors if the value is changed.

Neither Aggregation or Composition exist in UML 2.0+, they have been preserved in EA for legacy reasons. Of those, only Aggregation exists as an actual type in EA, where Composition is more or less an alias that is often used for a type of aggregation.

In UML, they are just (binary) associations with aggregation set.

From a strict UML perspective. Cmpstn extends association.

In EA, you can set in a profile the aggregation kind at either end to be used when creating a connector. Note that this doesn't prevent the user from changing it or update any existing connectors if the value is changed.

Thanks for that Simon,

I guess we've been using Aggregation and Composition types also for Legacy reasons.  Never really checked it out in detail.

So, to your point about Composition (and Aggregation) extending Association, to check for Aggregation vs Composition, we have to use the DestIsAggregate value (0,1,2) yes?

It seems, as a consequence of losing the Aggregation Type, the "Set Aggregation to Composite/Shared" Context Menu item disappears.  Should It?  (just a question)

Paolo

[Paolo F Cantoni]

[BUMP]
[BUMP]

Can anyone confirm:
"It seems, as a consequence of losing the Aggregation Type, the "Set Aggregation to Composite/Shared" Context Menu item disappears.  Should It?  (just a question)"

I just want to make sure that the behaviour should be as we see it.

Paolo