Model-Update Processes

Model-update processes are BPMN Processes that are executed before and after the transformation of model update: They serve as hooks that prepare instantiated elements for transformation and for running after the transformation.

You can define model-update processes for Modules, Processes, Plans, Sub-Processes, and Tasks with changes in the new model. One such element can contain only one model-update process for each phase.

Only model-update processes of instantiated elements are executed, that is, the elements that hold the token or their parent elements:

• for pre-processes, the elements that were running when the model update was triggered;
• for post-processes, the elements that will be running when the instance continues running.

As mention above, the processes are define as BPMN processes with the following restrictions:

• They must start with a None Start Event.
• They can import modules, which are common for the model update phase. However, note that the imported modules do not have access to the old or new models and must import the models explicitly if necessary.

Model update processes exist in their own contexts, separated from the model instances that are updated. However, they have access to the following:

• Contexts relevant for their phase:
  • Pre-processes have access to the old model instance.
  • Post-processes have access to the new model instance.
• Contexts of their model element.

Defined for Element	Accessible Context and Namespace
Module	Module namespace
Process	Process and parents
Plan	Plan and parents
Embedded Sub-Process	Sub-Process namespace and parents; for multi-instance sub-processes also their iterator
Reusable Sub-Process	Parameters of the sub-process and parents; for multi-instance also sub-processes iterator
Task	Task parameters and parents; for multi-instance Tasks their iterator

If a name clash occurs, for example, if a pre-process context variable has the same name as a variable in the attached old model, the name in the namespace with higher priority takes precedence. The namespace priority from the highest to the lowest is as follows:

1. Local namespace of the model update process
2. Contexts of the element the model update process is attached to:
   • If on activity, the parameters of the activity
   • If on a module, process, plan, or sub-process, the namespace of the element
   • If on a multi-instance activity, the iterator of the activity
   • Imports of other modules and global model update variables

Model update processes do not have access to other model update processes. However, you can define context variables which are shared by update processes in the given update phase or use signals between model-updates of the same phase.

Pre-Processes

A pre-process is a model update process attached to a modeling element of the old model. It is executed in the pre-processing update phase if defined for an instantiated element and serves to prepare the old model instance for transformation.

Post-Processes

A post-process is a model update process attached to a modeling element of the new model. It is executed in the post-processing update phase if defined for an instantiated element that still exists in the new model and serves to prepare the new model element for running.