Java-to-UML transformations

The Java-to-UML transformation transforms Java™ code into UML model elements.

Valid transformation sources

You can specify the following items as the source of a Java-to-UML transformation:
  • Java project
  • Source folder in a Java project
  • Java packages
  • Java classes

Valid transformation targets

You can specify the following items as a transformation target:
  • Project or folder in the workspace
  • UML model
  • Root packages
Note: If the transformation configuration implements the Reconciled Modeling design contract management protocol (DCMP), you must specify source and target elements that are valid for the Java-to-UML and UML-to-Java transformations.

If you specify a project or folder in the workspace as the transformation target, the transformation creates a new UML model in the container that you specify. The name of the model is JavaUMLModel, and a time stamp is appended to the name to ensure that the model and file name are unique. The time stamp is the system time specified in seconds; for example, JavaUMLModel1164050609968.emx.

If you specify a UML model as the transformation target, the transformation creates a temporary UML model, and compares the temporary model to the target model that you specify.

Support for custom enumerations

You can enable a UML-to-Java transformation extension to generate enumerations that preserve the name and values of the enum literals as retrievable strings. In round-trip engineering or in an iterative development environment, you can transform these custom enumerations into UML by enabling the Java to UML Custom Enumeration Extension when you configure a Java-to-UML transformation.

Support for multiple projects and their interdependencies

If you work with multiple Java projects or UML models, you can create an association file that defines associations between Java source elements and UML target elements in different projects when the elements might be outside of the scope of a transformation configuration. An association defines a link between a Java element and a UML element. A Java-to-UML association file has .xmi as a file name extension. Multiple transformation configurations can share an association file.

Each association specifies the location of a Java element and a UML element. You can specify the following Java elements in an association:
  • Project
  • Package
  • Source folder
  • JAR file
You can specify the following UML elements in an association:
  • Model
  • Package

By default, if the Java-to-UML transformation cannot create a reference to a concrete UML target element, it creates a visual reference to the corresponding Java element. If you define an association between the elements, the transformation creates a reference to a concrete UML target element and does not create a visual reference.

For example, consider a workspace that contains the following items:
  • Java projects named JP1 and JP2
    • JP2 contains a package named Package1 that contains a class named Class2
    • JP1 contains multiple JAR files and a class named Class1 that contains a reference to JP2.Package1.Class2
  • UML models named M1 and M2
  • A transformation configuration named TC1 that specifies JP1 as the transformation source and M1 as the transformation target
  • A transformation configuration named TC2 that specifies JP2 as the transformation source and M2 as the transformation target
Another user of TC1 creates an association file that contains the following Java-to-UML associations:
  • JP1 to M1
  • JP2 to M2

Because Class2 exists in JP2 and not in JP1, the first entry in the association file, although unnecessary, might be helpful to the other transformation users whose transformation configurations define these projects as source or target projects.

In this example, the transformation creates different references depending on when you apply TC1:
  • If TC1 runs before TC2, then the Java-to-UML transformation creates a reference to the concrete UML element named M2.Package1.Class2.
  • If TC1 did not run before TC2, then M2.Package1.Class2 does not exist. In this example, if an association refers to an element that does not exist, the Java-to-UML transformation creates a visual reference to JP2.Package1.Class2.

Preservation of Javadoc information from previous releases of IBM DevOps Model Architect

To preserve the information between the Javadoc tags that were generated in previous releases of the product, run the Java-to-UML transformation once to migrate the Javadoc information into the documentation property of the corresponding element in the UML model.
Note: To generate the Javadoc tags that were generated in previous releases of the product, you can modify the code templates in the Java Development Toolkit.

Comparing and merging transformation output with target UML models

The Java-to-UML transformation uses the comparing and merging functionality to determine the differences between the target model and the temporary model that the transformation generates. When you run the Java-to-UML transformation, the merge editor displays the differences between the two models. In the merge editor, you can select the changes that the transformation merges into the target model.

Filters in the merge editor

You can use the filters in the merge editor to show or hide the different types of deltas that occur when you run the Java-to-UML transformation. To simplify the view in the merge editor, click the Filters icon on the toolbar, and select the filters to apply.

For example, the transformation does not set upper and lower bounds when it transforms multiplicity elements such as attributes and parameters. In the temporary model, upper and lower bounds are set to null if no collection type is generated. If the upper and lower bounds are explicitly specified in the target UML model, even if these boundary values specify a default multiplicity of 0..1, a delta exists between the temporary model and the target model. For large models, these trivial deltas might be numerous, and make other deltas more difficult to see in the merge editor. To hide this type of delta, select the Filter out Trivial Lower and Upper Bound Changes filter.

Integration with team support

The transformation provides integration functionality with IBM® Rational® Team Concert™, CVS, Rational ClearCase®, and Rational ClearCase LT version control systems, which enables you to automatically check out files or add new files. You must enable team capabilities to work with configuration management systems.


Feedback