Pattern 14 (Multiple Instances with a priori Run-Time Knowledge)

FLASH animation of Multiple Instances with 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, but is known before the task instances must be created. Once initiated, these instances are independent of each other and run concurrently. It is necessary to synchronize the instances at completion before any subsequent tasks can be triggered.

Synonyms

None.

Examples

When diagnosing an engine fault, multiple instances of the check-sensor task can run concurrently depending on the number of error messages received. Only when all messages have been processed, can the identify-fault task be initiated;

In the review process for a paper submitted to a journal, the review paper task is executed several times depending on the content of the paper, the availability of referees and the credentials of the authors. The review process can only continue when all reviews have been returned;

When dispensing a prescription, the weigh compound task must be completed for each ingredient before the preparation can be compounded and dispensed.

Motivation

The Multiple Instances with a priori Run-Time Knowledge pattern provides a means of executing multiple instances of a given task in a synchronized manner with the determination of exactly how many instances will be created being deferred to the latest possible time before the first of the tasks is started.

Overview

As with other multiple instance patterns, there are two variants of this pattern depending on whether the instances are created sequentially or simultaneously as illustrated in Figures 18 and 19. In both cases, the number of instances of task C to be executed (indicated in these diagrams the variable numinst) is communicated at the same time that the thread of control is passed for the process instance.

Figure 18: Multiple instances with a prior run-time knowledge pattern (variant 1)

Figure 19: Multiple instances with 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 creation of instances of the task. Once determined, the number of task instances is a fixed value.

Implementation

Staffware, FLOWer and UML 2.0 ADs support the simultaneous variant of the pattern through the use of dynamic subplan and ExpansionRegion constructs respectively. BPMN and XPDL support both options via the multi-instance loop task construct. In the case of FLOWer, BPMN and XPDL, the actual number of instances required is indicated through a variable passed to the construct at runtime. For UML 2.0 ADs, the ExpansionRegion construct supports multiple instantiations of a task based on the number of instances of a defined data element(s) passed at run-time. Oracle BPEL supports the pattern via its (unique) <flowN> 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.