|Re: Stereotype proprty (tagged value) from imported package [message #1731708 is a reply to message #1731698]
||Mon, 09 May 2016 12:33
|| Christian Damus
Registered: July 2009
This should work as you expect. It oughtn't to matter whether the
stereotype application references an element in the same resource or
not. In fact, if the stereotype application were stored in a
"decorator model", then all of its references to model elements would
be of this kind. So, this had better work!
If you could raise a bug with a small sample model reproducing the
problem you're seeing, that would be a great help.
On 2016-05-09 11:19:08 +0000, Daniel Clarke said:
> I'm having an issue with stereotypes. Basically, I've defined a
> profile with a stereotype (extending "Class") and created a number of
> properties. The I have created a model and applied the profile.
> In my model, if I set the stereotype property value to a type that has
> been imported from another user model (using a package import),
> whenever I update the profile and reapply the update on my model it
> resets the stereotype property (i.e. loses what it was set to).
> If I set the stereotype to a locally defined type (i.e. not one from
> an imported package) it works fine when I update the profile and apply
> I'm not sure if this is to do with the fact that the profile is applied
> before the package is imported or something? Should this be possible
> to do? Is there a workaround?
|Re: Stereotype proprty (tagged value) from imported package [message #1731842 is a reply to message #1731782]
||Tue, 10 May 2016 12:45
|| Christian Damus
Registered: July 2009
Ah, okay, now I understand more. Your stereotype doesn't have a
reference to a model *element* as such, but rather to a *stereotype* of
that model element. You wouldn't have this problem if the reference
was to the UML element that is the base type.
The reason why this is happening is that the profile applications of
both models have to be updated together. If you update only the model
containing the MyComplexType, with the reference to the base-type in
the other model, then the new version of MyComplexType requires a
reference to some instance of the new version of
MyBaseDataTypeStereotype. But the simple-type in the referenced model
still has the old version of the MySimpleType stereotype applied, so
it's not an instance of the new MyBaseDataTypeStereotype and therefore
the current value would not be valid and the reference is cleared.
To work around this, as I said, you could make the
MyComplexType::myBaseType property have type UML::DataType instead of
MyBaseDataTypeStereotype. But I can see why you might not want to do
this, because only other complex- or simple-types should be allowed as
The real problem is that Papyrus needs to be able to detect this
situation and migrate the profile applications of both models together,
which would be a new enhancement. Also, I'm not sure that the UML2 API
even allows for this case, so work might be needed there, which remains
to be determined.
So, yes, please do raise a bugzilla and attach a zip archive of these
sample models to it. That will be most helpful!
On 2016-05-10 07:19:11 +0000, Daniel Clarke said:
> I've just tried to create a simple example which shows the behaviour.
> It is actually a slightly more complicated scenario which exhibits the
> behaviour I mentioned...
> I'll describe the simple example I've constructed and I've attached
> some screenshots.
> 1) Created a profile whereby I have a extended DataType with some
> stereotypes for a "complex" and "simple" data type". The complex type
> can reference another type as its "base" type.
> 2) Created a model using this profile and defined a simple type in it
> (with the stereotype MySimpleType).
> 3) Created a second model and defined a complex type in it (with the
> stereotype MyComplexType). I've then imported the simple type from the
> first model (using a package import) and assigned this to the
> "myBaseType" stereotype property.
> If I now update the profile and reapply it to the second model, the
> "myBaseType" property value is reset to null.
> I can zip up the example (or stick it on GitHub) if that is helpful and
> raise a bug if appropriate?
> Guidance again appreciated. Thanks.
Powered by FUDForum
. Page generated in 0.01892 seconds