COSA Evaluation Results
Evaluation results for COSA version 5.1 against the workflow control-flow patterns
Pattern |
Rating |
Motivation |
Sequence | + | Directly supported by arcs connecting activities. |
Parallel Split | + | Supported by multiple outgoing arcs from an activity. None of the arcs have transition conditions specified. |
Synchronization | + | Supported by multiple incoming arcs to an activity. None of the arcs have transition conditions specified. |
Exclusive Choice | + | Supported by multiple outgoing arcs from an activity. All of the arcs have disjoint transition conditions specified. |
+ | Supported by multiple incoming arcs to a place. | |
Multi-Choice | + | Supported by multiple outgoing arcs from an activity. The arcs may have (possibly overlapping) transition conditions specified. |
Structured Synchronizing Merge | - | Processes are not inherently structured. |
Multi-Merge | +/- | Only safe Petri net diagrams can be used. |
Structured Discriminator | - | The discriminator can be modelled by using true conditions in input arcs and extending the network. Unfortunately, the resulting diagram is too complex. |
Arbitrary Cycles | + | Supported. Any graph structure is allowed. |
Implicit Termination | - | Not supported, explicit termination is needed. |
Multiple Instances without Synchronization | + | COSA has a three level workflow model, i.e., workflow, flow, and activity. Flows (i.e., workflow instances) can be grouped in one workflow and share information. This combined with a trigger mechanism to create new flows is a possible solution where folders are used to facilitate shared access to common data. |
Multiple Instances with a Priori Design-Time Knowledge | - | There is no means of denoting that an activity should be executed multiple times. |
Multiple Instances with a Priori Run-Time Knowledge | - | There is no means of denoting that an activity should be executed multiple times. |
Multiple Instances without a Priori Run-Time Knowledge | - | There is no means of denoting that an activity should be executed multiple times. |
Deferred Choice | + | Supported by multiple outgoing arcs from a place. |
Interleaved Parallel Routing | + | Directly supported through places and also an optional setting of the workflow engine. |
Milestone | + | Directly supported through places. |
Cancel Activity | + | Supported by removing tokens from input places. |
Cancel Case | - | Only supported through an API call. |
Structured Loop | - | There is no means of specifying repeated execution of an activity or set of activities. |
Recursion | + | Recursive definition of process models can be achieved using triggers or the activ_run tool agent. |
Transient Trigger | + | Supported through trigger construct in synchronous mode. |
+ | Supported through trigger construct in asynchronous mode. | |
Cancel Region | +/- | Achievable by specifying a shadow cancellation activity for each activity in the cancellation region although the overall diagram is likely to be intractable for anything other than simple process models. |
Cancel Multiple Instance Activity | - | Multiple instance activities are not supported. |
Complete Multiple Instance Activity | - | Multiple instance activities are not supported. |
Blocking Discriminator | - | There is no modelling construct that directly corresponds to this pattern and although the behaviour can be indirectly achieved, the process model required to do is too complex. |
Cancelling Discriminator | - | Similar to WCP28, no direct support. |
Structured N-out-of-M Join | - | There is no modelling construct that directly corresponds to this pattern and although the behaviour can be indirectly achieved, the process model required to do is too complex. |
Blocking N-out-of-M Join | - | Similar to WCP30, no direct support. |
Cancelling N-out-of-M Join | - | Similar to WCP30, no direct support. |
Generalised AND-Join | - | Only safe Petri net diagrams can be used. |
Static Partial Join for Multiple Instances | - | Multiple instance activities are not supported. |
Cancelling Partial Join for Multiple Instances | - | Multiple instance activities are not supported. |
Dynamic Partial Join for Multiple Instances | - | Multiple instance activities are not supported. |
Acyclic Synchronizing Merge | + | The condition on an input arc to an activity can specified such that it will not be considered when the join condition for the activity is evaluated if the branch to which it belongs is not live. |
General Synchronizing Merge | - | No ability to determine when an OR-join should fire based on a complete evaluation of the overall state of the process instance. |
Critical Section | + | Supported through the use of a mutex place to prevent concurrent access to the critical section. |
Interleaved Routing | + | Supported through the use of a mutex place to prevent nominated activities from executing concurrently. |
Thread Merge | - | No ability to merge threads as the process in inherently safe. |
Thread Split | - | No ability to merge threads as the process in inherently safe. |
Explicit Termination | + | Directly supported, a process instance completes when an end activity is reached. |
Evaluation results for COSA version 4.2 against the workflow data patterns
Pattern |
Rating |
Motivation |
Task Data | + | Directly supported by (non-persistent) STD attributes at the activity level |
Block Data | + | Workflows can be nested and attributes of the form INSTANCE.name provide a means of supporting block data |
Scope Data | - | Not supported |
Multiple Instance Data | + | Support for distinct data elements in multiply triggered tasks and tasks with shared sub-workflow decompositions |
Case Data | + | Supported via tool agent INSTANCE (INSTANCE.name). |
Folder Data | + | Fully supported via folders accessible to nominated activities across multiple cases |
Workflow Data | +/- | COSA allows for attributes of the form DEFINITION.name however these are fixed at design time |
Environment Data | + | External data elements can be accessed via DDE, ODBC, XML, OS tool agents |
Task to Task | + | Supported by data sharing (implicit data passing) |
Block Task to SubWorkflow Decomposition | +/- | Supported by data sharing (implicit data passing) but no ability to limit the range of items passed |
SubWorkflow Decomposition to Block Task | +/- | As for Pattern 10 |
To Multiple Instance Task | - | Not supported |
From Multiple Instance Task | - | Not supported |
Case to Case | + | Supported via folder data |
Task to Environment - Push-Oriented | + | Supported through tool agents e.g. ODBC |
Environment to Task - Pull-Oriented | + | Supported through tool agents e.g. ODBC |
Environment to Task - Push-Oriented | + | Supported via command line and C/COM/Java APIs |
Task to Environment - Pull-Oriented | + | Supported via command line and C/COM/Java APIs |
Case to Environment - Push-Oriented | - | Not supported |
Environment to Case - Pull-Oriented | - | Not supported |
Environment to Case - Push-Oriented | + | Trigger functions allow process instance and folder data to be set |
Case to Environment - Pull-Oriented | + | Trigger functions allow process instance and folder data to be read |
- | Not supported | |
Environment to Workflow - Pull-Oriented | - | Not supported |
Environment to Workflow - Push-Oriented | - | Not supported |
Workflow to Environment - Pull-Oriented | + | Supported via command line and C/COM/Java APIs |
Data Transfer by Value - Incoming | +/- | Achievable via triggers although limitation on range and typing of parameters passed |
Data Transfer by Value - Outgoing | +/- | As for Pattern 27 |
Data Transfer - Copy In/Copy Out | - | Not supported |
Data Transfer by Reference - Unlocked | + | Standard means of data passing |
Data Transfer by Reference - With Lock | - | Not supported |
Data Transformation - Input | - | Not supported |
Data Transformation - Output | - | Not supported |
Task Precondition - Data Existence | + | By specifying transition conditions for tasks based on the CONDITION.TOKEN and STD.exists tool agents, subsequent task invocation can be delayed until required data element is available |
Task Precondition - Data Value | + | By specifying transition conditions for tasks based on the required data values and CONDITION.TOKEN tool agent, subsequent task invocation can be delayed until required data values are met |
Task Postcondition - Data Existence | - | Not supported |
Task Postconditon - Data Value | - | Not supported |
Event-Based Task Trigger | + | Triggers provide direct support for all three Pattern variants |
Data-Based Task Trigger | + | Directly supported by including a transition condition (which may include CONDITION.TOKEN) corresponding to the required data condition on the incoming arc to the task to be triggered |
Data-Based Routing | + | Supported by conditions on input and output arcs. Both exclusive choice and multi-choice supported |
Evaluation results for COSA version 4 against the workflow resource patterns
Pattern |
Rating |
Motivation |
Direct Allocation | + | Directly supported |
Role-Based Allocation | + | Directly supported |
Deferred Allocation | - | Not supported |
Authorisation | + | Distinct authorisation and distribution mechanisms are supported |
+/- | Indirectly achievable through user access rights | |
Case Handling | - | Not supported |
Retain Familiar | + | Supported via a customised distribution algorithm |
Capability Based Allocation | + | Supported via competency definitions for users, groups and activity definitions. |
History Based Allocation | +/- | Indirectly achievable via a custom (external) distribution algorithm |
Organisational Allocation | + | Directly supported through user/group and user/group script languages. |
Automatic Execution | + | Achievable by assigning work items to internal system users. |
Distribution by Offer - Single Resource | +/- | Non-binding offers not supported but allocated work items can by rejected for reallocation |
Distribution by Offer - Multiple Resources | + | Directly supported for multiple resources via group queues. |
Distribution by Allocation - Single Resource | + | Directly supported |
Random Allocation | + | Directly supported via random function in user/group language |
Round Robin Allocation | +/- | Indirectly achievable via a custom (external) distribution algorithm |
Shortest Queue | + | Supported via a customised distribution algorithm based on the fewwork function |
Early Distribution | - | Not supported |
Distribution on Enablement | + | Standard means of work distribution |
Late Distribution | - | Not supported |
Resource-Initiated Allocation | +/- | The act of a resource reserving a work item on a shared work list has the effect of locking the process instance |
Resource-Initated Execution - Allocated Work Item | + | Resources can initiate allocated work items from their work queues. |
Resource-Initiated Execution - Offered Work Item | + | Supported for work items on shared work queues |
- | Not supported | |
Resource-Determined Work Queue Content | + | A series of options are provided for configuring views in the worklist handler. |
Selection Autonomy | + | Resources can select any of the work items on their queue to initiate next |
Delegation | + | Resources can manually reroute work items from their work queues |
Escalation | + | Supported via the Target Dates option for processes together with a trigger to reroute the work item |
Deallocation | + | Directly supported through redistribution |
Stateful Reallocation | + | Supported through the reroute function |
Stateless Reallocation | - | Not supported |
Suspension/Resumption | + | Resources can suspend work items currently being executed |
Skip | + | Directly supported via skip option in worklist handler |
Redo | - | Not supported |
Pre-Do | - | Not supported |
Commencement on Creation | + | Supported for tasks initiated via a trigger |
Commencement on Allocation | - | Not supported |
Piled Execution | - | Not supported |
Chained Execution | - | Not supported |
Configurable Unallocated Work Item Visibility | - | Not supported |
Configurable Allocated Work Item Visibility | - | Not supported |
Simultaneous Execution | + | Resources can execute multiple work items simultaneously |
Additional Resources | +/- | Simulation environment provides multiple resource modelling capabilities for a single work item. |
Evaluation results for COSA version 5.1 against the workflow exception handling patterns
Pattern |
Explanation |
Work Item Failure |
|
SRS-CWC-RBK | An activity can deal with a detected failure by rolling back work in progress and restarting the activity via the COSA_activity_cancel function. |
Work Item Deadline |
|
OCO-CWC-COM | A compensating activity can be triggered for an activity that has no reached a specified state by a nominated time. |
ACA-CWC-COM | A compensating activity can be triggered for an activity that has no reached a specified state by a nominated time. |
SCE-CWC-COM | A compensating activity can be triggered for an activity that has no reached a specified state by a nominated time. |
External Trigger |
|
OCO-CWC-COM | A compensating activity can be initiated for an activity via an external trigger. |
ACA-CWC-COM | A compensating activity can be initiated for an activity via an external trigger. |
SCE-CWC-COM | A compensating activity can be initiated for an activity via an external trigger. |