Problem Statement

Background

The TieFlow Workflow Toolkit is a web-based electronic workflow system used to automate manual, form-based processes. These processes are specified in XML according to a DTD created for the workflow engine. The TieFlow Workflow Toolkit has a Java graphical Workflow Editor to allow users to graphically create, display, and modify process definitions. The Workflow Editor converts the graphical representation of the process and its underlying data (entered by the process creator in the Workflow Editor as part of the process definition) into an XML document according to the workflow process DTD. This XML document is then imported into the Workflow Engine for execution.

Problem

While the XML process definition is automatically validated according to the DTD, the DTD validation does not identify incomplete or incorrect process definitions. The current process verifier uses a graph reduction strategy to determine the validity of the process flow. While this works well for simple, top-down processes, it does not work for processes containing loops. As a result, it cannot be used for nearly all of the processes developed with the

Workflow Toolkit. Additionally, the current verifier is a stand-alone program with a rudimentary user interface.

The objective of this project is to modify the current verification strategy or implement a new verification strategy to handle loops in the process and any/all other valid process flows. Also, the process verifier must be integrated as a capability within the Workflow Editor. Finally, the user interface displaying the verification results (warnings and errors) should be improved and integrated with the editor's graphical process view.

High-Level Requirements

Code / Architecture

Detailed Requirements

Process Verification

1. Error: indicates a definite violation that would prevent the proper execution of the process.
   
2. Warning: indicates unusual circumstances that will not cause a problem in the execution of the process for the workflow engine, but may not be the process creator's intent.
   

1. A process definition must contain at least one activity.
   
2. A process definition must contain one and only one ProcessStart.
   
3. A process definition ProcessStart must have at least one EntryPoint.
   
4. Each Transition to an EntryPoint of a ProcessStart cannot share the EntryPoint with any other Transition. (No AND-join in a ProcessStart or no AND-join to a subProcess)
   
5. A process definition ProcessStart must have at least one ExitPoint.
   
6. A process definition must contain one and only one ProcessEnd.
   
7. A process definition ProcessEnd must have one and only one ExitPoint. (No AND-split from a subProcess)
   
8. The Transition from the ExitPoint of a ProcessEnd cannot share an Entry Point with any other Transition. (No AND-join from a ProcessEnd or a subProcess cannot go to an AND-join)
   
9. A process definition ProcessEnd must have at least one EntryPoint.
   
10. Each AssigneeRole maximum attribute value must be greater than or equal to its minimum attribute value unless the maximum attribute value is 0.
    
11. AssigneeRole maximum attribute must be integer values greater than or equal to 0.
    
12. AssigneeRole minimum attribute must be integer values greater than or equal to 1.
    
13. Each Activity must have at least one EntryPoint.
    
14. Each Activity must have at least one ExitPoint with a specified disposition.
    
15. Each Activity must have at least one transition to one of its EntryPoints from an ExitPoint of another Activity, ProcessStart, or SubProcess.
    
16. Each Transition must specify one and only one ExitPoint as its origin and one and only one EntryPoint as its destination.
    
17. For every split in the process flow where multiple threads of control execute in parallel (AND-split), there must be a corresponding join where each of those parallel threads recombine into a single process thread (AND-join). The individual parallel threads are required to either terminate in a dead-end or rejoin the other parallel threads. However, the parallel threads are not required to all recombine at the same time and place. The only requirement is that they recombine or terminate before the end of the process.
    
18. Transitions from Activities within a split parallel thread must connect to the EntryPoint of Activities or SubProcesses within the split parallel thread or to the EntryPoint of an Activity that is combining with one or more of the other split parallel threads (AND-join). Likewise, transitions to Activities within a split parallel thread must originate from the ExitPoint of Activities or SubProcesses within the split parallel thread or from the ExitPoint of the Activity where split parallel threads originated (AND-split). In other words, no Transitions may be made into or out of the Activities within the split parallel threads section of a process, unless the Transitions are completely contained within the split parallel threads section of the process.
    
19. Every independently executable path through a process must start at the WorkflowStart and end at the WorkflowEnd. In other words, a process cannot have paths without an end. In the case of an AND-split, an individual split parallel path may deadend as long as at least one of the other split parallel paths continues to the end of the process. In the case where a process has optional paths (OR-split), each optional path must be complete from one end of the process to the other.
    

1. Each Activity must have at least one Transition from one of its ExitPoints to the EntryPoint of another Activity, ProcessEnd, SubProcess, or ProcessGround.
   
2. RoleID of an AssigneeRole specified in an Activity must be defined in the process definition document by a Role.
   
3. Each SIMPLE Activity must have at least one AssigneeRole.
   
4. AUTOMATIC Activities cannot have an AssigneeRole.
   
5. Each SIMPLE Activity must have at least one ExitPoint with label. In other words, the Activity must have at least one visible disposition.
   
6. Each SIMPLE Activity must have a single formLayout.
   

1. linear (one Transition from an ExitPoint to an EntryPoint)
   
2. OR-split (process object has multiple Transitions each from their own ExitPoint)
   
3. OR-join (process object has multiple Transitions each to their own EntryPoint)
   
4. AND-split (process object has multiple Transitions from a single ExitPoint)
   
5. AND-join (process object has multiple Transitions to a single EntryPoint)
   
6. loopback (Transition goes from a process object to itself or a previous process object)
   
7. dead-end (process object has a Transition to the ProcessGround)
   

Process Verification Results