• Am I doing something wrong (I'm not sure I fully understand the semantics of the composition relationship between stereotypes, that is)
  
• Is this an error in the eastadl profile, or is this something that only works when using static profiles?
  

Hi, Klaas,
Are you saying that this actually does work for statically-generated
profiles? That you are having this problem only with a dynamic
profile? From a UML2 API perspective, there should be no difference in
behaviour ...

This probably doesn't help you any. :-/

A f'up:

It is very likely that the reason hitting the 'plus' button gives you
these "undefined" stereotype applications is because it reflectively
creates the stereotype applications (instances of the ClassStereotype
EClass in the profile's Ecore definition) without setting the
base_Class reference, which indicates the UML Class element to which
the stereotype is applied.

  <TestStereotypeCompositionProfile:ClassStereotype xmi:id="_mJbsEFbUEeOp5tUi3kbX5A" base_Class="_StRDwFbTEeOp5tUi3kbX5A" Attribute1="true" friend="_nzQwoFbUEeOp5tUi3kbX5A" Attribute2="5" name="Stereo applied to Class1">
    <child xmi:type="TestStereotypeCompositionProfile:ClassStereotype" xmi:id="_Y0WsYFgIEeOz0J84aBntog"/>
    <child xmi:type="TestStereotypeCompositionProfile:ClassStereotype" xmi:id="_ZlspwFgIEeOz0J84aBntog"/>
  </TestStereotypeCompositionProfile:ClassStereotype>

• Indeed, no base_class reference is set as you stated above
  
• The stereotype with name "Stereo applied to Class1" does have an attribute "friend", but _no_ attribute "child"!
  

• I didn't even succeed in applying a stereotype via the UML model editor from the UML2 project
  
• I don't really know what the expected behaviour should be (see below)
  

I think that having a 'plus' button to create new instances in this
case either should

* bring up the Apply Stereotype dialog to apply the <<ClassStereotype>> to
some Class in the model and then put the resulting stereotype
application in
the classStereotype collection of the containing stereotype application

* let the user pick an existing application of the
<<ClassStereotype>> stereotype
to move into the containment collection (but this then confuses
the semantics
of the 'plus' button with the usual new-object-creation semantics)

* just not be allowed (i.e., there should be no '+' button in this
case, but something
else that makes it clear that a stereotype application would be moved from
some other container)

I hope that made sense.

> Am I doing something wrong (I'm not sure I fully understand the
> semantics of the composition relationship between stereotypes, that is)

1. Is it mere "containment" as you seem to suggest above? In that case, the only difference between a composition association and a normal assocation in a profile would be that deleting the stereotype on a "parent" Class would result in the deletion of the stereotype on a child, but not of the child itself, right?
   
   
   
   
   
2. Or is it more like there should be a composition relationship between the base_Elements too (in this case stereotype composition could only be used correctly on base_Elements that support composition themselves (e.g. not on properties)
   
3. Or ...
   

On 2013-11-28 11:01:28 +0000, Klaas Gadeyne said:
> Christian W. Damus wrote on Tue, 26 November 2013 16:34

> However:
>
> I didn't even succeed in applying a stereotype via the UML model
> editor from the UML2 project
> I don't really know what the expected behaviour should be (see below)

If the profile is applied to the contextual package, then you should be
able to use the "UML Editor -> Element -> Apply Stereotype..." action
to apply the stereotype to an element within that package. What are
you seeing that isn't working?

[snip]
> What's the meaning of the composition relationship between stereotypes?

[snip "mere containment" part]
> Or is it more like there should be a composition relationship between
> the base_Elements too (in this case stereotype composition could only
> be used correctly on base_Elements that support composition themselves
> (e.g. not on properties)

No, I don't think so. A constraint such as this would have to be
expressed explicitly via OCL or some such. The structure of a
stereotype is independent of its base element.

Note, in particular, that it should be possible to define stereotype
containment relationships that cannot be mirrored by the elements they
extend. For example, suppose a stereotype of Class contains
stereotypes of Dependency, where the contained stereotypes are applied
to the class's client dependencies. The class doesn't own those
dependencies; its package does.

> Unfortunately, googling for "stereotype composition" doesn't bring a
> lot of useful stuff here it seems...

That is not a surprise. I haven't encountered many use cases for it ...

> Maybe the more interesting (yet basic??) question is this: If you
> create a meta-model in which a certain concept has a composition
> relationship towards another concept, what is/are the way(s) to map
> this onto a UML profile? And to what extent is the "containment"
> relationship (see 1/ above) useful for such a scenario?

I would tend to prefer mapping the containment of those concepts to
available containments in the UML metamodel. I actually have some
experience in tooling that does this kind of metamodel-to-profiled-UML
transformation for DSLs, and this was one element of my mapping
algorithm.

So, in your example, I would first see how well mapping the 'child'
relationship to Class::nestedClassifier works before actually
implementing it as a composite association in the stereotype. However,
I do see some usefulness of the stereotype composition in cases like
the dependencies as I described above, where there isn't a suitable
mapping in the UML metamodel.

It is interesting that in your example Class2 and Class4 are not nested
in Class1, but simply related by composite associations. This is
actually more like the dependencies case, because the Class1 would not
typically own its assocations (its containing package would). So,
perhaps the stereotype composition is a good approach here.

It is worth noting that a sensible UML tool would delete those class2
and class4 associations when Class1 is deleted. Also, the UML2 API
destroys the stereotypes applied to Class1 when it is deleted, so (as
above) that also results in Class2 and Class4 losing their stereotype
applications. That may not be what you want, so it is a consideration
in choosing whether the ClassStereotype::child property should be
composite or not.

1. Map it onto the class::nestedClassifier relationship. This would work, if one would use a class diagram. The disadvantage here is that one looses the semantic link between an (abstract) feature and a (concrete) property of the system \[*\].
   
2. Map it onto a UML composition relationship. A lot less clean and very ugly, since there is no 'property' of the type feature and there is no "automatic destruction"...
   

A f'up:

It is very likely that the reason hitting the 'plus' button gives you
these "undefined" stereotype applications is because it reflectively
creates the stereotype applications (instances of the ClassStereotype
EClass in the profile's Ecore definition) without setting the
base_Class reference, which indicates the UML Class element to which
the stereotype is applied.

I think that having a 'plus' button to create new instances in this
case either should

* bring up the Apply Stereotype dialog to apply the <<ClassStereotype>> to
some Class in the model and then put the resulting stereotype
application in
the classStereotype collection of the containing stereotype application

* let the user pick an existing application of the
<<ClassStereotype>> stereotype
to move into the containment collection (but this then confuses
the semantics
of the 'plus' button with the usual new-object-creation semantics)

* just not be allowed (i.e., there should be no '+' button in this
case, but something
else that makes it clear that a stereotype application would be moved from
some other container)

I hope that made sense.

cW