Pattern |
Rating |
Motivation |
| Sequence |
+ |
Supported through arcs connecting plan elements. |
| Parallel Split |
+ |
Nodes in static, dynamic and sequential subplans have an AND-split semantics. |
| Synchronization |
+ |
Nodes in static, dynamic and sequential subplans have an AND-join semantics. |
| Exclusive Choice |
+ |
Supported through the plan type system decision (based on data) and the plan type user decision (based on a user selection on the wavefront). Moreover, it is possible to specify guards on the arcs in the static, dynamic and sequential subplans. When a guard evaluates to true the subsequent activity is enabled otherwise it is skipped (status "refused"). |
Simple Merge |
+ |
Supported by the end nodes of the plan type system decision and the plan type user decision. Multiple incoming arcs in static, dynamic and sequential subplans can be used to merge flows. |
| Multi-Choice |
+ |
Supported by guards on arcs in static, dynamic and sequential subplans. |
| Structured Synchronizing Merge |
+ |
Supported inside static, dynamic and sequential subplans. Each plan model is directed acyclic graph of nodes representing various plan elements and actions. Nodes with multiple incoming arcs wait for their predecessors to be completed or skipped (called "refused"). If all preceding nodes are skipped or all incoming arcs have a guard evaluating to false, a node is skipped. Otherwise normal processing is resumed. Note that the approach is similar to passing true and false tokens. True tokens correspond to arcs that evaluate to true and get triggered by completed nodes. False tokens correspond to arcs that evaluate to false or arcs that are skipped (i.e., the preceding node is "refused"). The join semantics is that if a node has at least one true token as input it becomes enabled. If all input tokens are false it is skipped (i.e., labeled as "refused"). |
| Multi-Merge |
+/- |
It is possible to have multiple concurrent threads using dynamic subplans. Therefore, there is partial support for the pattern. However, since plans are highly structured, it is not possible to have an AND-split/XOR-join type of situation, i.e., the models are essentially "safe" (1-bounded). |
| Structured Discriminator |
- |
Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed. |
| Arbitrary Cycles |
- |
Not supported. In fact there are no loops and the language is block structured. Each plan model is directed acyclic graph of nodes representing various plan elements and actions. Iteration is achieved through the sequential subplan and the redo role. |
| Implicit Termination |
+ |
Supported, plans can have multiple end nodes. Only if all are completed (or refused), the plan is completed. |
| Multiple Instances without Synchronization |
+ |
Directly supported through dynamic subplans. the dynamic subplan can be put into another plan such that subsequent plan elements do not have to wait for the completion of the plan. |
| Multiple Instances with a Priori Design-Time Knowledge |
+ |
Directly supported through dynamic subplans. For a dynamic plan, the minimum and maximum number of instances can be selected and the actual number of instances may be based on some expression. This expression can be a constant, thus realizing the pattern. Multiple instance data can be passed and accessed through a so-called dynamic array. |
| Multiple Instances with a Priori Run-Time Knowledge |
+ |
Directly supported through dynamic subplans. One can specify a variable number of instances. |
| Multiple Instances without a Priori Run-Time Knowledge |
+ |
Directly supported through dynamic subplans. It is possible to create new instances during execution. There is a setting "User may create instances". |
| Deferred Choice |
+ |
Although there is no explict notion of state, there are different ways of realizing this pattern: (1) The plan type user decision (based on user selection on the wavefront) can make the implicit choice in some cases. (2) The plan type system decision can make the implicit choice in other cases. Note that a system decision blocks until at least one of its conditions is true. As a consequence, race conditions based on time or external triggers are possible. In the latter case, triggering is handled through data-dependencies rather than explicit control-flow dependencies. (3) Yet another way to use a specific type of deferred choice is by using guards on arcs in a plan model (i.e., inside a static, dynamic or sequential plan) that evaluate to NIL. In this case processing stops until the guard evaluates to true or false. A guard evaluates to NIL if e.g. it contains an undefined variable. Moreover, using the operator "HasValue" this can be exploited. This way a deferred choice may be implemented via data. Note that data can be set from outside the process (e.g., based on a trigger). |
| Interleaved Parallel Routing |
+/- |
Due to the case metaphor there is only one actor working on the case. Therefore, there is no true concurrency and any parallel routing is interleaved. Since true concurrency is not possible, a partial support rating is given. |
| Milestone |
+/- |
There is no direct support for milestones since there is no notion of state. However, in all situations, data dependencies can be used to emaulate the construct. Simply introduce a data element (i.e., place in Petri net terms) for each state for which a milestone needs to be specified. |
| Cancel Activity |
+/- |
It is possible to skip or redo activities. However, it is not possible to withdraw an activity in one branch triggered by an activity in another branch. Skip and redo are explicit user actions. Therefore, they provide only partial support. |
| Cancel Case |
+/- |
It is possible to skip or redo an entire plan. However, skip and redo actions are always explicit user actions. Therefore, they provide only partial support. Note that by defining a data element named cancel and using this data element as a precondition for every activity in the flow it is possible to block a case. Although this is an elegant solution, it is still considered to be indirect. |
| Structured Loop |
+ |
Iteration can be achieved through the use of the sequential plan construct |
| Recursion |
- |
Not supported. |
| Transient Trigger |
- |
Triggers can be modeled by setting data elements. There are various ways to wait for data, e.g., using guards on arcs or mandatory data elements of a milestone. The data elements can be considered as persistent. To model transient triggers one needs to reset the data value shortly after it has been set. |
Persistent Trigger |
+ |
Triggers can be modeled by setting data elements. There are various ways to wait for data, e.g., using guards on arcs or mandatory data elements of a milestone. This naturally corresponds to persistent triggers. |
| Cancel Region |
- |
Not supported. There is no integrated means of cancelling a group of plans or plan elements. |
| Cancel Multiple Instance Activity |
- |
No direct means of cancelling a dynamic subplan without triggering the next activity. |
| Complete Multiple Instance Activity |
+/- |
A dynamic subplan can have an auto-complete condition can be specified for the subplan based on a variety of conditions however it only completes when all instances have completed. The use of deadlines on a dynamic subplan results in both the remaining instances and all subsequent activities in the process instance being force completed when the deadline is reached. |
| Blocking Discriminator |
- |
Not supported. Note that the auto complete condition of a dynamic subplan cannot be used to continue processing at a higher level while blocking the dynamic subplan until all instances complete. |
| Cancelling Discriminator |
- |
Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed. |
| Structured N-out-of-M Join |
- |
Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed. |
| Blocking N-out-of-M Join |
- |
Not supported. The remaining subplan activities are forced to complete. |
| Cancelling N-out-of-M Join |
- |
Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed. |
| Generalised AND-Join |
- |
Not supported. Note that FLOWer models are "safe" (1-bounded). |
| Static Partial Join for Multiple Instances |
- |
Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed. |
| Cancelling Partial Join for Multiple Instances |
- |
Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed. |
| Dynamic Partial Join for Multiple Instances |
- |
Not supported. Dynamic subplans can have an auto complete condition however this is only evaluated when all subplans have completed. |
| Acyclic Synchronizing Merge |
+ |
Supported inside the static, dynamic and sequential subplans. Each plan model is a directed acyclic graph of nodes representing various plan elements and actions. Nodes with multiple incoming arcs wait for the predecessors to be completed or skipped (called "refused"). If all preceding nodes are skipped or all incoming arcs have a guard evaluating to false, a node is skipped. Otherwise normal processing is resumed. |
| General Synchronizing Merge |
- |
Not supported because each plan model need to correspond to an acyclic graph. |
| Critical Section |
+/- |
Not directly supported. However, data elements can acts as semaphores. There are no concurrency problems because of the write-lock on cases. |
| Interleaved Routing |
+/- |
As for Interleaved Parallel Routing, the case metaphor allows a user to work on any of its constituent activities without regard to their overall sequence. A case is completed when all of its activities have been completed. Although there is no direct means of ensuring that activities are only undertaken one at a time, the fact that they are all undertaken by the same user obviates any potential for concurrency and ensures that they are interleaved. |
| Thread Merge |
- |
Not supported. The case metaphor prevents any possibility of multiple threads of execution. |
| Thread Split |
- |
Not supported. The case metaphor prevents any possibility of multiple threads of execution. |
| Explicit Termination |
- |
Not supported. Plans complete when all end nodes have completed. |
