Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Papyrus/Oxygen Work Description/NewFeature/ImportRhapsody"

(Papyrus Rhapsody Plugins)
(rewrite the Incoming document, remove many line about QVTo troubles during the dev.)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Import From Rhapsody Model=
+
This documentation talks about the import of models created with the software '''IBM Rational Rhapsody''' into Papyrus. '''IBM Rational Rhapsody''' is developed by the IBM company. In this documentation, we reference this software as '''Rhapsody'''.  
The bugs used for this task are:
+
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=496175 bug 496175:  Papyrus must provide a tool to import UML Rhapsody model into Papyrus]
+
** used to trace the development itself
+
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=499237 bug 499237:  the plugin org.eclipse.papyrus.migration.rsa must be refactored]
+
** used to trace the rsa refactoring
+
  
=Requirements=
+
==Which Rhapsody version models are supported?==
*Created diagram will have a specific style to know they have been created from a Rhapsody Model. The goal of this information is to allow to target diagrams created by QVTO with DiagramReconcilier in case of bug.
+
The migration tool has been developed with IBM Rhapsody 8.0.3. Nevertheless, it should work with previous and next versions.
  
=QVTo=
+
==Where are located the Papyrus Intereoperability Rpy plugins?==
The migration fro mRhapsody model to Papyrus model has been done using QVTo. We observe some trouble/restriction using this language:
+
All Papyrus Rpy user plugins are stored in the Papyrus git ''org.eclipse.papyrus-interoperability.git'', into the subfolder ''rpy''.
*QVTo blackboxes: need to be in a dedicated plugins. We get compilation trouble if they are in the same plugin than the QVTo files (at least from the developer point of view)
+
*Stereotype application
+
**resource/resourceset: the file edited by the transformation is in an other resourceset than the object given as parameter of the transformation, so this code deosn't work:
+
<code>
+
Stereotype firstStereotype=...//(coming from a parameter of the transformation)
+
element.applyStereotype(firstStereotype);
+
element.setValue(firstStereotype,"propName", newValue);//doesn't work </code>
+
we must do :
+
<code>
+
Stereotype firstStereotype=...//(coming from a parameter of the transformation)
+
element.applyStereotype(firstStereotype);
+
Stereotype secondStereotype=element.getAppliedStereotype(firstStereotype.getQualifiedName())
+
element.setValue(secondStereotype,"propName", newValue);//works, first and secondStereotype are equals; their resource have the same URI, but 2 instance of the same resource is loaded</code>
+
  
** When do I apply stereotype ?
+
=Import From SysML Rhapsody Model=
It could seem a good idea to apply them when required in the mapping method, but it is not possible, because
+
The bugs used for this task are:
###the result of the mapping is not yet in stored in the resource, so we get a NPE (main reason),
+
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=496175 bug 496175:  Papyrus must provide a tool to import UML Rhapsody model into Papyrus]
###in some case stereotype properties reference UML object not yet mapped (or stereotype application of others objects),
+
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=496176 bug 496176:  Papyrus must provide a tool to import Rhapsody SysML Model into Papyrus]
###more complex to overide when we want extends a transformation to manage others profiles.
+
** used to trace the development itself
That's why we make a second run to apply profiles and stereotypes on the objects
+
  
* How to find easily the result of previously executed transformation
+
The documentation is now available in the Eclipse Help Contents.
**The most common usecase is to set the element (EObject) representing a View during the graphical transformation. The QVTo method called resolved required to know which mapping was used to create the semantic element. The best solution is to always call the same common method to do the mapping. 2 implementations are possible:
+
This documentation is stored into the git org.eclipse.papyrus-interoperability, at this location: '''rpy\plugins\org.eclipse.papyrus.interoperability.rpy.doc'''. It contains user documentation and developer documentation.  
***after a mapping call a dummy method used as map (key,value) to store the result of the mapping:
+
<code> mapping EObject::StoreSourceAndResult(res : EObject) : EObject {
+
            init { result := res }   
+
}
+
</code>
+
***create a common mapping from a given type in the source metamodel to the most generic type of the target metamodel. This mapping will call the good submapping using ''disjunct'' and ''when'' QVTo keyword.
+
  
 +
This feature doesn't require to have the IBM Rhapsody software installed on your computer.
  
 +
=Requirements=
 +
*Created diagrams must have a specific NamedStyled to identify them as created from Rhapsody diagrams. This NamedStyle will indicate the Rhapsody version of the initial model too. The goal of this information is to allow to target diagrams created by QVTO with DiagramReconcilier in case of bug.
 +
*Created semantic models will have a specific EAnnotation to identify them as created from Rhapsody Model. This EAnnotation will indicate the Rhapsody version of the initial model too. The goal of this information is to allow to target diagrams created by QVTO with DiagramReconcilier in case of bug.
 +
*Papyrus must provide the import for the Rhapsody SysML Internal Block Diagram.
 +
*Papyrus must provide the import for the Rhapsody SysML Parametric Diagram.
 +
*Papyrus must provide the import for the Rhapsody SysML Block Definition Diagram.
  
=Development=
+
=QVTo=
*The development is done on a dedicated branch called '''committers/vlorenzo/oxygen/496176-import-rpy''' based on the master (Oxygen) branch.
+
The migration from Rhapsody model to Papyrus model has been done using QVTo.
*Builds are associated to this branch [https://hudson.eclipse.org/papyrus/view/ImportRpy/ here]
+
*The development has been done with all required plugins in the workspace.
+
**In the first Eclipse instance, the plugin owning the QVTo files (org.eclipse.papyrus.migration.rhapsody) doesn't compile because QVTo builder isn't able to resolve dependencies when they are in the same workspace. Moreover blackboxes registered in a plugin.xml can't be resolved.
+
**We launch a 2nd Eclipse to write QVTo transformation with no compilation error
+
**We launch a third Eclipse to launch transformation and check the result
+
==Papyrus Rhapsody Plugins==
+
All Papyrus Rhapsody plugins are stored in the Papyrus git, in this path : '''extraplugins/migration/rhapsody'''
+
*'''org.eclipse.papyrus.migration.rhapsody.metamodel''', '''org.eclipse.papyrus.migration.rhapsody.metamodel.edit''', '''org.eclipse.papyrus.migration.rhapsody.metamodel.editor''':
+
**these plugins provide the EMF version of the Rhapsody metamodel used to create Models and Diagrams.
+
**The metamodel has been initially created using the Rhapsody java API, then completed using all examples provided by Rhapsody. This update has been done using the plugin '''org.eclipse.papyrus.migration.rhapsody.dev.api.discovery'''.
+
  
*'''org.eclipse.papyrus.migration.rhapsody.blackboxes''':
 
** This plugin provides some usefull blackboxes (java code). They are called by the QVTO transformations.
 
** These blackboxes can't be wrapped in the same plugins than the QVTo transformations themselves due to compilation errors (at least for developper).
 
  
*'''org.eclipse.papyrus.migration.rhapsody.geometry''':
+
=How does Papyrus Rhapsody Import work ?=
**This plugin provides objects to represent Rhapsody graphical element and manipulate them easily to get their size and their location.
+
 
+
*'''org.eclipse.papyrus.migration.rhapsody.parser''' and '''org.eclipse.papyrus.migration.rhapsody.parser.ui''':
+
** These plugins are used to parse the Rhapsody files (*rpy)
+
 
+
*'''org.eclipse.papyrus.migration.rhapsody.dev.api.discovery''':
+
**It is a developper plugin
+
**This plugin is not distributed, but it is build (a pom.xml file is provided)
+
**This plugin allow to update Rhapsody EMF metamodel when we meet models inconsistent with the current one.
+
 
+
*'''org.eclipse.papyrus.migration.rhapsody.importer''':
+
**This plugin provides the tool to parse a *.rpy file into a emf file (*.umlrhapsody) using the rhapsody metamodel provided by '''org.eclipse.papyrus.migration.rhapsody.metamodel'''
+
 
+
*'''org.eclipse.papyrus.migration.rhapsody''':
+
**This plugin uses the other plugin described previously. It takes the selected *.rpy model, convert it into a EMF model (*.umlrhapsody), then QVTo transformations are applied on this previous file to create the Papyrus model (uml, notation and di files).
+
 
+
==Papyrus Rhapsody JUnit tests==
+
Rhapsody JUnit tests are stored on the Papyrus git repository too, in the folder \tests\junit\extraplugins\migration\rhapsody.
+
===JUnit plugins===
+
*'''org.eclipse.papyrus.migration.rhapsody.tests''':
+
**This test checks if the Rhapsody shared folder owning libraries is set as Eclipse Parameter. If not we ar enot able to launch the JUnit tests
+
*'''org.eclipse.papyrus.migration.rhapsody.sysml.tests''':
+
**This plugin launches tests on the import of SysML model from Rhapsody into Papyrus.
+
 
+
==How does Papyrus Rhapsody Import work ?==
+
 
This import works in 2 steps:  
 
This import works in 2 steps:  
#we convert the '''*.rpy''' file into a '''*.umlrhapsody''' which is the same model described using the EMF Rhapsody metamodel provided by the plugin '''org.eclipse.papyrus.migration.rhapsody.metamodel'''
+
#we convert the '''*.rpy''' file into a '''*.umlrpy''' which is the same model described using the EMF Rpy metamodel provided by the plugin '''org.eclipse.papyrus.interoperability.rpy.'''
#we call the QVTO transformation themselves to import the model described in the '''*.umlrhapsody''' file into a Papyrus model (file *.uml, *.notation and *.di)
+
#we call the QVTO transformation themselves to import the model described in the '''*.umlrpy''' file into a Papyrus model (file *.uml, *.notation and *.di)
 
+
 
+
==How to register the shared Rhapsody folder==
+
This feature requires to have an access to a Rhapsody folder called '''Share'''. There are several way to define it:
+
*in the file eclipse.ini  (without quote around the path):
+
<code>
+
--launcher.appendVmargs
+
-DRhapsodyHome=C:\\Program Files (x86)\\IBM\\Rational\\Rhapsody\\8.1.3\\Share 
+
</code>
+
*in the debug configuration as VM arguments (with quotes around the path)
+
<code>
+
-DRhapsodyHome="C:\\Program Files (x86)\\IBM\\Rational\\Rhapsody\\8.1.3\\Share"
+
</code>
+
 
+
=Required changes in Papyrus=
+
Papyrus already manages the import of RSA Model. All the code of this import (QVTO transformation, Wizard Pages, Dialog, Launcher, ...) are in the plugin <code>org.eclipse.papyrus.migration.rsa</code>. Thje main part of this code is generic, so a refactoring is required to be able to reuse this code for the Rhapsody Import.
+
 
+
These changes will be done using the <code> Bug 499237: [Importer][Rhapsody][RSA] the plugin org.eclipse.papyrus.migration.rsa must be refactored<code>
+
==Changes==
+
 
+
 
+
Papyrus model rsaToPapyrusParameters (from org.eclipse.papyrus.migration.rsa/model/ui) becomes migrationParameters (in org.eclipse.papyrus.migration.common/model/ui).
+

Latest revision as of 11:20, 24 April 2017

This documentation talks about the import of models created with the software IBM Rational Rhapsody into Papyrus. IBM Rational Rhapsody is developed by the IBM company. In this documentation, we reference this software as Rhapsody.

Which Rhapsody version models are supported?

The migration tool has been developed with IBM Rhapsody 8.0.3. Nevertheless, it should work with previous and next versions.

Where are located the Papyrus Intereoperability Rpy plugins?

All Papyrus Rpy user plugins are stored in the Papyrus git org.eclipse.papyrus-interoperability.git, into the subfolder rpy.

Import From SysML Rhapsody Model

The bugs used for this task are:

The documentation is now available in the Eclipse Help Contents. This documentation is stored into the git org.eclipse.papyrus-interoperability, at this location: rpy\plugins\org.eclipse.papyrus.interoperability.rpy.doc. It contains user documentation and developer documentation.

This feature doesn't require to have the IBM Rhapsody software installed on your computer.

Requirements

  • Created diagrams must have a specific NamedStyled to identify them as created from Rhapsody diagrams. This NamedStyle will indicate the Rhapsody version of the initial model too. The goal of this information is to allow to target diagrams created by QVTO with DiagramReconcilier in case of bug.
  • Created semantic models will have a specific EAnnotation to identify them as created from Rhapsody Model. This EAnnotation will indicate the Rhapsody version of the initial model too. The goal of this information is to allow to target diagrams created by QVTO with DiagramReconcilier in case of bug.
  • Papyrus must provide the import for the Rhapsody SysML Internal Block Diagram.
  • Papyrus must provide the import for the Rhapsody SysML Parametric Diagram.
  • Papyrus must provide the import for the Rhapsody SysML Block Definition Diagram.

QVTo

The migration from Rhapsody model to Papyrus model has been done using QVTo.


How does Papyrus Rhapsody Import work ?

This import works in 2 steps:

  1. we convert the *.rpy file into a *.umlrpy which is the same model described using the EMF Rpy metamodel provided by the plugin org.eclipse.papyrus.interoperability.rpy.
  2. we call the QVTO transformation themselves to import the model described in the *.umlrpy file into a Papyrus model (file *.uml, *.notation and *.di)

Back to the top