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.
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 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.
| UML element | Transformation output | Trace relationship in a class diagram |
|---|---|---|
![]() |
/**
*
*/
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
}
}
|
![]() |
The transformation does not alter the source model when you specify that the transformation generate trace relationships.
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.