Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Stereotype composition
Stereotype composition [message #1212212] Tue, 26 November 2013 20:25 Go to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi,

Consider the following stereotype definition
index.php/fa/16837/0/

When I define a profile like this, and create a model to test it, it doesn't seem to work. When trying to fill in the classStereoType property, I cannot select any existing model objects. Pressing + below results in "undefined" entries as shown in the screenshot below.

index.php/fa/16838/0/

However, I noticed that this construction is also used in the eastadl profile, notably for the safetyCase stereotype. When I try to use this profile (dynamically), I do get the same error as above. So I wonder


  • 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?


Re: Stereotype composition [message #1212324 is a reply to message #1212212] Tue, 26 November 2013 21:26 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1206
Registered: July 2009
Location: Canada
Senior Member

Hi, Klaas,

It is entirely possible that the UML2 API does not support stereotype
composition, though I'm not sure why it wouldn't. Certainly, I don't
think the UML-to-Ecore transformation would have a problem with such
references and the determination of the stereotype applications of a
UML element doesn't care what contains them (whether a Resource or some
other stereotype application).

In any case, the UML2 API will by default put a new stereotype
application in the contents-list of the resource containing the UML
element to which it is applied. It would be up to the host tool (in
this case, Papyrus) to provide a UI that lets you *move* this
stereotype application from the resource into the 'classStereotype'
reference of some other <<ClassStereotype>> application. I should have
thought it would work in Papyrus for compositions as it does for
non-composite associations (simple references). Note that I have never
tried any scenario like this ...

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. :-/

Christian


On 2013-11-26 20:25:30 +0000, Klaas Gadeyne said:

> Hi,
>
> Consider the following stereotype definition
>
>
> When I define a profile like this, and create a model to test it, it
> doesn't seem to work. When trying to fill in the classStereoType
> property, I cannot select any existing model objects. Pressing + below
> results in "undefined" entries as shown in the screenshot below.
>
>
>
> However, I noticed that this construction is also used in the eastadl
> profile, notably for the safetyCase stereotype. When I try to use this
> profile (dynamically), I do get the same error as above. So I wonder
>
>
> 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?
>
>
>
> <image>
> <image>
Re: Stereotype composition [message #1212334 is a reply to message #1212212] Tue, 26 November 2013 21:34 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1206
Registered: July 2009
Location: Canada
Senior Member

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


On 2013-11-26 20:25:30 +0000, Klaas Gadeyne said:

> Hi,
>
> Consider the following stereotype definition
>
>
> When I define a profile like this, and create a model to test it, it
> doesn't seem to work. When trying to fill in the classStereoType
> property, I cannot select any existing model objects. Pressing + below
> results in "undefined" entries as shown in the screenshot below.
>
>
>
> However, I noticed that this construction is also used in the eastadl
> profile, notably for the safetyCase stereotype. When I try to use this
> profile (dynamically), I do get the same error as above. So I wonder
>
>
> 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?
>
>
>
> <image>
> <image>
Re: Stereotype composition [message #1216114 is a reply to message #1212324] Thu, 28 November 2013 10:23 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
[snip]

Christian W. Damus wrote on Tue, 26 November 2013 16:26
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 ...


No, just that I didn't test it so far. I was assuming that, if the east-ADL profile was implementing stereotype composition, that it should have been supported in some way. However, I now installed the papyrus eastADL extra component, and it shows exactly the same (erroneous) behaviour.

Quote:

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


At least it gave me some direction to search in, so thanks (and see follow-up post for more details)!

Klaas
Re: Stereotype composition [message #1216184 is a reply to message #1212334] Thu, 28 November 2013 11:01 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Christian W. Damus wrote on Tue, 26 November 2013 16:34
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.



True!

When I define the profile below
index.php/fa/16880/0/
and apply it to a testmodel
index.php/fa/16881/0/
index.php/fa/16882/0/

The resulting serialised (part of the) UML file looks like

  <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>


So

  • 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"!

there is clearly something going wrong here Sad

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)



Quote:

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.


Well, in order to assess whether that's a sensible behaviour, I would like to come back to one of my original concerns:

Quote:

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


What's the meaning of the composition relationship between stereotypes?

  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 ...


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

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?

(Jeezes, this is getting long Smile
Re: Stereotype composition [message #1216691 is a reply to message #1216184] Thu, 28 November 2013 15:37 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1206
Registered: July 2009
Location: Canada
Senior Member

Hi, Klass,

See some replies in-line, below.

cW


On 2013-11-28 11:01:28 +0000, Klaas Gadeyne said:

> Christian W. Damus wrote on Tue, 26 November 2013 16:34
>> 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.
>
>
> True!
>
> When I define the profile below
>
> and apply it to a testmodel
>
>
>
> The resulting serialised (part of the) UML file looks like
>
>
> <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>
>
>
> So
>
> 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"!
>
> there is clearly something going wrong here :(

The 'child' property in the Ecore representation of the stereotype is a
containment reference, so the ReflectiveItemProvider employed by the
UML Editor to present the stereotype application will not show it in
the property sheet. Containment references are only presented (by
default) in the tree viewer.


>
> 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?

-------- 8< --------

> Well, in order to assess whether that's a sensible behaviour, I would
> like to come back to one of my original concerns:
>
> Quote:
>>> Am I doing something wrong (I'm not sure I fully understand the
>>> semantics of the composition relationship between stereotypes, that is)
>
>
> What's the meaning of the composition relationship between stereotypes?

That is a very good question! I have struggled, myself, to understand
why it would be useful.


> 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?

"Mere containment" is the only semantics that we can expect to get from
the UML-to-Ecore transformation involved in the EMF-based
implementation of UML Profiles. So, yes, unapplication of this
stereotype from some element in your model *will* eliminate all
stereotype applications that it contains, because part of the process
of unapplication is to "destroy" the stereotype application that has
been unapplied. UML's "destroy" semantics includes:

* removing the destroyed object (element or stereotype application) and its
subtree from the model content
* deleting all inbound references to the destroyed object and its subtree
* deleting all outbound references from the destroyed object and its subtree

The last point above is crucial: this deletes all base_Xyz references
in the tree of stereotype applications, effectively unapplying all
contained stereotypes as well.

So, in this respect, I think the traditional semantics of composition
are respected: when an "instance" of the stereotype is destroyed, so
are all of the "instances" of stereotypes that it contains.


> 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.


> Or ...
>
>
> 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.


>
> (Jeezes, this is getting long :)

Not at all. This is a very useful discussion!


>
> <image>
> <image>
> <image>
Re: Stereotype composition [message #1217207 is a reply to message #1216691] Thu, 28 November 2013 20:44 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi,

I tried to snip as much as possible to keep stuff readable (it also means that I understood you or that I agree Smile

Christian W. Damus wrote on Thu, 28 November 2013 10:37

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?


This works, I didn't try it via the UML Editor menu Sad, I only tried the contextual menu for the UML model elements...


Quote:

[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.


I can understand this (and the example) technically, although I cannot judge for this example whether it makes sense to contain the dependency stereotypes in the class stereotypes (probably because I cannot guess what meta-model would be behind this profile definition).

Quote:

> 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 ...


not many = none?

Quote:

> 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.


_very_ interesting! I didn't even know such tooling existed! Could you point me to more information about it, or was it something confidential?

Quote:

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.


Well I do see a problem here, and that is that one thing we haven't mentioned but which is in my opinion also an important parameter in the mapping exercise is the UML concrete graphical syntax.
But let's try again to make it a little more concrete (the above example was actually only constructed to illustrate the problems I had in papyrus (and, as it seems at first sight, also with the uml2 editors) that I encountered when I tried to use stereotype composition. Maybe it's time to take a step back.

Let's suppose I want to create a UML profile implementation of (cardinality-based) feature diagrams [http://en.wikipedia.org/wiki/Feature_model#Cardinality-based_feature_models] and my meta-model looks like
index.php/fa/16891/0/

Semantically, features could be regarded as abstract _properties_ of a system (class) and hence one could create a feature stereotype that extends uml::property. Moreover, as a uml::property is associated with an upper and a lower bound, it rather also maps well with the MultiplicityInterval containment relationship.
One could then use the composite structure diagram to represent feature trees.

One (of the) remaining hurdle(s): The child containment reference. As you can see at [http://en.wikipedia.org/wiki/File:E-shopFM.jpg], "bank transfer" and "credit card" are both children of the payment feature, but they are not contained (encapsulated) in the uml sense of containment if I understood it correctly. Meaning, if payment is deleted, both bank transfer and credit card should be deleted, but both are _not_ encapsulated in payment (at least not in the graphical concrete syntax of the feature diagrams).

As far as I can see, UML properties have one containment relationship to themselves: qualifier (uml 2.5 beta 1 page 152). However, I don't really understand it semantics, and at least in papyrus I could not drag (contained) qualifier onto a composite structure diagram.
This is where my idea of using a composition relationship in the stereotype entered the picture. However, I now came to the conclusion that it's not what I want in this case. Indeed, in this way it will _never_ be possible to delete "bank transfer" and "credit card" if payment is deleted.

Option two: map feature onto uml::class. Semantically further apart, one also needs to create a mapping for the MultiplicityInterval element (and this also means more work for the 'modeller' of the feature diagrams). For the containment, one could see two options here

  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"...


So, none of the solutions is really satisfactory. I guess 1/ above comes closest.
(Now, if your transformation can take this all into account and come up with a real good solution, that would be really _amazing_ (to a mere mortal as myself at least)!)
ps. A different conclusion could also be that trying to map this DSL onto UML fails Smile

[*] This would probably lead us too far, but think for instance about OCL constraints that link the (value of) the abstract feature properties to the (value of) the concrete 'implementation' properties.

Thx for the explanation!



Re: Stereotype composition [message #1217225 is a reply to message #1212334] Thu, 28 November 2013 20:54 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Christian W. Damus wrote on Tue, 26 November 2013 16:34
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


Annex:

The discussion somewhat went in another direction, but if the '+' would stay as it is, the first bullet makes most sense to me (damned, yet another feature request to submit Smile. For me the '+', doesn't work either with non-composite associations (but IIRC, that might be a mac os x specific bug, will verify).

The second bullet would maybe be more inline with the '...' button indeed.

Re: Stereotype composition [message #1219145 is a reply to message #1217225] Mon, 02 December 2013 11:15 Go to previous message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Submitted as https://bugs.eclipse.org/bugs/show_bug.cgi?id=422934
Previous Topic:Not possible to install Papyrus
Next Topic:"Unexpected error" when adding a guard in UML AD
Goto Forum:
  


Current Time: Wed Jul 08 03:40:39 GMT 2020

Powered by FUDForum. Page generated in 0.02563 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top