Flow diagrams to Petri nets

This document describes how the FD2PN component has been reused for several workflow languages. This component features a reusable transformation from a Workflow concept to a Petri net, which is able to deal with several of the patterns defined in the Workflow patterns catalog.

The menu provides links to the different artefacts of the case study.

Code for Bentō:

Workflow concept

The source concept abstracts the common elements found in workflow languages that the transformation needs to deal with. The following image shows the designed concept. Workflows are made of interconnected nodes, some of them representing tasks or activities, while others are gateways in charge of routing the process flow. Tasks and the different types of gateways are modelled as subclasses of an abstract class Node.

We have identified as gateways the homonymous patterns in the well-known catalogue of control workflow patterns of van der Aalst et al. (see the Workflow patterns catalog), as the semantics of these patterns is well-documented and precisely defined. All types of gateway have cardinality \code{0..1} because the pattern they represent may be present or not in a particular modelling language (this cannot be depicted with the Ecore graphical editor). In particular, class ParallelSplit is a type of node that splits an execution thread into several parallel threads which execute concurrently; e.g., this behaviour is called AND-split or fork in modelling languages like BPMN and Activity Diagrams, respectively. Synchronization synchronizes several parallel execution threads into a single one when the parallel threads are completed. ExclusiveChoice passes the control flow to an output branch among several ones. MultiChoice passes the control flow to two or more output branches among several ones. Finally, SimpleMerge permits the convergence of two or more execution threads into a single one when some of the incoming threads are completed (in contrast to synchronization which requires the completion of all incoming branches, not only of one).

The semantics of final tasks may depend on the particular modelling language. While in languages like YAWL, reaching a final task concludes the execution of the workflow, in languages like BPMN, the execution only finishes when all active branches terminate. There are also languages which accommodate both semantics. For example, Activity Diagrams have both FlowFinalNodes for ending just a certain execution branch, and ActivityFinalNodes which end the complete execution. Our concept abstracts both options by means of the class FinalTask, which has the boolean flag isTerminating to indicate whether reaching an object of the bound type concludes the workflow execution or not.