Relationships between UML model elements and UML-to-Java transformation output

Traceability options enable you to create relationships between a source model and the transformation output.

The options in the transformation configuration enable to you specify the type of relationship that the transformation generates between a model element and the transformation output. By default, the transformation does not create traceable relationships.

Trace relationships between source model elements and transformation output

To understand how the elements of a source model relate to the elements in a target project, you can have a transformation create trace relationships from the source model elements to the generated elements in the target project. You can then view the trace relationships in a topic diagram by creating and running model queries.

Creating trace relationships is useful in large projects that might contain multiple models and multiple transformation configurations. You can also create and run traceability queries that display how the transformation output relates to software specifications and model elements.

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. If you rename elements in the source UML model, this unique identifier enables the merge functionality to refactor and merge the appropriate elements.
Note: If you move a UML element out of the scope of its top-level class, when you rerun the transformation, the merge algorithm does not refactor or merge the renamed element because the scope of the element changed.

When you rerun the transformation, if necessary, the transformation uses the identifier in the source code to match corresponding elements and then changes the code to reflect the changes to the model. For example, if you rename a UML operation in the source model and rerun the transformation, the transformation renames the previously generated Java method and preserves the method body, instead of deleting the previously generated method and adding a new method.

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 as code refactoring instead of additions and deletions to the generated code.

To view the relationships between source model elements and the transformation output, you can visualize the source model element in a diagram and drag the code element that the transformation generates into that diagram. The following table lists the following things: the UML representation for a source model element named Class1, which contains an integer attribute named attribute1, and two operations named Operation1 and Operation2, which do not have any parameters; the code that the transformation generates; and the class diagram that shows the trace relationship between the elements.
UML element Transformation output Trace relationship in a class diagram
This image shows the UML representation of Class1, which is described in the preceding paragraph.
/**
 * 
 */
package Package1;

import java.util.Collection;

/** 
 * <!-- begin-UML-doc -->
 * <!-- end-UML-doc -->
 * @uml.annotations
 *     derived_abstraction="platform:/resource/UMLProject/Model.emx#_9YlH8CpPEdyn7_VFIWTp4A"
 * @generated "sourceid:platform:/resource/UMLProject/Model.emx#_9YlH8CpPEdyn7_VFIWTp4A"
 */
public class Class1 {
	/** 
	 * <!-- begin-UML-doc -->
	 * <!-- end-UML-doc -->
	 * @generated "sourceid:platform:/resource/UMLProject/Model.emx#__8ptgOSnEdyXH8PWExuX2g"
	 */
	private Integer attribute1;

	/** 
	 * @return the attribute1
	 * @generated "sourceid:platform:/resource/UMLProject/Model.emx#__8ptgOSnEdyXH8PWExuX2g?GETTER"
	 */
	public Integer getAttribute1() {
		// begin-user-code
		return attribute1;
		// end-user-code
	}

	/** 
	 * @param theAttribute1 the attribute1 to set
	 * @generated "sourceid:platform:/resource/UMLProject/Model.emx#__8ptgOSnEdyXH8PWExuX2g?SETTER"
	 */
	public void setAttribute1(Integer theAttribute1) {
		// begin-user-code
		attribute1 = theAttribute1;
		// end-user-code
	}

	/** 
	 * <!-- begin-UML-doc -->
	 * <!-- end-UML-doc -->
	 * @generated "sourceid:platform:/resource/UMLProject/Model.emx#_RDsjcOSnEdyXH8PWExuX2g"
	 */
	public void Operation1() {
		// begin-user-code
		// TODO Auto-generated method stub

		// end-user-code
	}

	/** 
	 * <!-- begin-UML-doc -->
	 * <!-- end-UML-doc -->
	 * @generated "sourceid:platform:/resource/UMLProject/Model.emx#_R04v0OSnEdyXH8PWExuX2g"
	 */
	public void Operation2() {
		// begin-user-code
		// TODO Auto-generated method stub

		// end-user-code
	}
}
This image shows a trace relationship, with the derive stereotype applied, between the UML representation of Class1 and the transformation output.

The transformation does not alter the source model when you specify that the transformation generate trace relationships.

Direct references between model elements and transformation output

You can instruct a transformation to create direct references between source model elements and transformation output. The transformation replaces source model elements with pointers to the transformation output. The source code that the transformation generates becomes the primary engineering artifact, and the elements in the model become visual representations of the code. This practice is useful if you want to work in the target domain instead of working with the UML model. The changes that you make to the visual representations of the objects in the model are immediately visible in the code.

Running a transformation that creates direct references between model elements and transformation output changes the source model. To avoid possible problems, you should place your source model under version control.

To realize the benefits of working in the target domain, you should create direct references when you make incremental changes to a UML model, and then convert the model into visual representations of code. If the transformation cannot transform UML elements, such as nested elements, it moves these elements to the nearest package. If the transformation cannot move a model element to the nearest package, it deletes the element.

To learn about creating direct references between model elements and transformation output, see the related tutorial for this topic.


Feedback