Migration of Rational XDE Java projects and code models

You can import three types of Rational^® XDE™ models into Rational UML modeling products. In XDE, all model types can reference each other. Learn about model closure, profile migration, and the various requirements and limitations of XDE Java™ project import.

The following table lists the three types of models that you can import:

Model type	Description
Code	These models are synchronized with the Java source code in a single Java project.
Reference	These models represent framework libraries that the Java code models reference. In most cases, these models, such as the jdk_min reference model, were created by IBM^® Rational and were part of XDE. In some instances, customers created reference models and placed them in a designated location that they define in the XDE preferences.
Content	These are UML conceptual models that are not bound to the Java code.

An XDE Java code model project contains the following two types of artifacts:

Java projects that contain Java source files
XDE Java code models.

Model closure

In Rational XDE, cross-model references exist. Code models often contain references to reference models as well as to other code models and content models. Elements in content models can contain references to elements in other content models and to elements in code models. When a set of models in an XDE workspace does not contain missing models or broken references, the set of models is considered a closure. Before you import XDE models, verify that your model sets do not have broken references because of models that are missing from their expected location in the workspace.

Profile migration

Rational XDE uses a Java RTE profile that contains stereotypes that are applied to UML model elements in all XDE code models. When you import code models using the Rational XDE model import wizard, the wizard imports the XDE Java RTE profile definition as well as the applied stereotypes in the code model.

Similarly, the Rational UML modeling products provide a profile called JavaTransformation5.0 that contains stereotypes that you can apply to UML elements to represent various Java code types and constructs. Unlike the Java RTE profile in XDE, the JavaTransformation5.0 profile is not required to use the UML-to-Java transformation capability of the UML modeling products. The JavaTransformation5.0 profile is used in the following situations:

To create a collection class such as a Java variable list or hashmap
To specify the dimension of an array

As part of the Java code model import process, the import wizard also applies the JavaTransformation5.0 profile to each imported XDE code model. This profile makes the model compatible with the Java transformation components and enables the model to participate in both forward and reverse transformations.

Note: You might see XDE properties migrated to your imported diagrams; these properties are no longer needed and they do not affect your model.

Requirements and limitations

Before you begin the process of importing Rational XDE Java code models, it is important to understand the following migration limitations.

The import process is a one-way procedure.
After you import a model into Rational UML modeling products, you cannot bring the imported model back into XDE.
The XDE Java Project Import wizard uses a lot of memory during the model import process.
You can expect the import wizard to use 1.25 times the amount of memory that is used to load the imported model in XDE. If you notice memory issues when you work with the model in XDE, you will likely encounter memory issues during the import process.
Although the compare and merge functionality is not important during the model import process, you might need to use it to maintain the imported models after migration.
XDE Web models, EJB models, and J2EE Deployment models cannot be migrated.
The Rational UML modeling products use a different approach to support Web and J2EE development, based on the use of Web-specific and J2EE-specific modeling languages and no use of UML. Before you attempt to migrate from XDE you must ensure that all XDE content models and Java code models are updated to remove any cross-model references that resolve to these type of models. Such references typically exist when depicted elements from those models exist in diagrams that are stored in the content models and Java code models.