Transformation is the main phase of model update: the record instances, variables, and asynchronous model elements that were instantiated before the model instance was suspended for model update and are changed in the new model are transformed to their version for the new model.

Schema of transformation

The way they are transformed is define by transformation rules in the model update definition.

For example, it is not necessary to define transformation on a function definition, since it is called and returns an output in one step. If a function is modified in the new model, the function is simply substituted with the new implementation and next function call uses the model instance the new function. Also, if you delete a variable in the new model, the variable is simply removed and no other action is required. However, if you change the type of a record field on a record, any values of variables of the record type must be transformed accordingly.

Record Transformation

Record transformations are defined for record fields of basic data types that have been added or changed in the new model as the transformation expression: the expression return the value for the new record field instance.

If a record has a supertype, it inherits the transformation expression. If it defines its own transformation expression, the transformation expression of its supertype is ignored.

Important: It is not possible to transform the type of a Shared Record field since this requires database migration.

The evaluation is performed for each field instance in the context of the new model instance; To refer to the values in the original model instance, use the old() function call: the function takes a string expression that resolves into the name of the record property.

Example: The old() function call syntax

old(<STRING_EXPRESSION>)

Variable Transformation

Variable transformations are defined for variables that have been changed in the new model. The transformation expression returns the new variable value. Note that variable transformation can be influenced also by the transformation on the records. Therefore, on model update transformation, the variable is transformed according to the variable transformation expression. If such an expression is not defined, it is transformed according to the record transformation.

Asynchronous Modeling Elements Transformation

Asynchronous modeling elements that can be running when model update is triggered and exist in the new model must define their transformation strategies. Deleted or added asynchronous elements do not require any special actions on model update.

If you remove an asynchronous model element from the new model and the element was running when model update was triggered, the Start Event of its parent activity becomes running when the model instance resumes (the token from the deleted element is moved to the closest Start Event).

Transformation of asynchronous elements is performed as follows:

The transformation of modified data types and variables is applied on all instances of the element.
The transformation defined on asynchronous model elements is applied on the elements that were running before or will be running after the model update.

Goals and elements with atomic execution semantics do not define Transformation strategy since they cannot hold a token and can be only deleted or have their parameter values modified. The behavior of goal structures on model update is described in Goal Hierarchy Update.

Transformation Strategies

The transformation strategy specifies how an instantiated asynchronous element that is changed in the new model and was running when model update was triggered or will be running after the model update, is handled.

The following model elements must define their transformation strategy if modified in the new model:

Processes
Plans
Activities

The strategy can be set to restart or continue:

restart: If the element was running when the model update was triggered or will be running after the update, the context of the element is discarded and created anew.
continue: If the element was running when the model update was triggered or will be running after the update, the context is preserved.

Transformation strategy semantics

The strategies are applied in a top-down manner: If a task in a sub-process has its strategy set to continue and the subprocess has its strategy set to restart, the continue strategy of the task will be never applied, since the parent subprocess will be always restarted if its content is running.

Goal-Hierarchy Update

Since Goal hierarchies need to be updated in a way which preserves the status of the Goals and adjusts it if necessary so that the hierarchy is consistent.

On transformation, the statuses of matched Goals are preserved and the following rules are applied:

If a Goal is decomposed in Plans and at least one of the Plans is running, the Goal becomes running.
If a Goal is inactive and its parent is deactivated, it becomes deactivated as well.