Transformation of BPMN Models for Behaviour Analysis

Ivo Raedts, Marija Petković, Yaroslav S. Usenko, Jan Martijn van der Werf

Jan Friso Groote and Lou Somers

LaQuSo, Laboratory for Quality Software

an activity of Technische Universiteit Eindhoven and Radboud Universiteit Nijmegen

P.O Box 513, 5600 MB Eindhoven, The Netherlands

Abstract. In industry, many business processes are modelled and stored in En-

terprise Information Systems (EIS). Tools supporting the verification and vali-

dation of business processes can help to improve the quality of these business

processes. However, existing tools can not directly be applied to models used in

industry.

In this paper, we present our approach for model verification and validation:

translating industrial models to Petri nets and mCRL2, and subsequently apply-

ing existing tools on the models derived from the initial industrial models.

The following translations are described: BPMN models to Petri nets and Petri

nets to mCRL2. It is shown what the analysis on the derived models can reveal

about the original models.

1 Introduction

New laws, standards and technologies have given the use of Enterprise Information

Systems (EIS) an enormous boost. For mayor firms, the knowledge about business

processes is a mayor asset and is stored in EIS. Different firms define their business

processes using different formalisms and tools. The data in the EIS is maintained and

used by different persons within a firm and the correctness of the business processes

should be validated and verified.

A particular check that can be performed is whether processes are sound. This applies

in particular when a process describes a workflow. A workflow process is a process

having one entry point and one exit point. A process is sound if for each state that can

be reached from the initial state, a firing sequence exists that leads the system to the

final state. In a process model with formal execution semantics, these types of proper-

ties can be defined precisely, and verified automatically by tools.

Although numerous editors for creating models are used in industry, their analysis

facilities often have shortcomings. Business processes are typically specified using

other formalisms than the ones required by most existing verification tools. More-

over, most scientific tools operate on models based on modeling languages not often

used in industry.

Model transformations provide a wider range for applying model analysis on business

processes used in industry. The original models are transformed to ‘as-equivalent-as-

Raedts I., Petkovi

´

c M., S. Usenko Y., Martijn van der Werf J., Friso Groote J. and Somers L. (2007).

Transformation of BPMN Models for Behaviour Analysis.

In Proceedings of the 5th International Workshop on Modelling, Simulation, Veriﬁcation and Validation of Enterprise Information Systems, pages

126-137

DOI: 10.5220/0002428801260137

Copyright

c

SciTePress

possible’ models, specified in other formalisms, enabling the use of analysis tools for

these formalisms. This can result in better insight in, and additional information

about, the quality of the original model.

Fig. 1. Model transformations.

Our analysis approach is presented in Fig. 1. First, the original models are automati-

cally transformed to Petri nets 15. Subsequently, the Petri net models can be used as

input for Petri net-based analysis tools. The Petri nets can also automatically be trans-

formed to mCRL2 8, a process algebraic language 4, after which the mCRL2 toolset

can be used.

The Business Process Modeling Notation, BPMN, 23 is a graphical notation de-

signed for both business process design and business process implementation. BPMN

presents a good case for our approach: translating BPMN models to formal standards

supported by analysis facilities.

The same approach can also be followed for other industry standards, such as

BPEL 7 EPC 11 or UML diagrams 6. Transformations to Petri nets are described in

18 12 for BPEL, in 20 for EPC and in 3 for UML.

Petri nets are well-suited for modeling, analyzing and describing concurrent sys-

tems with a complex process flow. There are many Petri net-based tools like Yasper

9, Woflan 19, INA 16, LoLA 17 and CPN Tools 14 that can be used for model check-

ing and simulation. Different tools perform different types of analysis and some tools

are limited to a subset of Petri nets that can be analyzed. Therefore, it is valuable to

be able to use more tools. The range of analysis possibilities is extended by translat-

ing Petri nets to mCRL2, a process algebraic formalism. This enables automatic veri-

fication by the mCRL2 toolset.

The transformation from BPMN to Petri nets is implemented in XSLT. The trans-

formation from Petri nets to mCRL2 is implemented in C++. As both transformations

are integrated in our software framework 13 along with analysis tools, our approach

can be carried out via a web browser.

This paper is organized as follows. First the formalisms involved, BPMN, Petri

Nets and mCRL2 are explained in section 2. The transformation of BPMN models to

Petri nets is described in section 3. The Petri net-based analyses are explained in

section 4. The transformation of Petri nets to mCRL2 is described in section 5. Sec-

tion 6 shows how our analysis approach has been used in practice and what the Petri

net based analysis has revealed about the original BPMN models.

127

2 The Formalisms Involved

2.1 Business Process Modeling Notation

The Business Process Modeling Notation (BPMN) 23 is a graphical notation for busi-

ness process modeling. It describes processes in terms of order dependencies between

subprocesses and atomic tasks. The notation is supported by a variety of business

process modeling applications, and companies start to use it as their standard model-

ing technique. The BPMN standard was recently adopted by OMG 10.

Process steps are combined to processes, expressing control logic such as sequences,

choice, parallel execution and iteration. BPMN models consist of a set of nodes con-

nected by sequence flows or other types of flows. The main symbols are shown in

Table 2. An example BPMN model is shown in Figure 3.

Table 2. BPMN elements.

BPMN element Description

Start Event

Interm. Event

End Event

The Start Event indicates where a particular process will start.

Intermediate Events occur between a Start Event and an End Event

and will affect the flow of the process. The End Event indicates

where a process will end.

Task

A task is an atomic activity within the process. It represents work

to be performed. A task will be activated when one of its incoming

sequence flows is triggered and will trigger all its outgoing se-

quence flows when it is finished.

AND Gateway

An AND Gateway will trigger all outgoing flows, when all incom-

ing flows are triggered.

XOR Gateway

An XOR Gateway will trigger one of its outgoing flows when one

of its incoming flows is triggered.

Subprocess

Subprocesses are used to support hierarchy. A Subprocess contains

its own Start and End Event.

Sequence Flow

The Sequence Flow shows the order in which activities will be

performed in a Process.

2.2 Petri Nets

Petri nets provide a formal method to describe behaviour. A Petri net consists of

places and transitions, connected by directed arcs. A place can only be connected to a

transition and vice versa. In classical Petri nets, these are the only allowed elements.

The formal definition of Petri nets can be found in 14. Petri nets can be extended to

be able to express more behaviour. The Petri nets used here, further referred to as

128

extended Petri nets, are extended with inhibitor 1 and reset arcs 2. In Table 3, the

Petri net elements are explained.

Table 3. Petri net elements.

Element Description

Transition

A transition is a modeling unit representing a process step.

Place

Place with tokens

A place can contain tokens that define a part of the state of the net. A

distribution of tokens over the places is called a marking, representing

the state of the net.

Inflow Arc

An inflow arc is the arrow from a (incoming) place to a transition. If

all incoming places connected to a transition have enough tokens

according to the firing rules, the transition is enabled and can fire.

Outflow Arc

An outflow arc is the arrow from a transition to a (outgoing) place. If a

transition fires, it consumes tokens from its incoming places, and

produces tokens in its outgoing places according to the firing rules.

Reset Arc

When a place is connected to a transition with a reset arc, all tokens

are removed from it when the transition fires.

Inhibitor Arc

When a place connected to a transition via an inhibitor arc contains a

token, the transition cannot be enabled.

Yasper 9 is a Petri net modeller and simulator extending Petri nets with various no-

tions. The most important ones are shown in Table 4. Transitions are also extended

with properties dealing with timing, costs, and resources for simulation purposes.

Table 4. Yasper specific elements.

Element Description

Case sensitivity

(yellow)

Yasper distinguishes between different workflow cases in a process. This is

done with case sensitive places. Transitions having multiple case sensitive

input places can only fire if enough tokens of the same case are present. If a

transition fires, tokens produced in the case sensitive output places have the

same case identity as tokens consumed from the case sensitive input places.

Emitter

A transition, with outflow arcs to case sensitive places but without inflow

arcs from case sensitive places, is drawn differently and is called emitter.

Collector

A transition, with no outflow arcs to case sensitive places but with inflow

arcs from case sensitive places, is drawn differently and is called collector.

XOR

This element requires and consumes one token from one of the places con-

nected with an inflow arc. When the XOR fires, one token is produced in one

of the places (chosen non-deterministically) connected with an outflow arc.

Subnet

This element is used to support hierarchy.

129

2.3 mCRL2

The language mCRL2 8 offers a uniform framework for the specification of data and

processes. Data is specified by equational specifications: one can declare types and

functions working upon these types, and describe the meaning of these functions by

equational axioms. Processes are described in process algebraic style, where the par-

ticular process syntax stems from ACP 4, extended with data-parametric ingredients.

Infinite processes are specified by means of (finite systems of) recursive equations,

which can also be data-parametric. As an example, for action a, each solution for the

equation X=a.X specifies the process that can only repeatedly execute a. Here, X is a

process name and “.” is the sequential composition operator. The Process Y(23),

where Y(n) is defined by the data-parametric equation Y(n)=a.Y(n+1), can do the

same as X.

mCRL2 makes use of multiactions. A multiaction is a collection of ordinary actions

that happen simultaneously as one atomic step. A few examples of multiactions are

a|b, a|b|c and a|a|b. The multiactions are convenient for representing Petri nets be-

cause several actions may be performed synchronously when a transition is being

fired, like removing a token from an input place and adding a token to an output

place. These actions are combined to a multiaction and then hidden in a way that only

the transition name is left visible.

In mCRL2 parallel composition does not communicate. Instead, it introduces multiac-

tions, e.g. the parallel composition a||b of actions a and b is equal to a.b+b.a+a|b,

where + is the alternative composition operator. As a result, the number of multiac-

tions can increase exponentially with the number of parallel compositions. Hence,

operators need to restrict this behaviour. The blocking operator block(H,p) blocks all

multiactions a part of which occurs in the action set H, on the process p. For example:

δ

δ

δ

..))|.(},({ bbcabaablock

=

+=

+

where

δ

is a deadlock process that cannot

execute any action.

Communication of actions is also defined using the concept of multiactions. The local

communication operator comm(C,p) realizes communication of multiactions with

equal data arguments. For instance, comm({_a|a

→__a}, a|_a|c|d) = __a|c|d.

3 Transforming BPMN Models to Petri Nets

The mapping rules for the translation of BPMN to Petri nets are shown in Table 5. If

the resulting Petri nets do not contain reset or inhibitor arcs, most Petri net tools can

be used to analyze the translated BPMN models. The last translation rule in the table

illustrates how a time-out exception is translated. An example of the mapping is

shown in Figure 3. The translation is described in detail in 21.

130

Table 5. The mapping between BPMN and Petri nets.

BPMN elements Petri net elements

Start Event

Emitter connected to place

End Event

Place connected to Collector

Task

Transition

Task with two incoming sequence flows

Merge-like behaviour

Task with two outgoing sequence flows

Fork-like behaviour

A connected Subprocess

A connected Subnet

XOR Gateway

XOR

AND Gateway

Transition

Time-out interruptible task

The translation result of the time-out interruptible

task

131

Fig. 3. An example BPMN model and the derived Petri net.

4 Analyzing Industrial Models using Petri Net-based Tools

Figure 4 depicts the Petri net analyzers and transformations from, to, and between

Petri nets we use.

Fig. 4. Petri net analysis tools and related transformations.

4.1 Yasper

After the transformation of a BPMN model to a Yasper Petri net, Yasper simulations

on the derived Petri net can be used to validate the original model.

Yasper supports automatic simulation, where the transitions to execute are randomly

chosen. Transitions can have a mean execution time and deviation and both fixed

costs and costs per time unit. The automatic simulation uses this information to pro-

vide performance analysis by simulation.

Another facility is the stepwise execution of a net. At each step, the user can select

one of the enabled transitions to execute, after which the state (i.e. the distribution of

tokens) is updated accordingly. This manual simulation helps users to validate their

132

models by enabling them to quickly explore many different process execution paths

and discover that unexpected or incorrect states are reachable.

The Yasper Petri net editor and analysis tool 9 can assist with soundness verification

in several ways. Yasper provides reduction techniques 22 preserving properties like

soundness and liveness. These reductions result in a smaller model which is easier to

analyse.

4.2 Woflan, INA and LoLA

In order to invoke automatic verification tools, like Woflan, INA, and LoLA, the

Yasper Petri nets are transformed to classical Petri nets. This can only be done if the

net does not contain reset arcs or inhibitors.

Woflan 19, the Workflow Analyzer, is a software tool with the specific purpose of

analyzing workflow Petri nets for soundness. Applied to a net it reports whether the

net is a valid workflow net, and if so, whether it is sound; if not, it lists one or more

specific problems with the net.

INA 16, the Integrated Net Analyzer, provides traditional Petri net analysis on

classical Petri nets: it can check a number of Petri net properties and show the invari-

ants, the reachability and the coverability graphs of a Petri net. INA also offers model

checking with temporal logic on Petri nets to verify properties of the system.

LoLA 17 is a model checking tool which tackles the state space explosion by us-

ing reduction techniques. Therefore, INA is first used to check the Petri net, and then

LoLA is used to verify properties on the system.

5 Petri Nets to mCRL2

If the Petri net contains reset arcs or inhibitor arcs, most Petri net tools cannot be

used. In this case, our solution is transforming the extended Petri net to mCRL2, to

enable automatic verification.

Petri nets are input to the transformation to mCRL2 specifications. Petri nets consist

of a finite set of places {P

1

,...,P

n

}, transitions {T

1

,...,T

m

}, and arcs {a

1

,...,a

k

, a'

1

,…,a'

l

}

that connect places to transitions (inflow arcs), and vice versa (outflow arcs). The arcs

may be ordinary, inhibitor or reset arcs. Besides the Petri net itself, also the initial

marking of the Petri net is used for the translation to mCRL2.

133

Fig. 5. mCRL2 actions mapped to the arcs and transitions of a Petri net.

As illustrated in Figure 5 the result of the transformation, a mCRL2 specification, is

constructed in the following way:

Each arc is represented by three actions in mCRL2: a and _a represent the outflow

actions and the inflow actions associated with the arc, and __a represents their syn-

chronization where __a = a|_a.

Each transition T

i

is represented by the process

iipxiipxii

taaaaT |'||'|_||

1111

KK=

where a

i11

,...,a

ipx

are the inflow arcs that enter T

i

and _a'

i11

,...,_a'

ipx'

are the outflow

arcs that depart from T

i

. Action t

i

is used to indicate that transition T

i

has fired.

Each place P

j

is represented by the process equation

∑

∈

+−→≥=

},,1{

),('1),(1

)),('),((.'||'|_||_)),(():(

qi

jjiijpijjiijpijj

jipjipnPaaaajipnNatnP

K

KK

where q is the number of different transitions connected to P

j

by an arc, and the ac-

tions _a

ijx

and a'

ijx

are the inflow and the outflow actions corresponding to the inflow

and outflow arcs connecting place P

j

and transition T

i

, respectively. The parameter n

represents the amount of tokens P

j

contains, p(i,j) is the number of inflow arcs from

P

j

to T

i

, and p'(i,j) is the number of outflow arcs from T

i

to P

j

.

In case of inhibitor arcs we check if the adjacent place is empty using the condition

n=0 in the above process equation. In case of reset arcs we set the number of tokens

to be the number of incoming arcs by changing the recursive call to P

j

(p'(i,j)) in the

above process equation.

All transitions are combined in one process T = (T

1

+...+T

m

).T which represents that

the transitions must be interleaved, and do not happen simultaneously.

The whole system is represented by the parallel composition of all processes repre-

senting places, where the actions representing arcs are forced to synchronize:

S = hide({__a},block({a,_a},comm({a|_a→__a},P

1

||...||P

n

||T)))

The arc firing actions are hidden, which only leaves the t

i

actions visible. This shows

when a particular transition fires.

134

5.1 Analyzing Petri Nets using the mCRL2 Toolset

The mCRL2 toolset allows to generate a transition system (state space) corresponding

to the generated mCRL2 specification derived from the Petri net. The labels of this

transition system represent the firings of the transitions of the Petri net. Each path in

the generated transition system can be simulated with Petri net simulation tools. The

mCRL2 toolset can automatically find deadlock traces starting from the system’s

initial state and resulting in a state from where no transitions are enabled.

Furthermore, the mCRL2 toolset can visualize the state spaces. This can be used to

find livelock-states from which it is possible to keep repeating the same set of activi-

ties, but from which it is impossible to perform a sequence of activities that lead the

system to the desired final state.

6 Case Study

One of our clients is maintaining business processes related to various sectors. Educa-

tion is one of these sectors and its processes are stored as BPMN models. We re-

ceived six BPMN models and performed automated error detection on these models.

We translated the BPMN models to Petri nets and subsequently invoked Woflan on

the Petri nets to perform automatic verification. The results are shown in Table 6.

Table 6. The results of the analysis of the BPMN models.

Model

number

Number of

BPMN

elements

Number of

Petri net

elements

Woflan result

1 14 26 1 AND-OR mismatch

2 41 79 No workflow (unrelated nodes)

3 17 33 Sound workflow process definition

4 73 143 2 AND-OR mismatches

5 93 176 5 AND-OR mismatches

6 62 114 No workflow (no unique start condition)

The column ‘Woflan result’ contains the summarized conclusion of Woflan.

After retrieving the results, we had to translate them back in terms of the BPMN

models to locate the errors. In the reports, Woflan printed the names of the Petri net

transitions involved in the error. Since the transition names are identical to the BPMN

task names and as the translation uses the BPMN lay-out to generate the Petri net lay-

out, it was relatively easy to locate the BPMN tasks involved.

Two of the analyzed models are no workflows and eight AND-OR mismatches

were found in the four remaining models. The AND-OR mismatches reported by

Woflan indicate that a parallel split is not matched by a parallel join, while it should

be joined by a parallel join. The unrelated nodes, indicated by Woflan in Table 6,

turned out to be a livelock. A livelock state is a state from which it is possible to pro-

135

ceed, but from which it is impossible to reach the desired final state. Table 7 shows

how the livelock and an AND-OR mismatch found in the Petri net relate to errors in

the BPMN model.

Table 7. Interpreting the analysis results.

The Livelock in the BPMN model The Livelock in the Petri net

The AND-OR mismatch in the BPMN

model

AND-OR mismatch in the Petri net

Once task A from the shown livelock is triggered, the process will reach a livelock

state. Most AND-OR mismatches were similar to the one that is shown. Two se-

quence flows leaving task A means that both task B and C will be triggered, but the

two sequence flows entering task E, result in task E being triggered twice. These

errors can be prevented by forbidding modellers to model tasks which have multiple

incoming and outgoing sequence flows. Instead gateways should be used.

7 Conclusions and Future Work

We now have an operational tool to perform BPMN model translations that we can

further extend with more advanced BPMN constructs. We have employed it on pre-

existing BPMN models in actual use, and found many actual inconsistencies with the

models, clearly pointing out the need for the modellers to improve their models be-

fore they can be used as exact specifications.

Our next goal is to be able to automatically present the Petri net and mCRL2 analysis

results in terms of the original model. For example, we want to parse deadlock traces,

which can be sequences of the elements of a Petri net model, and subsequently auto-

matically back-translate these to deadlock traces in terms of the original BPMN mod-

els. This should fasten the interpretation of analysis results to original models.

References

1. Agerwala, T.: A complete model for representing the coordination of asynchronous proc-

esses. Technical report, John Hopkins University, Baltimore, Maryland. (1974)

2. Araki, T., Kasami, T.: Some decision problems related to the reachability problem for Petri

nets. Theoretical Computer Science 3(1) (1976) 85-104

136

3. Baresi, L.; Pezzè, M.: On Formalizing UML with High-Level Petri Nets. In: Agha, G.A.;

De Cindio, F.; Rozenberg, G.: Lecture Notes in Computer Science, Vol. 2001: Concurrent

Object-Oriented Programming and Petri Nets, Advances in Petri Nets, pages 276-304.

Springer-Verlag, 2001.

4. Baeten, J.C.M., Weijland, W.P.: Process Algebra. Cambridge Tracts in Theoretical Com-

puter Science 18, Cambridge University Press (1990)

5. Billington, J., Christensen, S., Hee van, K., Kindler, E., Kummer, O., Petrucci, L., Post, R.,

Stehno, C., Weber, M.: The Petri Net Markup Language: Concepts, Technology, and

Tools. In: Proc. ICATPN 2003, Eindhoven. LNCS 2679, Springer-Verlag (2003) 483-505

6. Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modeling Language User Guide. Ad-

dison-Wesley, Reading (1999)

7. Curbera, F., Goland, Y., Klein, J., Leymann, F., Roller, D., Thatte, S., Weerawarana, S.,

Business Process Execution Language for Web Services, Version 1.0, (2002)

8. Groote, J.F., Weerdenburg van, M.J., Mathijssen, A.H.J., Usenko, Y.S.: From µCRL to

mCRL2. Motivation and outline. In: Aceto, L., Gordon, A.D. (eds.): Short contrib.. Work-

shop on Algebraic Process Calculi: The First Twenty Five Years and Beyond, BRICS

Technical Report NS-05-3 (2005) 126-131

9. Hee van, K., Post, R., Somers, L.: Yet Another Smart Process EditoR. In: Feliz-Teixeira, J.,

Carvalho Brito, A.E. (eds.): Proc. European Simulation and Modelling Conference

(ESM2005), Eurosis-ETI, Ostend, ISBN 90-77381-22-8 (2005) 527-530

10. Home page http://www.omg.org/

11. Keller, G., Nüttgens, M., Scheer, A. W., Semantische Prozessmodellierung auf der Grund-

lage "Ereignisgesteuerter Prozessketten (EPK)", Heft 89, Institut für Wirtschaftsinfor-

matik, Saarbrücken, Germany (1992)

12. Ouyang, C., Verbeek, E., Aalst van der, W.M.P., Breutel, S., Dumas, M., Hofstede ter,

A.H..: Formal Semantics and Analysis of Control Flow in WS-BPEL. Technical report (re-

vised version), Queensland University of Technology (October 2005)

13. Raedts, I., Petkovic, M., Serebrenik, A., Werf van der, J.M.E.M., Somers, L.J.A.M., Boote,

M.: A Software Framework for Automated Verification. In: Proceedings 22nd Annual

ACM Symposium on Applied Computing, Seoul, (2007) 1031-1032.

14. Ratzer, A., Wells, L., Lassen, H.M., Laursen, M., Qvortrup, J.F., Stissing, M.S., Wester-

gaard, M., Christensen, S., Jensen, K.: CPN Tools for Editing, Simulating, and Analysing

Coloured Petri Nets. In: Proc. ICATPN 2003, Eindhoven. LNCS 2679, Springer-Verlag

(2003) 450-462.

15. Reisig, W.: Petri Nets, An Introduction. Springer-Verlag, Berlin (1985)

16. Roch, S., Starke, P.: INA: Integrierter Netzanalysator, Handbuch, version 2.1. Technical

report, Humboldt-Universitaet zu Berlin (1998)

17. Schmidt, K.: LoLA: A Low Level Analyser. In: Nielsen, M., Simpson, D. (eds.): Proc.

ICATPN 2000. LNCS 1825, Springer-Verlag (2000) 465-474

18. Stahl, C.: A Petri Net Semantics for BPEL. Technical Report 188, Humboldt-UniversitÄat

zu Berlin (July 2005)

19. Verbeek, H.M.W., Basten, T., Aalst van der, W.M.P.: Diagnosing Workflow Processes

using Woflan. The Computer Journal 44(4) (2001) 246-279

20. Verbeek, H.M.W. Dongen van, B.F. : Translating labelled P/T nets into EPCs for sake of

communication, In: BETA Working Paper 194, January 2007, Eindhoven University of

Technology

21. Vijverberg, W., Translation of Process Modeling Languages, Master’s thesis, Eindhoven

(2006)

22. Werf van der, J.M.E.M.: Analysis of well-formedness and soundness by reduction tech-

niques and their implementation. Master thesis, Eindhoven (2006)

23. White, S.A.: Business Process Modeling Notation (BPMN) Version 1.0 - May 2004

137