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.
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.
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.
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.
Because Class2 exists in JP1 and not in JP2, 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.
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.
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.
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.