Bug 410987 - [Profile Import] Papyrus shall enable to import the semantics information of a UML profile defined in other tools
Summary: [Profile Import] Papyrus shall enable to import the semantics information of ...
Status: RESOLVED FIXED
Alias: None
Product: Papyrus
Classification: Modeling
Component: Others (show other bugs)
Version: 0.10.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: SR1   Edit
Assignee: Camille Letavernier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 418644 432334 432599
Blocks: 410988
  Show dependency tree
 
Reported: 2013-06-18 04:04 EDT by Camille Letavernier CLA
Modified: 2014-09-12 06:49 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Camille Letavernier CLA 2013-06-18 04:04:29 EDT 
Papyrus shall enable to import the semantics information of a UML profile defined in RSA-RTE
Comment 1 Toni Siljamäki CLA 2013-06-24 06:21:57 EDT 
The profile attached to bug 409472 can be used as part of testing this one.
Comment 2 Camille Letavernier CLA 2014-03-28 14:25:41 EDT 
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.
Comment 3 Camille Letavernier CLA 2014-09-12 06:49:06 EDT 
Fixed in a808fbf (Luna), 3a67bf4 (Mars/Master)