Description Daniel Clarke 2016-05-10 10:18:36 EDT

Created attachment 261599 [details]
Example profile and models which show the bug.

Issue with stereotype application losing property values if set to a a stereotype from an imported package.

Example enclosed:

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.



See forum post for further info:
https://www.eclipse.org/forums/index.php/m/1731782/#msg_1731782

Reply of interest:

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

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