Pattern 6 (Folder Data)

FLASH animation of Folder Data pattern

Description

Data elements can be defined which are accessible by multiple cases on a selective basis. They are accessible to all components of the cases to which they are bound.

Example

Selected instances of the Approve Travel Request task can access the current cash reserves data element regardless of the case in which they execute, providing they nominate the folder they require at case initiation.

Motivation

Folder data provides a mechanism for sharing a data element between related task instances in different cases. This is particularly useful where tasks in multiple cases are working on a related problem and require access to common working data elements.

Overview

Figure 7 illustrates the notion of folder data. In essence, "folders" of related data elements are declared in the context of a process prior to the execution of individual cases. Individual cases are able to nominate one or more of these "folders" that their task instances should have access to during execution. Access may be read-only or read-write. In Figure 7, two folders are declared (A and B) containing data elements X and Y respectively. During the course of execution, case1 and case2 have access to folder A whereas case3 has access to both folders A and B. As there is only one copy of each folder maintained, should any of case1, case2 or case3 execute concurrently, then they will in effect share access to data element X. As a general rule, for folder data to be useful in an offering, the cardinality of the accessibility relationship between folders and cases needs to be m-n i.e. data elements in a given folder need to be accessible to more than one case and a given case needs to be able to access more than one data folder during execution.

Figure 7: Folder data visibility

Context

There are no specific context conditions associated with this pattern.

Implementation

Of the offerings examined, only COSA offers the facility to share data elements between cases on a selective basis. It achieves this by allowing each case to be associated with a folder at commencement. At any time during execution of the case, it is possible for the current folder to be changed. The type of access (read-only or read-write) and a range of access controls can be specified for each folder at design time. It is also possible to use folders as repositories for more complex data elements such as documents.

Issues

Solutions

The first issue is addressed in COSA by only allowing a case to access attributes from one folder at a time. This is achieved using a specific Tool Agent for folders. It is possible to change the folder to which a case refers at any time (again using a specific Tool Agent call). In terms of the second issue, similar considerations apply to those discussed for case data. In the case of COSA, there is no direct system support to address this problem.

Evaluation Criteria

An offering achieves full support if it has a construct that satisfies the description of the pattern.

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