Pattern 15 (Multiple Instances without a priori Run-Time Knowledge)

FLASH animation of Multiple Instances without a priori Run-Time Knowledge pattern

Description

Within a given process instance, multiple instances of a task can be created. The required number of instances may depend on a number of runtime factors, including state data, resource availability and inter-process communications and is not known until the final instance has completed. Once initiated, these instances are independent of each other and run concurrently. At any time, whilst instances are running, it is possible for additional instances to be initiated. It is neccesary to synchronize the instances at completion before any subsequent tasks can be triggered.

Synonyms

None.

Examples

The despatch of an oil rig from factory to site involves numerous transport shipment tasks. These occur concurrently and although sufficient tasks are started to cover initial estimates of the required transport volumes, it is always possible for additional tasks to be initiated if there is a shortfall in transportation requirements. Once the whole oil rig has been transported, and all transport shipment tasks are completed, the next task (assemble rig) can commence.

Motivation

This pattern is an extension to the Multiple Instances with a priori Run-Time Knowledge pattern which defers the need to determine how many concurrent instances of the task are required until the last possible moment - either when the synchronization of the multiple instances occurs or the last of the executing instances completes. It offers more flexibility in that additional instances can be created "on-the-fly" without any necessary change to the process model or the synchronization conditions for the task.

Overview

Similiar to other multiple instance patterns, there are two variants to this pattern depending on whether the initial round of instances are started sequentially or simultaneously. These scenarios are depicted in Figures 20 and 21. It should be noted that it is possible to add additional instances of task C in both of these implementations via the add instance transition at any time up until all instances have completed and the join associated with them has fired triggering the subsequent task (B).

Figure 20: Multiple instances without a priori run-time knowledge pattern (variant 1)

Figure 21: Multiple instances without a priori run-time knowledge pattern (variant 2)

Context

There is one context condition associated with this pattern: the number of task instances (i.e. numinst) is known at runtime prior to the completion of the multiple instance task (note that the final number of instances does not need to be known when initializing the MI task).

Implementation

Only one of the offerings examined - FLOWer - provides direct support for this pattern. It does this through the dynamic subplan construct.

Issues

None identified.

Solutions

N/A

Evaluation Criteria

Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption.

Product Evaluation

To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.