Revision as of 06:05, 9 November 2016

Import From Rhapsody Model

The bugs used for this task are:

• bug 496175: Papyrus must provide a tool to import UML Rhapsody model into Papyrus
  • used to trace the development itself
• bug 499237: the plugin org.eclipse.papyrus.migration.rsa must be refactored
  • used to trace the rsa refactoring

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 sematnic 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 fro mRhapsody model to Papyrus model has been done using QVTo. We observe some trouble/restriction using this language:

• 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:

Stereotype firstStereotype=...//(coming from a parameter of the transformation) element.applyStereotype(firstStereotype); element.setValue(firstStereotype,"propName", newValue);//doesn't work we must do : 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

• • When do I apply stereotype ?

It could seem a good idea to apply them when required in the mapping method, but it is not possible, because

1. 1. 1. the result of the mapping is not yet in stored in the resource, so we get a NPE (main reason),
      2. in some case stereotype properties reference UML object not yet mapped (or stereotype application of others objects),
      3. more complex to overide when we want extends a transformation to manage others profiles.

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 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:
    • after a mapping call a dummy method used as map (key,value) to store the result of the mapping:

mapping EObject::StoreSourceAndResult(res : EObject) : EObject {

           init { result := res }     

}

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

Development

• The development is done on a dedicated branch called committers/vlorenzo/oxygen/496176-import-rpy based on the master (Oxygen) branch.
• Builds are associated to this branch 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:
  • 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:

1. 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
2. we call the QVTO transformation themselves to import the model described in the *.umlrhapsody 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):

--launcher.appendVmargs -DRhapsodyHome=C:\\Program Files (x86)\\IBM\\Rational\\Rhapsody\\8.1.3\\Share

• in the debug configuration as VM arguments (with quotes around the path)

-DRhapsodyHome="C:\\Program Files (x86)\\IBM\\Rational\\Rhapsody\\8.1.3\\Share"

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 org.eclipse.papyrus.migration.rsa. 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 Bug 499237: [Importer][Rhapsody][RSA] the plugin org.eclipse.papyrus.migration.rsa must be refactored<code>

Papyrus model rsaToPapyrusParameters (from org.eclipse.papyrus.migration.rsa/model/ui) becomes migrationParameters (in org.eclipse.papyrus.migration.common/model/ui).