Professional Edition and Enterprise Edition users with version 4.1 or higher can use the UML-to-Ecore Plug-In to easily create Ecore metamodels for use in the Eclipse Modeling Framework (EMF). The contained UML elements will be mapped to Ecore elements as described in Appendix A.
To export a package to Ecore:
Select the desired package in the diagram or via the Navigation Panel.
Click the 'Ecore' button in the Properties tab of the Package.
This will add the stereotype <<ecoremodel>> and the tagged values nsURI and nsPrefix to the package. Alternatively, you can opt to add these manually.
Right-click on the package to access the context menu, then select "Export to Ecore".
Browse to the appropriate location, enter a filename, and click "Save".
(The following text is reproduced from the Eclipse Project. Please consult their website for more detailed information.)
EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Poseidon, then imported into EMF. Most important of all, EMF provides the foundation for interoperability with other EMF-based tools and applications.
EMF consists of three fundamental pieces:
EMF - The core EMF framework includes a meta model (Ecore) for describing models and runtime support for the models including change notification, persistence support with default XMI serialization, and a very efficient reflective API for manipulating EMF objects generically.
EMF.Edit - The EMF.Edit framework includes generic reusable classes for building editors for EMF models. It provides:
Content and label provider classes, property source support, and other convenience classes that allow EMF models to be displayed using standard desktop (JFace) viewers and property sheets.
A command framework, including a set of generic command implementation classes for building editors that support fully automatic undo and redo.
EMF.Codegen - The EMF code generation facility is capable of generating everything needed to build a complete editor for an EMF model. It includes a GUI from which generation options can be specified, and generators can be invoked. The generation facility leverages the JDT (Java Development Tooling) component of Eclipse.
The JAR Import Plug-in supports reverse-engineering and importing JAR archives into an existing model in Poseidon for UML. You can use and extend existing packages or frameworks in your own models, or browse and learn existing APIs. This feature is often requested by professional developers, for instance, to get a more vivid visualization of APIs than a standard Javadoc might provide.
With the RoundTrip UML/Java Plug-in you can generate Java code from your UML model, edit your code, reverse-engineer your code and synchronize with the model. Modeling and coding are not separated anymore.
The MDL Import Plug-in is now incorporated into the Embedded, Embedded Enterprise, Professional, and Enterprise editions and enables Poseidon to import UML models created by Rational Rose.
The MDL Import functionality is available from thedialog (accessible from the menu or by clicking the icon in the toolbar), which allows you to select the file type *.mdl. Unlike jar and java import, the current model is discarded and you cannot add a Rose model to your current model. You can set the scaling factor by entering a different value into the text field below the general information about the plug-in (see Display Issues). By default, the import plug-in hides the package information in Class Diagrams - long package names tend to ruin the diagram layout. If you want package names to be displayed in classes and interfaces, you may activate the check box.
This version of the import plug-in reads class, state, activity, usecase, and sequence diagrams. The other diagram types will be incorporated in the next release.
Some elements are changed during the import, others are ignored completely. Here is a list of known shortcomings:
Poseidon currently supports comments for classes, interfaces, packages, use cases, actors and states, but not for transitions, associations or objects. If a comment is not supported, it is added to the diagram as ordinary text.
Metaclass: Poseidon does not support meta classes, these classes are imported as ordinary classes.
Synchronization States: Rose does not discriminate between fork and join states. There is no way of telling how to map synchronization states - this plug-in currently always assumes fork states if the number of outgoing transitions is bigger than one. You are informed about the decision.
Subsystems: Subsystems are treated as packages - Poseidon does not support subsystems at the moment.
The following features are (at the moment) not being imported at all. You will get a warning after the import is complete that these elements will be missing.
References: MDL files support references to other files ( *.jar or *.cab files, for example). This import tool ignores references, no warning is issued.
Other problems: Some older versions of Rose have a bug in sequence diagrams: Links between objects have a wrong target ID. These links will not be resolved correctly by this plug-in - you will get an error message. Rose does the resolving by name instead of by ID, which seems rather error-prone, so we do not try to do this. Loading and saving the model with a new Rose version like Rose 2000 solves the problem, and the sequence diagram can be correctly be imported.
MDL files contain information about the diagram layout. The import plug-in reads the diagram elements coordinates and positions the diagram elements accordingly. A few things should be considered, though. Poseidon uses "smaller" coordinates than Rose. In general, scaling down the coordinates by 40 percent does the job - the diagrams almost look like they did in Rose. You can change the value in the Configuration tab to the right. If you choose 80%, for example, the diagram elements are further apart (but not bigger!) - making it easy to add comments or further elements.
While the coordinates are read from the MDL file, the sizes of diagram elements are dependent on the information being displayed. For example, a classes size depends on the length of the contained methods names and parameters. Long names or lots of parameters may lead to overlapping classes. To solve this, you can either select a higher scaling factor, or (at least for Class Diagrams) you can can edit the display options (select menu item, and click the tab ).
Poseidon performs an automatic layout of sequence diagrams - layout information contained in MDL files is ignored. Objects are currently placed arbitrarily, you might have to re-arrange them and any associated textual information. Apart from that, Rose allows activations to have arbitrary length, while Poseidon calculates the length of activations depending on the stimuli sent. Using the right mouse button, you can force an object to remain activated after the last message was sent.
We did extensive testing, and any problems during import should be signaled. But before you use and extend an imported file for production work, you should check your models and diagrams in case some model element was forgotten. If you experience problems or want to request additional features, do not hesitate to contact us - details available from the Section called Contact in Chapter 1.