Process Instances
Process models define restrictions on process instances that belong to the
process model. Therefore, it is essential to properly define not only process
models but also process instances. Modelling process instances is not an easy
task, because of their intangible nature. A process instance is started, and it
lives for a limited time period before it ceases to exist, similarly to activity
instances.
A process instance consists of a number of activity instances as well as
event and gateway instances. The ordering relationships of activity instances
in a process instance is defined by the relationships of the activity models in
the process model.
For instance, if a process model defines an execution ordering constraint
between activity models A and B, then for each particular process instance,
the activity instance that belongs to activity model A must have terminated
before the activity instance for B can be started.
An extension of the process metamodel discussed above is presented in Figure
3.17. There are additional classes for process instances and node instances
that are a generalization of activity instances, events, and gateway instances.
There are one-to-many relationships between the respective concepts at the
model level and at the instance level, as shown in the metamodel.
Each process instance is associated with exactly one process model, and
each process model is associated with an arbitrary number of process instances.
Each process instance is composed of an arbitrary number of activity
instances. Each activity instance is associated with exactly one activity model.
The same holds for events and gateways.
Note that each activity model is associated with an arbitrary number of
activity instances. In the case of loops, an activity model is associated with
multiple activity instances. An activity model that lies on a branch that is
not taken during a particular process instance is not associated with any
activity instance, explaining the cardinality of the association * that allows
zero occurrences of the association, i.e., there might be activity models in a
process model for which no activity instances are required for a particular
process instance.
After introducing events and event orderings to represent activity instances,
this section looks at events and event orderings that occur during
the enactment of process instances. Process models restrict for a process instance
the events and event orderings of its activity instances by imposing
execution constraints, such as sequential execution of activity instances. Execution
constraints need to be satisfied by all process instances based on a
particular process model.
The execution constraints can be precisely specified by events and their
ordering. For example, the execution constraint A ! B dictates that the start
event of the activity instance corresponding to B can only happen after the
termination event of the activity instance corresponding to A. This is the
basic idea of characterizing the execution semantics of process instances.
To illustrate these concepts, a process instance based on the process model
shown in Figure 3.15 on page 91 is investigated. Each process instance based
on this process model starts with an analyze order activity. Depending on
a decision, either the simple check activity or the advanced check activity
is enacted. This process model makes room for different process instances.
Depending on the decision made at the gateway node, either the simple check
activity instance or the advanced check activity is executed.
Event diagrams are also useful for capturing process instances. The event
diagram of a particular process instance is shown in Figure 3.18, where a
process instance is shown during which the simple check activity instance is
selected.
When the process starts, activity instances for all three activity models
are generated. In event diagrams, the subscripts of the init, enable, terminate, and skip events can be omitted, if the activity instance to which the event
belongs is clear.
The start event is represented by the event node N1 in the process model.
The occurrence of this event is represented in the event diagram by event n1.
Once this event has occurred, the AnalyzeOrder activity instance can start,
i.e., it can enter the ready state, represented by an enable event.
When the AnalyzeOrder activity instance terminates, (1) the AdvCheck
activity instance is no longer required, so that a skip event occurs for this
activity instance, and (2) the SimpleCheck activity instance is enabled, so
that it can start. When this activity completes, the final event n7 of the
process instance occurs.
Process models define restrictions on process instances that belong to the
process model. Therefore, it is essential to properly define not only process
models but also process instances. Modelling process instances is not an easy
task, because of their intangible nature. A process instance is started, and it
lives for a limited time period before it ceases to exist, similarly to activity
instances.
A process instance consists of a number of activity instances as well as
event and gateway instances. The ordering relationships of activity instances
in a process instance is defined by the relationships of the activity models in
the process model.
For instance, if a process model defines an execution ordering constraint
between activity models A and B, then for each particular process instance,
the activity instance that belongs to activity model A must have terminated
before the activity instance for B can be started.
An extension of the process metamodel discussed above is presented in Figure
3.17. There are additional classes for process instances and node instances
that are a generalization of activity instances, events, and gateway instances.
There are one-to-many relationships between the respective concepts at the
model level and at the instance level, as shown in the metamodel.
Each process instance is associated with exactly one process model, and
each process model is associated with an arbitrary number of process instances.
Each process instance is composed of an arbitrary number of activity
instances. Each activity instance is associated with exactly one activity model.
The same holds for events and gateways.
Note that each activity model is associated with an arbitrary number of
activity instances. In the case of loops, an activity model is associated with
multiple activity instances. An activity model that lies on a branch that is
not taken during a particular process instance is not associated with any
activity instance, explaining the cardinality of the association * that allows
zero occurrences of the association, i.e., there might be activity models in a
process model for which no activity instances are required for a particular
process instance.
After introducing events and event orderings to represent activity instances,
this section looks at events and event orderings that occur during
the enactment of process instances. Process models restrict for a process instance
the events and event orderings of its activity instances by imposing
execution constraints, such as sequential execution of activity instances. Execution
constraints need to be satisfied by all process instances based on a
particular process model.
The execution constraints can be precisely specified by events and their
ordering. For example, the execution constraint A ! B dictates that the start
event of the activity instance corresponding to B can only happen after the
termination event of the activity instance corresponding to A. This is the
basic idea of characterizing the execution semantics of process instances.
To illustrate these concepts, a process instance based on the process model
shown in Figure 3.15 on page 91 is investigated. Each process instance based
on this process model starts with an analyze order activity. Depending on
a decision, either the simple check activity or the advanced check activity
is enacted. This process model makes room for different process instances.
Depending on the decision made at the gateway node, either the simple check
activity instance or the advanced check activity is executed.
Event diagrams are also useful for capturing process instances. The event
diagram of a particular process instance is shown in Figure 3.18, where a
process instance is shown during which the simple check activity instance is
selected.
When the process starts, activity instances for all three activity models
are generated. In event diagrams, the subscripts of the init, enable, terminate, and skip events can be omitted, if the activity instance to which the event
belongs is clear.
The start event is represented by the event node N1 in the process model.
The occurrence of this event is represented in the event diagram by event n1.
Once this event has occurred, the AnalyzeOrder activity instance can start,
i.e., it can enter the ready state, represented by an enable event.
When the AnalyzeOrder activity instance terminates, (1) the AdvCheck
activity instance is no longer required, so that a skip event occurs for this
activity instance, and (2) the SimpleCheck activity instance is enabled, so
that it can start. When this activity completes, the final event n7 of the
process instance occurs.
No comments:
Post a Comment