Community
Participate
Working Groups
Build Identifier: 20100917-0705 Moving a stereotyped Class into a QVTo transformation on an inout model remove the stereotype. Reproducible: Always Steps to Reproduce: 1. create an uml model with a stereotyped element 2. create a transformation with an uml inout model 3. add a mapping rule that move the element (for example : from a package to another) 4. run the transformation result : the element has lost its stereotype
Created attachment 184021 [details] A project example This is a project example with : - A uml model with a stereotyped element (Test.uml) - The profile used in Test.uml (Test.profile.uml) - A transformation example (movingStereotypedElement.qvto) Look into Test.uml : MyStereotypedClass is stereotyped Run movingStereotypedElement with Test.uml as parameter Look into Test.uml : MyStereotypedClass is not stereotyped anymore
(In reply to comment #1) > Created an attachment (id=184021) [details] > .... > - A transformation example (movingStereotypedElement.qvto) This transformation does not move a package, it duplicates its structure, copies its name and moves the owned types from the source package (self) to the target package (result). This is not a QVTo bug.
(In reply to comment #2) > This transformation does not move a package, it duplicates its structure, > copies its name and moves the owned types from the source package (self) to the > target package (result). Yes, this transformation does not move a package but its owned types. And if one of this owned type is stereotyped, it loses its stereotype (like the MyStereotypedClass Class in my example). This is a QVTo bug.
I stand corrected; the behavior you've observed is definitely a defect. However, it's hard to fix this defect in QVTo because the UML specification does not provide any generic way to find instances of stereotypes in a model. The consequence of this is that there is a lot of implementation-level variability in the way UML tools manage instances of stereotypes and their relationship with modeling elements. Perhaps, QVTo could provide a pluggable mechanism to inform the QVTo engine about the implementation-specific details for accessing & managing instances of stereotypes in a model. This problem is closely related to an issue I've raised against the UML at the OMG: http://www.omg.org/issues/uml2-rtf.open.html#Issue15001
Actually the problem is in script. Mapping simpleMove() creates new package thus necessary profiles need to applied to it in order to be able to contain types (UML classes) with applied stereotypes. Modified mapping (which remediates the problem) is below: mapping Uml::Package::simpleMove() : Uml::Package { name := 'topackage'; self.getAllAppliedProfiles()->forEach(p) { result.applyProfile(p); }; ownedType := self.ownedType; } Checked with QVTO from Kepler release.
