OpenWflow Home

"Java-based Open Source WF Verification and WFMS.  A set of modules for running verifiably correct workflows diagrammed using UMLv2.0"














Contents
Introduction
Workflows
Diagramming
Verification
Software
Downloads
Papers
Links
Contact

Introduction


There are many definitions of workflows often with an implicit perception that the type of workflow is understood.

These definitions will be considered and an outline of the approach used for this particular system will be given. Note that it will be UML based as this is now a de facto standard comprehensible to non-technical users.

[20 Aug 2004]
A comprehensive view and the process of constructing workflows using UMLv2.0 Behavio(u)rs will be posted during the course of the next few weeks and months.

The intention is to have an open source Java based system that:

  • is verifiable
  • is based on Workflow patterns
  • uses industry standards (UML, XMI etc.) for 3rd party tools to be able to diagram workflows
  • is relatively simple to comprehend
  • is comprehensively documented
  • has functionality not often seen in current workflow systems (such as recursion)
[21 Aug 2004]
A little restructuring and correction made to this page. Some additional information added.

Workflows


A discussion regarding:

  • Petri nets
  • UML Activity diagrams
  • Other
Some discussion wrt characteristics of all workflows will be given.

Diagramming


A brief outline of diagramming for Petri nets and a more comprehensive outline of UMLv2.0 Activity diagrams. Discussion wrt to anomalies, ambiguities, omissions, unnecessary syntactic sugaring and so on.

For example, some systems consider the diagram on the right to be incorrect ...

(Is it?)

Verification


Comprehensive discussion outlining how UMLv2.0 Activity diagrams may be rigourously verified. Points covered include:

Syntactical validation
The syntax of a workflow is formally defined from the results of graph theory. Syntactical validation checks component usage of the diagram, such as:

  • Incorrect usage, eg: condition node with only one output
  • Deadlocks and livelocks (infinite cycles etc.)
  • Unintentional multiple execution, eg: merge on two concurrent paths
Structural validation
Some structural components are not covered in syntactical validation, for example: critical tasks or processes.

Restrictions
Restrictions include not allowing some constructs that are just syntactic sugaring. For example, Conditional Nodes are defined in the UMLv2.0 spec. as: "… a structured activity node that represents an exclusive choice among some number of alternatives." This can be represented as a set of Actions with Decision Points having guard transitions. Hence Conditional Nodes will be rejected.

Other
Validations are made for:
  • Reachability

  • If an activity is not reachable from any start activity of a process definition, the activity will have no chance to be executed. Therefore, it makes no sense to define such an activity in a process definition.
  • Semantic validation

  • Does the workflow model the wishes of the user correctly? The semantics of a workflow structure is the set of possible traces through the structure, that is all possible action sequences. A complete set of instance subgraphs of a workflow graph would be validated.
  • Criticality

  • It may so arise that in some workflows, specific tasks or processes must be invoked. This notion is tied up with the idea of Reachability.
  • Initiation

  • A sequence of events exists leading to the execution of a workflow object.
  • Resource allocation and performance

  • Resources required by the workflow of the system to operate correctly. This will be based on a security/role based sub-system.


    Partitions (Resources/Swimlanes)

  • Liveness

  • Implies the workflow is not dead. That is, there exists an initial state such that the workflow will start and that movement between processes of the workflow keep the workflow in a correct state.
  • Safeness, soundness, boundedness

  • The workflow must be able to finish and, on termination, there should be no dead tasks. This is usually as a result of a terminating decision. It should be possible to execute an arbitrary task by following the appropriate route though the workflow. No state should occur more than a limited number of times.
  • Exception handling

  • Where the semantics cannot be verified (perhaps because conditions are calculated within a process not exposed to the workflow), where a condition occurs which cannot be routed or handled by the WfMS, an exception occurs.

Software


Design of the system using Aspect Oriented Programming (AOP) methods. Brief outline of AOP and thread synchronization in JDK1.5. (Every Activity is a thread and every Action within an Activity is run as a separate thread).

Downloads


A JAR download.

Papers


Various standards, white papers and links to (mainly academic) papers.

  UMLv2.0 Superstructure [current status: Final, but not complete release]
  XML Metadata Interchange [XMI]

Links


Links to useful sites such as:

  UML org
  OMG org
  WfMC org

A list of other Workflow systems can be found in manageability.org. Note, not all are open source, they quite often use proprietary diagramming methods or use languages (mainly XML based) and none (so far as I am aware) verify their diagrams comprehensively.

Contact


Serious enquiries regarding workflows and modeling workflows in UMLv2.0 can currently be addressed to: Workflow Enquiry. Note that flippant enquiries will be studiously ignored.

 


Activity with Parameters


UML   OMG

WfMC UML






Loop