Pattern 34 (Redo)

FLASH animation of Redo pattern

Description

The ability for a resource to redo a work item that has previously been completed in a case. Any subsequent work items (i.e. work items that correspond to subsequent tasks in the process) must also be repeated.

Example

The Inspector has decided to redo the Interview Key Witness work item.

Motivation

The Redo pattern allows a resource to repeat a work item that has previously been completed. This may be based on a decision that the work item was not undertaken properly or because more information has become available that alters the potential outcome of the work item.

Overview

The Redo pattern effectively provides a means of "winding back" the progress of a case to an earlier task. The difficulties associated with doing this where a process instance involves multiple users means the pattern is not a common PAIS feature, however for situations where all of the work items in a case are allocated to the same user (e.g. in a case handling system), the problem is more tractable. One consideration in utilizing this pattern is that whilst it is possible to regress the execution state in a case, it is generally not possible to wind back the state of data elements, hence any necessary reversion of data values needs to be managed at the level of specific applications and is not a general PAIS feature. This pattern is illustrated by the R:redo arc in Figure 6.

Context

There is one context condition associated with this pattern: any shared data elements (i.e. block, scope, case data etc.) cannot be destroyed during the execution of a case.

Implementation

Of the offerings examined, only FLOWer provides the ability to redo a previously completed work item.

Issues

Redoing a previously completed work item can have significant consequences on the execution of a case. In particular, the validity of any subsequent work items is questionable as redoing a preceding work item may impact data elements utilised by these work items during their execution.

Solutions

FLOWer addresses this issue by requiring any work items that depend on a "redone" work item to also be repeated before the case can be marked as complete.

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.

Summary of Evaluation