UML-to-Java transformations

The UML-to-Java transformation transforms UML model elements into Java™ code, and generates code that is compatible with the Java 2 Platform, Standard Edition 1.4 (J2SE 1.4) and the Java 2 Platform, Standard Edition 5.0 (J2SE 5.0).
Important: The UML-to-Java 1.4 transformation is deprecated, and is now called the UML-to-Java (deprecated) transformation. No functionality is being added to the UML-to-Java (deprecated) transformation, and the transformation behavior is different from the UML-to-Java 5.0 transformation, which is now called the UML-to-Java transformation. You should use the UML-to-Java transformation, whether an application contains code that is compatible with Java 2 Platform, Standard Edition (J2SE) 5.0 or J2SE 1.4 or later.

Valid transformation sources

The UML-to-Java transformation generates Java classes from the following UML sources:
  • UML models
  • Packages and their contents
  • Non-nested classes and their contents
  • Non-nested interfaces and their contents
  • Non-nested enumerations

The transformation transforms the contents of UML models, packages, classes, and interfaces. For example, when the transformation transforms a class, the transformation also transforms the operations and properties of the class.

If you select a model or model elements in the Project Explorer view instead of using the Transformation Configuration editor, the model or elements that you select override the source model or elements that you specify in the transformation configuration. The transformation configuration is not affected and the source that you specify on the Source and Target page of the transformation configuration editor or the New Transformation Configuration wizard does not change.

Valid transformation targets

You can specify a Java project, or a source folder in a Java project, as the destination for the output of the UML-to-Java transformation.

Alternate names for generated output

You can create a mapping model to specify alternate names for the elements that the transformation generates, without modifying the source model. You might specify alternate names if you want to include Java-specific details, such as naming restrictions in platform-independent models, or if the logical organization of the source model is not appropriate as target packaging.

You can specify a qualified name such as com.ibm.NewName or an unqualified name such as NewName. Specifying alternate names for packages affects all classifiers in that package, unless the classifier specifies a fully qualified name. You can also specify alternate locations in the same project for elements that the transformation generates.

Parameterized types that the UML-to-Java transformation supports

You can specify the following Java collection types as the generic interface for parameterized types, or generics, when you create or configure a UML-to-Java transformation:
  • AbstractCollection
  • AbstractList
  • AbstractMap
  • AbstractSequentialList
  • AbstractSet
  • ArrayList
  • BitSet
  • Collection
  • HashMap
  • HashSet
  • Hashtable
  • LinkedList
  • List
  • Map
  • Set
  • SortedMap
  • SortedSet
  • Stack
  • TreeMap
  • TreeSet
  • WeekHashMap
  • Vector

The transformation does not generate parameterized type information for other Java collections.

Annotation of Java source code with UML collection information

If you do not configure the transformation to generate code that is compatible with the J2SE 5.0, the UML-to-Java transformation adds comments about UML collection types to the Java collection types that it generates. These comments enable the visual development tools to create accurate visual representations of the Java collection types.

If you specify a multiplicity of * on a UML attribute and you do not change the Java collection information in the transformation configuration, by default, the UML-to-Java transformation generates a Java set.

The following table shows an example of an association relationship between Class1 and Class2; the association relationship specifies a multiplicity of 1..*. The table also shows excerpts of the source code that the transformation generates using the default values in the transformation configuration, and the visual representation of the association relationship. Assume that the transformation is not configured to create trace relationships between source model elements and generated code.
UML elements UML-to-Java transformation output Visual representation of transformation output
This image shows UML model elements named Class1 and Class2, with an association relationship  that specifies a multiplicity. The transformation generates the following source code if you clear the Use Java 5 check box in the transformation configuration:
public class Class1 {
	/** 
	 * <!-- begin-user-doc -->
	 * <!-- end-user-doc -->
	 * @uml.annotations for <code>class2</code>
	 *     collection_type="Package1.Class2"
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	private Set class2;
}
This image shows the visual representation of Class1, which contains a  collection of  Class2 classes.
The transformation generates the following source code if you select the Use Java 5 check box in the transformation configuration:
public class Class1 {
/**
*
*
* @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
*/
private Set<Class2> class2;
}</Class2>
If you run the Java-to-UML transformation using the generated code in the above example as the transformation source, it generates the following items:
  • In Class1, the transformation generates a UML attribute called class2 with the «JavaCollection» stereotype applied; the collectionType property is set to java.util.Collection, and the multiplicity is set to *.
  • In Class2, the transformation generates a UML attribute of type Class called class1, with a multiplicity set to 1, and no stereotype applied.

The following image shows the visual representation of the UML class that the Java-to-UML transformation generates:

This image illustrates the example described in the previous paragraph.

Documentation of relationships in transformation output

The UML-to-Java transformation transforms UML relationship documentation into Javadoc information for the following UML relationships:
  • Associations
  • Generalizations
  • Implementations
  • Realizations
To transform usage relationship documentation into Javadoc information, you must configure the UML-to-Java transformation to generate J2SE 5.0 code.

The transformation adds documentation for generalization, implementation, and realization relationships to the UML documentation for the originating class in each relationship. The transformation also adds the documentation for these relationships to the Javadoc information for the generated target class of each relationship.

For associations, the transformation adds the UML documentation to the documentation of each associated property.

Modeling of Java exceptions

In a UML model, you can use a UML operation to represent a Java method. In the RaisedException property of a UML operation, you can specify the UML classes that represent the exception objects that are associated with the operation. When you run the UML-to-Java transformation, the transformation generates a Java throws statement that contains the classes that you specify in the RaisedException property.

Preservation of Java keywords

Several Java keywords, such as strictfp, native, transient, and volatile, cannot be represented in a UML model. To preserve these keywords when you run the UML-to-Java transformation, or the UML-to-Java transformation, you should model these keywords as UML keywords.

Visual representations of generated Java elements

If you want the output of the UML-to-Java transformation to be the primary engineering artifact, you can specify that the transformation create a direct relationship between the source UML objects and the generated Java code. Creating direct relationships deletes the source UML objects and replaces them with visual representations of the source objects.

Trace relationships

The UML-to-Java transformation enables you to create trace relationships from UML source model elements to the generated Java classes. You can then view the trace relationships in a topic diagram by creating and running model queries.

Model element identifiers in transformation output

When you run a transformation that is configured to create trace relationships, for each element that supports the @generated tag, the transformation appends a unique identifier to the @generated tag. This identifier specifies the UML model element from which the Java element was generated, as in this example: * @generated "sourceid:platform:/resource/UMLProject/SimpleModel.emx#_83GpoBtIEdyLaOwyRX_ZMQ". If you rename elements in the source UML model, this unique identifier enables the merge functionality to refactor and merge the appropriate elements.

The Java-to-UML, or reverse, transformation can also use the identifiers to match corresponding elements between the Java project and the UML model. If applicable, changes to the Java source code elements are treated as modifications or code refactoring instead of additions and deletions to the generated code.

Integration with team support

The UML-to-Java transformation provides integration functionality with 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.

Related concepts
Relationships between UML model elements and UML-to-Java transformation output
Related tasks
Transforming UML models into Java code
Applying the UML-to-Java transformation profile
Specifying exceptions in UML operations
Specifying sources and targets for UML-to-Java transformations
Specifying the Java collection types that UML-to-Java transformations generate
Creating trace relationships between UML source model elements and UML-to-Java transformation output
Enabling team capabilities
Related reference
Interpretation of UML elements by UML-to-Java transformations

Feedback