Bugzilla – Full Text Bug Listing
| Summary: | [Profile Import] Papyrus shall enable to import the semantics information of a UML profile defined in other tools | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Camille Letavernier <cletavernier> |
| Component: | Others | Assignee: | Camille Letavernier <cletavernier> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | papyrus-bugs, rschnekenburger, t.leouay |
| Version: | 0.10.0 | ||
| Target Milestone: | SR1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 418644, 432334, 432599 | ||
| Bug Blocks: | 410988 | ||
|
Description
Camille Letavernier
The profile attached to bug 409472 can be used as part of testing this one. In case of Profiles (Unlike other diagrams), the main difficulty lies in the semantics difference between the source and target model. The source tool only supports "uml::Class", whereas Papyrus only supports "uml::DataType". Although they are semantically equivalent (i.e., in all cases, they are converted at runtime to an Ecore::EClass, and their instances must be contained in the Stereotype: properties typed with the uml::Class or uml::DataType must have "aggregation = composition". Note that this is not explicity in Papyrus: it is done automatically during the profile definition) Anyway, the transformation of an element to a different type is not trivial (See Comment 1 in Bug 430876). So, it may be simpler to implement support for uml::Class in Papyrus Profile Diagram, and avoid this transformation from Class to DataType. The other solution would be to make a pre-transformation in Java, before the QVTo transformation, to convert all uml::Class to uml::DataType. In this case, Java is a little bit more powerful than QVTo, as it allows manipulating the metamodel and allows for "reflexive" transformations, whereas QVTo is (AFAIK, at least) limited to the model. Fixed in a808fbf (Luna), 3a67bf4 (Mars/Master) |