Mentor Information:

Scott Hetherington shetheri@tietronix.com 281-461-9300 x227

 

 

Faculty Advisor:

Dr. Kwok-Bun Yue

yue@cl.uh.edu

281-283-3864

 

 

Team Members:

Karthik Katikaneni
Lingbao Wang
Sa Nguyen
Su Dang

 

 
 

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

1. Process Verifier shall be integrated and compatible with the TieFlow Workflow Toolkit Workflow Editor.
2. Process Verifier shall use the Java JDK version 1.5 for any required Java code.
3. Process Verifier shall use the XML parser currently used by the Workflow Editor for any required XML processing.

Detailed Requirements

Process Verification

4. Process Verifier shall provide the capability for the user to select the process definition desired for verification. By default, it should be the process definition currently selected and displayed in the Workflow Editor.
5. Process Verifier shall automatically include any and all sub-processes associated with the selected process definition.
6. Process Verifier shall analyze the process definition to find errors, inconsistencies, and logical problems in the process definition. Ideally, the "rules" would be configurable to allow addition or modification of individual rules without redesign or major modification of the code.
7. Process Verifier shall provide multiple error types to indicate the severity of the violation. At a minimum, the types should include:
  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.
8. Process Verifier shall verify the following Error rules:
  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.
9. Process Verifier shall verify the following Warning rules:
  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.
10. Process Verifier shall verify the following valid process flow patterns:
  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

11. Process Verifier shall display some indication of status while it is executing.
12. Process Verifier shall display the verification results in a new window.
13. Process Verifier shall display each error found.
14. Process Verifier shall display errors of the same type grouped together with the error type displayed only once, followed by the details of each violation.
15. Process Verifier shall display the possible cause of or corrective action for each error.
16. Process Verifier shall display each warning found.
17. Process Verifier shall display warnings of the same type grouped together with the warning type displayed only once, followed by the details of each violation.
18. Process Verifier shall display the possible cause of or correction action for each warning.
19. Process Verifier shall highlight the error/warning area of the process in the graphical display when an individual error or warning is clicked in the Verification Results window.