The transformation does not update or refactor code beyond the scope of the source or target that you specify in the transformation configuration. If code that is beyond the transformation scope contains references to changed model elements, you must update the code manually.
The following table lists how changes to the source UML model impact previously generated code when you rerun a transformation.
| Model element | Change | Impact on previously generated code when you rerun the transformation |
|---|---|---|
| Non-nested class or interface (includes top-level classes or interfaces) | Add | A new Java file is created. |
| Add implementation or extension | Clauses are rewritten or added. | |
| Move | The original Java file is moved to the new location as
defined in the model. The new location must be within the scope of the transformation. |
|
| Remove implementation or extension | Clauses are rewritten or removed. | |
| Rename | All instances of and references to the Java class
within the scope of the transformation are refactored. If the transformation is not configured to create trace relationships, the original generated class is deleted, and a class with the new name is created. |
|
| Attribute | Move within the hierarchy of a single UML class, including moving the attribute to or from a nested class | The Java field is moved to the new location. Getter and setter methods, if generated, are also moved. |
| Move to a new UML class hierarchy | The original field is deleted. Getter and setter
methods, if generated, are also deleted. A field is created in a Java file that corresponds to the new location in the hierarchy. |
|
| Rename | The field is renamed. If the transformation is not configured to create trace relationships, the field with the original name is deleted and a field with the new name is created. |
|
| Operation | Modify return type | The method return type is updated. |
| Modify signature | The method signature is updated to reflect
the change in the model Changes to the method body are preserved. |
|
| Move within the hierarchy of a single UML class, including moving the operation to or from a nested class | The method is moved to the new location. Changes to the method body are preserved. |
|
| Move to a different UML class hierarchy | The original method is deleted. A new method
with the same name is created in the generated Java file that represents the new location
of the method. Changes to the method body are not preserved. |
|
| Rename | The method is renamed. If the transformation is not configured to create trace relationships, the method with the original name is deleted and a method with the new name is created. Changes to the method body are preserved. |
|
| Nested class or interface | Move within the hierarchy of a single UML class, including moving to or from a nested class | The nested class or interface is moved to the
new location. Elements in the nested class or interface are preserved. |
| Move to a new UML class hierarchy | The previously generated class or interface
is removed. The new class or interface is added. |
|
| Rename | The nested class or interface is renamed in
its existing location. Nested elements are preserved. If the transformation
is not configured to create trace relationships:
|