Process Model

The process model comprises all processes within a model: the process is a container element for Goal or BPMN process workflows and is always part of a module. Just like a Module, a Process represents a namespace which, on runtime, results in a local process context and a process instance.

A process can contain other elements that create further nested namespaces and therefore result in further local contexts in the process instance context, such as, Sub-Process contexts.

Depending on the requirements, a process can be

• Goal-based defined in GO-BPMN with the Goal extension
• BPMN-based defined in BPMN.

When a model is instantiated it instantiates its process model: it attempts to create instances of each process in the process model including processes in module imports. For each process it firs checks whether the process is executable and whether it can be instantiated automatically. If the Process is not executable, no instance is created. If it is executable, instantiation takes place:

1. A process instance based on the process is created.
2. A process context is created.
3. The process instance becomes Running. What happens when the process instance becomes running depends on whether it is a BPMN Processes and Goal Processes.
4. On execution finish, the Process instance becomes Finished.

Process Attributes

• Executable defines whether a process can run. When false, the process never runs: when a model instance is triggering processes, either on start automatically or with another mechanism, such as, signals, the process is ignored.
• Visibility defines the access rules to the process.
• Create activity reflection type creates a record that reflects the process. The Record is the subtype of the Activity record and can then be used as a parameter of the Execute task. For further information, refer to the Standard Library documentation.

Goal Processes

The Goal-based process is a process that defines its logic in a goal hierarchy. On execution, after the parent model instance becomes running and one process instance based on the process is created, the goal hierarchy is activated:

1. Context data are created and initialized (initial values are assigned).
2. All top Goals are triggered: they become Ready and, if their conditions are fulfilled, they become running.
3. The Process instance becomes Running.
4. When no Achieve Goal is Active (Ready or Running) and no Plan is running, the Goal-based Process instance becomes Finished.

BPMN Processes

The BPMN-based process is a process that encapsulates a BPMN workflow.

It is instantiated when the parent model instance is instantiated, and that possibly multiple times by different start events. It also can be used as a Reusable Process and be instantiated as a sub-process instances.

When a BPMN-based process is instantiated, the following happens:

1. Context data are created and initialized (initial values are assigned).
2. The process instance becomes Running and its Start Event, and Activities without incoming Flow are triggered and produce tokens (the token marks the currently executed step).
3. The token leaves the start event or activity through the outgoing flows.
4. When no process element is active (there is no token in the workflow), the process instance becomes Finished.

A BPMN-based Process defines the following specific properties:

• Instantiate automatically: if false, the Process can be triggered only as a Reusable Sub-Process
• Parameters: an arbitrary number of parameters

Reusable Processes

Any BPMN-based process that starts with a None Start Event can be reused by another process by the means of the reusable subprocess activity. The activity defines the referenced process and is used in a workflow just like any other activity. However, on runtime, the entire workflow of the referenced process is executed providing a convenient mechanism for reuse of the existing workflow.

When a BPMN-based process is used exclusive as a reusable sub-process, it can be parametric.

Process Modeling