Business Processes Modelling MPB (6 cfu, 295AA)didawiki.di.unipi.it/.../mpb/21-epc-2018.pdf · Event-driven Process Chain 3 An Event-driven Process Chain (EPC) is a particular type

Business Processes Modelling MPB (6 cfu, 295AA)

Roberto Bruni http://www.di.unipi.it/~bruni

21 - Event-driven process chains

!1

http://www.di.unipi.it/~bruni

Object

2

We overview EPC and the main challenges that arise when analysing

them with Petri nets

Ch.4.3, 6 of Business Process Management: Concepts, Languages, Architectures

Petri Net Transformations for Business Processes – A Survey 53

Legend

Start u V

XOR

V

f

t

e

m

l

V

XOR

XOR

XOR

Finishimage

Create thumbnail

Evaluate

Send image

Send link

Imagesent

Link sent

redo

Image too big

Image small enough

thumbnail failed

finish failed

XOR

XOR

V

V V

VXOR-split –Exclusive choice

XOR-join –Simple merge

AND-split –Parallel split

OR-split –Multi-choice

AND-join –Synchronization

OR-join –Gen. Sync. Merge

Simple flow – Sequence

function functionevent

Start event End event

Fig. 4. The example process as an EPC

Three types of EPC objects can be used to model the control-flow aspectof a process: functions, events, and connectors. In a natural way, these typescorrespond to the BPMN activities, events, and gateways. However, EPCs donot allow for exceptions, and it supports only a limited set of connectors, whichis shown by Fig. 4. Apart from the full set of connectors, this figure also shows anthe example process as an EPC, and it relates the object types to the workflowpatterns explained in Section 2.2.

4.2 Transformation Challenges

A main challenge in EPCs is the semantics of the constructs that support the‘Simple Merge’ and ‘General Synchronizing Merge’ patterns, viz. the XOR-joinconnector and the OR-join connector. Everybody agrees that the XOR-join con-nector should be enabled if one of its inputs is enabled, but this agreement islacking in case more than one inputs is enabled. Some say that the XOR-joinshould be executed for every single enabled input, while others say that theconnector should block if multiple inputs are enabled. An even bigger problemis the OR-join connector, for which a definitive semantics has lead to exten-sive discussions in literature and to different solutions, all of which fail for someEPCs [17,18,19]. As a result, not everybody will agree on a given mapping, asnot everyone will agree with the semantics used by it.

Furthermore, an EPC allows for multiple start events and multiple finalevents, but not all combinations of these events are possible. Although the pro-cess designer might know the possible combinations, an EPC does not containthis information.

Event-driven Process Chain

3

An Event-driven Process Chain (EPC) is a particular type of flow-chart

that can be used for configuring an Enterprise Resource Planning (ERP) implementation

Supported by many tools (e.g. SAP R/3)

EPC Markup Language available (EPML) as interchange format

EPC overview

4

Rather informal notation simple and easy-to-understand

EPC focus is on representing domain concepts and processes

(not their formal aspects and technical realization)

It can be used to drive the modelling, analysis and redesign of business process

EPC origin

5

EPC method was originally developed by Wilhelm-August Scheer (early 1990’s)

Part of a holistic modelling approach called ARIS framework

(Architecture of Integrated Information Systems)

EPC informally

6

An EPC is an “ordered” graph of events and functions

It provides various connectors that allow alternative and parallel execution of processes

The flow is specified by logical operators AND, XOR, OR

Events

7

Any EPC diagram must start with event(s)

and end with event(s)

Passive elements used to describe under which circumstances a process (or a function) works

or which state a process (or a function) results in (like pre- / post-conditions)

Graphical representation: hexagons

Functions

8

Any EPC diagram may involve several functions

Active elements used to describe the tasks or activities of a business process

Functions can be refined to other EPC diagrams

Graphical representation: rounded rectangles

Logical connectors

9

Any EPC diagram may involve several connectors

Elements used to describe the logical relationships between elements in the diagram

Branch, merge, fork, join

Graphical representation: circles (or also octagons)

∧ ∨

X

AND OR

XOR

Control flow

10

Any EPC diagram may involve several control flow connections

Control flow is used to connect events with functions and connectors by expressing causal dependencies

Graphical representation: dashed arrows

EPC ingredients at a glance

11

EPC diagrams

12

EPC elements can be combined in a fairly free manner (possibly including cycles)

There must be at least one start event and one end event Events have at most one incoming and one outgoing arc

Events have at least one incident arc

Functions have exactly one incoming and one outgoing arc

The graph is weakly connected (no isolated nodes)

Connectors have either one incoming arc and multiple outgoing arcs or viceversa (multiple incoming arcs and one outgoing arc)

EPC ingredients: Diagrams

13

Other constraints are sometimes imposed

Unique start / end event

No arc between two events No arc between two functions

No event is followed by a decision node (i.e. (X)OR-split)

Connections NOT allowed: Examples

14

Connections NOT allowed: Examples

15

∨ XOR

Other annotations for functions

16

Organization unit: determines the person or organization responsible for a specific function (ellipses with a vertical line)

Supporting system: technical support (rectangles with vertical lines on its sides)

Information, material, resource object: represents objects in the real world e.g. input data or output data for a function (rectangles linked to function boxes) angles with vertical lines on its sides)

17

18

19

20

21

22

23

24

EPC an example

25

Petri Net Transformations for Business Processes – A Survey 53

Legend

Start u V

XOR

V

f

t

e

m

l

V

XOR

XOR

XOR

Finishimage

Create thumbnail

Evaluate

Send image

Send link

Imagesent

Link sent

redo

Image too big

Image small enough

thumbnail failed

finish failed

XOR

XOR

V

V V

VXOR-split –Exclusive choice

XOR-join –Simple merge

AND-split –Parallel split

OR-split –Multi-choice

AND-join –Synchronization

OR-join –Gen. Sync. Merge

Simple flow – Sequence

function functionevent

Start event End event

Fig. 4. The example process as an EPC

Three types of EPC objects can be used to model the control-flow aspectof a process: functions, events, and connectors. In a natural way, these typescorrespond to the BPMN activities, events, and gateways. However, EPCs donot allow for exceptions, and it supports only a limited set of connectors, whichis shown by Fig. 4. Apart from the full set of connectors, this figure also shows anthe example process as an EPC, and it relates the object types to the workflowpatterns explained in Section 2.2.

4.2 Transformation Challenges

A main challenge in EPCs is the semantics of the constructs that support the‘Simple Merge’ and ‘General Synchronizing Merge’ patterns, viz. the XOR-joinconnector and the OR-join connector. Everybody agrees that the XOR-join con-nector should be enabled if one of its inputs is enabled, but this agreement islacking in case more than one inputs is enabled. Some say that the XOR-joinshould be executed for every single enabled input, while others say that theconnector should block if multiple inputs are enabled. An even bigger problemis the OR-join connector, for which a definitive semantics has lead to exten-sive discussions in literature and to different solutions, all of which fail for someEPCs [17,18,19]. As a result, not everybody will agree on a given mapping, asnot everyone will agree with the semantics used by it.

Furthermore, an EPC allows for multiple start events and multiple finalevents, but not all combinations of these events are possible. Although the pro-cess designer might know the possible combinations, an EPC does not containthis information.

EPC intuitive semantics

26

A process starts when some initial event(s) occurs

The activities are executed according to the constraints in the diagram

When the process is finished, only final events have not been dealt with

If this is always the case, then the EPC is “correct”

EPC semantics?

27

Little unanimity around the EPC semantics

Rough verbal description in the original publication by Scheer (1992)

Later, several attempts to define formal semantics (assigning different meanings to the same EPC)

Discrepancies typically stem from the interpretation of (X)OR connectors (in particular, join case)

Other issues: unclear start, alternation between events and functions,

join/split correspondence

Problem with start events

28

A start event is an event with no incoming arc

A start event invokes a new execution of the process template

What if multiple start events occur?

Solution: Start events are mutually exclusive

(as if they were preceded by an implicit XOR split)

Problem with start events: solution

29

A B

XOR

hypothetical / implicit split

Problem with alternation

30

From empirical studies: middle and upper management people consider strict alternation between events and functions

as too restrictive: they find it hard to identify the necessary events at the

abstract level of process description they are working at

Solution: It is safe to drop the requirement about alternation

(dummy events might always be added later)

Every join has a split

31

observation: Every join has at least one corresponding split

(i.e. a split for which there is a path from either output to the input of the join)

proof sketch: we trace backward the paths

leading to the join from start events; if the start events coincide there is a split node in the path; if start events differ, the candidate split is the implicit XOR

Problem with corresponding splits

32

The semantics of a join often depends on the nature of the corresponding split

But: 1) there can be more candidates to corresponding split 2) and they can have different type than the join

candidates of the same type of the join are called matching split

Some suggested to have a flag that denotes the corresponding split

Tagging corresponding splits

33

∨

∨

∨∨

s1

s2

j1

j2


34

∨

∨

∨∨

s1

s2

j1

j2


35

∨

∨

∨∨

s1

s2

j2

j1 {s1}


36

∨

∨

∨∨

s1

s2

j2

j1 {s1}


37

∨

∨

∨∨

s1

s2

j1 {s1}

j2 {s2}

Problem with OR join

38

If an OR join has a matching split, the semantics is usually: “wait for the completion of all paths activated by the matching split”

If there is no matching split, some policy must be applied:

wait-for-all: wait for the completion of all activated paths (default semantics, because it coincides with that of a matching split)

first-come: wait only for the path that is completed first and ignore the second

every-time: trigger the outgoing path on each completion (the outgoing path can be activated multiple times)

Some suggested to have different (trapezoid) symbols or suitable flags to distinguish the above cases

Problem with XOR join

39

Similar considerations hold for the XOR join

If a XOR join has a matching split, the semantics is intuitive: “it blocks if both paths are activated and

it is triggered by the completion of a single activated path”

If there is no matching split: all feasible interpretations that do not involve blocking are already

covered by the OR (wait-for-all, first-come, every-time) and contradict the exclusivity of the XOR

(a token from one path can be accepted only if we make sure that no second token will arrive via the other path)

Some suggest to just forbid the use of XOR in the unmatched case (the implicit start split is allowed as a valid match)

Sound EPC diagrams

40

We transform EPC diagrams to Workflow nets: the EPC diagram is sound if its net is so

We can exploit the formal semantics of nets to give unambiguous semantics to EPC diagrams

We can reuse the verification tools to check if the net is sound

Translation of EPC to Petri nets

41

A note about the transformation

42

We first transform each event, function and connector separately in small net fragments

When translating the control flow arcs we may then introduce other places / transitions to preserve

the bipartite structure in the net (no arc allowed between two places,

no arc allowed between two transitions)

We show different translations, depending on whether joins are decorated or not

First attempt (decorated EPC)

43

PETER RITTGEN MODIFIED EPCS AND THEIR

FORMAL SEMANTICS

Oktober 1999

Arbeitsberichte des Instituts für Wirtschaftsinformatik Nr. 19

PETER RITTGEN MODIFIED EPCS AND THEIR

FORMAL SEMANTICS

Oktober 1999

Arbeitsberichte des Instituts für Wirtschaftsinformatik Nr. 19

EPC

44

Petri net

A

event place

EPC

45

Petri net

function transition

EPC

46

Petri net

AND split net

∧

EPC

47

Petri net

XOR split net

XOR

EPC

48

Petri net

OR split net

∨ xor +

and

EPC

49

Petri net

AND join net

∧

EPC

50

Petri net

net

XOR

XOR join

corresponding split

?...

...

EPC

51

Petri net

net

XOR

XOR join

most general case ? ? ?

......

EPC

52

Petri net

net

XOR join

corresponding XOR/OR split

ok

?

XOR...

...

EPC

53

Petri net

net

XOR join

corresponding AND/OR split

deadlock!

? ?

XOR...

...

EPC

54

Petri net

net

XOR join

better to have a corresponding

XOR split!

XOR...

...

EPC

55

Petri net

net

∨

OR join

corresponding split

?...

...

EPC

56

Petri net

net

∨

OR join with

matched OR split

matching OR split

......

EPC

57

Petri net

net

∨

OR join wait-for-all

(mismatched)

mismatched corresponding split: most general

casewfa

? ? ?...

...

EPC

58

Petri net

net

∨


(mismatched)

corresponding AND split

wfa...

...

EPC

59

Petri net

net

∨


(mismatched)

corresponding XOR split

wfa...

...

EPC

60

Petri net

net

∨


(mismatched)

wfa works well with any

corresponding split

wfa

? ? ?...

...

EPC

61

Petri net

net

∨

OR join first-come

(mismatched)

fc

? ? ?


case...

...

EPC

62

Petri net

net

∨

OR join first-come

(unmatched)


fc

ok

......

EPC

63

Petri net

net

∨

OR join first-come

(unmatched)


fc

pending token!

......

EPC

64

Petri net

net

∨

OR join first-come

(mismatched)

fc

fc: better to have

a corresponding XOR split!

......

EPC

65

Petri net

∨

OR join every-time

(mismatched)

et

? ? ?

net


case...

...

EPC

66

Petri net

∨

OR join every-time

(mismatched)

et


oknet

......

EPC

67

Petri net

∨

OR join every-time

(unmatched)

et


multiple tokens! net

......

EPC

68

Petri net

∨

OR join every-time

(mismatched)

et

net

et: better to have

a corresponding XOR split!

......

69

split

∧

∨

XOR

join

corresp. split

matched OR split

corresp. split: wfa

corresp. split: fc

corresp. split: et

......

......

...... ...

...

70

split

∧

∨

XOR

join

corresp. split

matched OR split

corresp. split: wfa

corresp. split: fc

corresp. split: et

better to have a

corresp. XOR split

better to have a

corresp. XOR split

Ill-formed net

71

Petri net

dummy transition

Ill-formed net

72

Petri net

dummy place

Example

73

9

Fig. 13: Example of a modEPC

implicit XOR

J2

Example

74

9


implicit XOR

Example

75

9


Example

76

9


Example

77

9


Exercise

78

9


(first-come)

Sound?

matching split

matching split

implicit XOR

matching split

J2

ZOOM IN

79

9

Fig

. 13:

Exam

ple

of

a m

od

EP

C

(first-come)

J2

ZOOM IN

80

Exercise

81

Sound?

2 The informal semantics of EPCs

We start with a brief discussion of the informal semantics of EPCs, where we focus on one

speciality of the semantics of EPCs, which we call non-locality. Figure 1 shows a simple

example of an EPC. The dynamic behaviour of the EPC is best illustrated by process

folders, which are propagated between the different nodes of the EPC along its control

flow arcs. The connectors, which are represented as circles, may join and split process

folders. This way, the connectors define the routing and the synchronization of process

folders. For our example, we assume that, initially, there is one process folder on each of

the two events Start1 and Start2.

Inner2

f’2f’1

Inner1

Stop2

f2

Start2

By−pass

Empty

f1

Start1

Stop1

Figure 1: A simple EPC

First, we discuss what happens to the process folder on Start1: This process folder is

passed to function f1. At the XOR-split connector below f1, the process folder is either

propagated to the By-pass event or to the Inner1 event. If the process folder is propagated

to the By-pass event, it is further propagated to the Empty function, and then passed on to

the Stop1 event via the XOR-join connector. If the folder is passed to the Inner1 event,

it is further propagated to the function f’1 and then reaches the AND-split connector. At

the AND-split the process folder is duplicated. The two copies are propagated via the two

outgoing arcs. One process folder is propagated to the XOR-join, the other is propagated

to the OR-join on the right-hand side.

Second, we discuss what happens to the process folder on Start2: This process folder

is propagated to function f2. What happens at the OR-join below function f2 depends

on the behaviour of the left-hand part of the EPC. If there is the possibility that a process

folder will arrive from the left-hand part, the OR-join delays the propagation of the process

2

Summary of problems

82

We need to decorate the EPC diagram joins must be decorated with matching/corresponding splits

mismatched OR-joins must be decorated with policies

Split / join mismatch may induce unexpected behaviour

Possible introduction of dummy places and transitions

Second attempt (no decoration required)

83

Formalization and Verificationof Event-driven Process ChainsW.M.P. van der AalstDepartmentofMathematics and ComputingScience, EindhovenUniversity of Technology,P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands, telephone: -31 40 2474295,e-mail: [email protected]

AbstractFor many companies, business processes have become the focal point of atten-tion. As a result, many tools have been developed for business process engineer-ing and the actual deployment of business processes. Typical examples of thesetools are BPR (Business Process Reengineering) tools, ERP (Enterprise ResourcePlanning) systems, and WFM (Workflow Management) systems. Some of the lead-ing products, e.g. SAP R/3 (ERP/WFM) and ARIS (BPR), use Event-driven Pro-cess Chains (EPCs) to model business processes. Although event-driven processchains have become a widespread process modeling technique, they suffer from aserious drawback: neither the syntax nor the semantics of an event-driven processchain are well defined. In this paper, this problem is tackled by mapping event-driven process chains (without connectors of type ) onto Petri nets. Petri netshave formal semantics and provide an abundance of analysis techniques. As a re-sult, the approach presented in this paper gives formal semantics to event-drivenprocess chains. Moreover, many analysis techniques become available for event-driven process chains. To illustrate the approach, it is shown that the correctnessof an event-driven process chain can be checked in polynomial time by using Petri-net-based analysis techniques.

Keywords: Event-driven process chains, Petri nets, workflow management, veri-fication.

1 IntroductionAs a response to increased competitive pressure in the global marketplace, enter-prises are looking to improve the way they are running their businesses. The termbusiness process engineering ([27]) subsumes the set of principles, activities, and

1

Simplified EPC

84

We rely on event / function alternation along paths in the diagram

and also along paths between two connectors

OR-connectors are not considered

EPC 2 Petri nets: events and functions

85

event

function

place

transition

Figure 3: Events are mapped onto places and functions are mapped onto transi-

tions.

tions. The translation of connectors is much more complex. A connector may cor-

respond to a number of arcs in the Petri net or to a small network of places and

transitions. Figure 4 shows the rules that are used to map connectors onto Petri net

constructs. The behavior of a connector of type corresponds to the behavior of

a place, i.e., a connector of type agrees with a node of type ‘place’ in the Petri

net. A connector of type agrees with a node of type ‘transition’. If the type of a

join connector agrees the type of the output node in the corresponding Petri net, the

connector is replaced by two or more arcs. For example, a join connector of type

corresponds to a number of arcs in the Petri net if and only if the output node is

a transition (see Figure 4). If the type of a join connector and the type of the output

node do not agree, the connector is replaced by a small network. If the type of a

split connector does not agree with the type of the input node in the Petri net, the

connector is replaced by a small network. Otherwise, the connector is replaced by

a number or arcs.

Figure 4 does not give any constructs for connectors of type . The semantics of

join connectors of type are not clear. This problem is tackled in Section 6. For

the moment, we assume all the connectors to be of type or . Based on this

assumption the formalization of the mapping is rather straightforward.

Definition 5 ( ) Let be an event-driven process chain

with and . is the Petri

net generated by : , , and

. See Table 1 for the definition

of , , and .

The places in the Petri net correspond either to events or to constructs needed to

model the behavior of a connector in the event-driven process chain. Transitions

correspond to functions or are the result of the translation of a connector. Each

10

EPC 2 Petri nets: split/join connectors

86

The translation of logical connectors depends on the context:

if a connector connects functions to events we apply a certain translation

if it connects events to functions we apply a different translation

EPC 2 Petri nets: AND split

87

V V

e1 e2

f1

XOR

e1 e2

f1

e1 e2

f1

V V

XOR

f1

e1 e2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

e1 e2

f1

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

f1

e1 e2

XOR XOR

Figure 4: Mapping connectors onto places and transitions.

11

(event to functions) (function to events)

EPC 2 Petri nets: AND-join

88

V V

e1 e2

f1

XOR

e1 e2

f1

e1 e2

f1

V V

XOR

f1

e1 e2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

e1 e2

f1

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

f1

e1 e2

XOR XOR


11

(events to function) (functions to event)

EPC 2 Petri nets: XOR split

89

V V

e1 e2

f1

XOR

e1 e2

f1

e1 e2

f1

V V

XOR

f1

e1 e2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

e1 e2

f1

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

f1

e1 e2

XOR XOR


11

(event to functions) (function to events)

EPC 2 Petri nets: XOR join

90

V V

e1 e2

f1

XOR

e1 e2

f1

e1 e2

f1

V V

XOR

f1

e1 e2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

e1 e2

f1

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

f1

e1 e2

XOR XOR


11

(events to function) (functions to event)

EPC 2 Petri nets: at a glance

91

V V

e1 e2

f1

XOR

e1 e2

f1

e1 e2

f1

V V

XOR

f1

e1 e2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

e1 e2

f1

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

f1

e1 e2

XOR XOR


11

V V

e1 e2

f1

XOR

e1 e2

f1

e1 e2

f1

V V

XOR

f1

e1 e2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

e1 e2

f1

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

f1

e1 e2

XOR XOR


11

V V

e1 e2

f1

XOR

e1 e2

f1

e1 e2

f1

V V

XOR

f1

e1 e2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

e1 e2

f1

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

f1

e1 e2

XOR XOR


11

V V

e1 e2

f1

XOR

e1 e2

f1

e1 e2

f1

V V

XOR

f1

e1 e2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

e1 e2

f1

e1

f1 f2

e1

f1 f2

e1

f1 f2

f1

e1 e2

f1

e1 e2

XOR XOR


11

event

function

place

transition


tions.














a number or arcs.









of , , and .




10

event

function

place

transition


tions.














a number or arcs.









of , , and .




10

EPC 2 nets: Example

92

connector corresponds to the places, transitions and/or arcs listed in Table 1.

In Table 1 it is assumed that connectors are only connected to functions and events,

i.e., . Although it is possible to extend Table 1 with additional rules

for connections between connectors, we use an alternative approach. Every arc

connecting two connectors is replaced by an event and a function, i.e., fake events

and functions are added to the event-driven process chain before the translation to a

Petri net. Figure 5 illustrates the approach that is used to handle arcs in .

The arc between the XOR-join (join connector of type ) and the AND-join

(join connector of type ) is replaced by function X and event X and three arcs.

The arc between the AND-join and the XOR-split is also replaced by a function,

an event and three arcs.

XOR

V

XOR

event A event B event C

function D function E

function X

event X

function Y

event Y

XOR

V

XOR

event A event B event C


event C

function X

event X

event Y

function Y


event A event B

Figure 5: Arcs between connectors are replaced by events and functions before the

event-driven process chain is mapped onto a Petri net.

Figure 6 shows the Petri net which corresponds to the event-driven process chain

shown in Figure 1. Note that the arc between the two XOR connectors is replaced

by an event and a function, and mapped onto an additional place and transition in

the Petri net. In this case there was no real need to add these additional nodes.

However, there are situations where adding events and functions is the only way

to model the control flow properly.

It is easy to see that for any event-driven process chain

satisfying the requirements in Definition 4, is a

Petri net, i.e., and .

Moreover, the Petri net is free-choice (see Definition 12).

13

(add dummy events and functions)

(context-dependent translation)

Outcome

93

From any EPC we derive a free-choice net

Moreover, if we add unique start / end events (and suitable transitions attached to them)

the net is a workflow net

Exercise

94

XOR

XOR

V

V

XOR

customerorder

received

ordercustomer

order

order data

customer

accepted rejected

checkavailability

articles

available

articles need to beproduced

purchase

material

makeproduction

plan

material

available

plan

available

produce

articles

finished

product

ship

order

XOR

XOR

customerorder

order

shipped

bill

send

outstanding

accounts

check

payment

completed

customercompare

Figure 1: Modeling of a business process, using event-driven process chains.

5

customerorder

received

ordercustomer

order

order data

customer

accepted rejected

checkavailability

articles

available

articles need to beproduced

purchase

material

makeproduction

plan

material

available

plan

available

produce

articles

finished

product

ship

order

customerorder

order

shipped

bill

send

outstanding

accounts

check

payment

completed

comparecustomer

Figure 6: The event-driven process chain of Figure 1, mapped onto a Petri net.

14

Check it sound!

Exercise

95

V

V

ordercustomer

purchase

material

makeproduction

plan

material

available

plan

available

produce

articles

finished

product

received

customerorder

register

XOR

bill

send

outstanding

accounts

V

V

XOR

start startproductionbilling

XOR

check

payment

completedbilling

ship

order

order

shipped

V

XOR

nobillingneeded

Figure 7: An erroneous event-driven process chain.

18

(remind to add dummy events and functions

and to guarantee event/function alternation)

Sound?

Relaxed soundness (a third attempt)

96

Popularity vs superiority

97

EPC are a quite successful, semiformal notation

They lack a comprehensive and consistent syntax They lack even more a corresponding semantics

You may restrict the notation, but people will prefer the more liberal (flexible) syntax and ignore the guidelines

You may enrich the notation, but people will dislike or misinterpret implementation policies

What are ultimately business process?

98

Graphical language to communicate concepts

Careful selection of symbols shapes, colors, arrows

(the alphabet is necessary for communication)

Greatest common denominator of the people involved

Intuitive meaning (verbal description, no math involved)

Remember some good old friends

99

Chief Process Officer

Process designer

System architect

System developer

Business engineer

Process participants

Knowledge workerProcess responsible

EPCWFnet

A secret not to tell

100

Ambiguity is useful in practice!

The more ways are to interpret a certain construct the more likely an agreement will be reached

A pragmatic consideration

101

Moreover

in the analysis phase the participants may not be ready

to finalise the specification and decide for the correct interpretation

Yet

it is important to find out flaws as soon as possible

Consequences

102

Ambiguous process descriptions arise in the design phase

therefore

we need to fix a formal representation that preserves all ambiguities

Problem

103

EPC is fine (widely adopted)

WF nets offer a useful tool

but

Soundness is too demanding at early stages

Relaxed soundness

104

A sound behaviour: we move from a start event to an end event so that nothing blocks or remains undone

Execution paths leading to unsound behaviour can be used to infer potential mistakes in the EPC

If some unsound behaviour is possible but enough sound paths exist

the process is called relaxed sound

A 3-steps approach (keep it simple!)

105

K.R. Dittrich, A. Geppert, M.C. Norrie (Eds.): CAiSE 2001, LNCS 2068, pp. 157–170, 2001. © Springer-Verlag Berlin Heidelberg 2001

Relaxed Soundness of Business Processes

Juliane Dehnert1,∗ and Peter Rittgen2

1 Institute of Computer Information Systems, Technical University Berlin, Germany [email protected]

2 Institute of Business Informatics, University Koblenz-Landau, Germany [email protected]

Abstract. Business processes play a central role in the reorganization of a company and the (re)design of the respective information system(s). Typically the processes are described with the help of a semiformal, graphical language such as the Event-driven Process Chains (EPCs) by Scheer. This approach provides a suitable medium for the communication between the participants: the domain experts and the IT specialists. But these models leave room for interpretation and hence ambiguities which makes them less suitable as a basis for the design of information systems. To remedy this we suggest to transform the EPCs into a formal representation (Petri nets) preserving the ambiguities, i.e. all possibly intended behaviour. Now formal techniques can be used to find out whether the possible behaviours comprise sensible behaviour. If so, we call the net relaxed sound. By not limiting the modeler compared to previous ways (e.g. [8], [3]) we take a pragmatic approach to correctness which only requires that the net represents some valid behaviour. This allows us to draw conclusions on mistakes in the original EPC and to make suggestions for its improvement thereby enhancing both the model’s quality and its suitability for software engineering.

1 Motivation

Business processes play a central role in the reorganization of a company and the (re)design of the respective information system(s). Typically the processes are described with the help of a semiformal, graphical language such as the Event-driven Process Chains (EPCs) by Scheer [15]. Approaches of this type are suitable for the analysis phase of an IT project where the focus is on communication: reaching an agreement on how the process should look like between participants with totally different backgrounds and “knowledge cultures”: CEOs, heads of department, department staff, IT experts and so on. In this phase it is imperative that the language used represents the greatest common denominator of the people involved. And more than that it should leave room for interpretation: the more ways there are to interpret a certain construct the more likely it is that an agreement is reached. The participants might not (yet) be ready to specify the “final” behaviour in detail and decide for the “correct” interpretation. But although this feature is desirable in the analysis phase of IS development it constitutes a major problem in the design phase where we need an ∗ This work is supported by Deutsche Forschungsgemeinschaft (reference WE 1214-3-3a,

research group Petri Net Technology)

K.R. Dittrich, A. Geppert, M.C. Norrie (Eds.): CAiSE 2001, LNCS 2068, pp. 157–170, 2001. © Springer-Verlag Berlin Heidelberg 2001

Relaxed Soundness of Business Processes

Juliane Dehnert1,∗ and Peter Rittgen2

1 Institute of Computer Information Systems, Technical University Berlin, Germany [email protected]

2 Institute of Business Informatics, University Koblenz-Landau, Germany [email protected]

Abstract. Business processes play a central role in the reorganization of a company and the (re)design of the respective information system(s). Typically the processes are described with the help of a semiformal, graphical language such as the Event-driven Process Chains (EPCs) by Scheer. This approach provides a suitable medium for the communication between the participants: the domain experts and the IT specialists. But these models leave room for interpretation and hence ambiguities which makes them less suitable as a basis for the design of information systems. To remedy this we suggest to transform the EPCs into a formal representation (Petri nets) preserving the ambiguities, i.e. all possibly intended behaviour. Now formal techniques can be used to find out whether the possible behaviours comprise sensible behaviour. If so, we call the net relaxed sound. By not limiting the modeler compared to previous ways (e.g. [8], [3]) we take a pragmatic approach to correctness which only requires that the net represents some valid behaviour. This allows us to draw conclusions on mistakes in the original EPC and to make suggestions for its improvement thereby enhancing both the model’s quality and its suitability for software engineering.

1 Motivation

Business processes play a central role in the reorganization of a company and the (re)design of the respective information system(s). Typically the processes are described with the help of a semiformal, graphical language such as the Event-driven Process Chains (EPCs) by Scheer [15]. Approaches of this type are suitable for the analysis phase of an IT project where the focus is on communication: reaching an agreement on how the process should look like between participants with totally different backgrounds and “knowledge cultures”: CEOs, heads of department, department staff, IT experts and so on. In this phase it is imperative that the language used represents the greatest common denominator of the people involved. And more than that it should leave room for interpretation: the more ways there are to interpret a certain construct the more likely it is that an agreement is reached. The participants might not (yet) be ready to specify the “final” behaviour in detail and decide for the “correct” interpretation. But although this feature is desirable in the analysis phase of IS development it constitutes a major problem in the design phase where we need an ∗ This work is supported by Deutsche Forschungsgemeinschaft (reference WE 1214-3-3a,

research group Petri Net Technology)

Step 1: straightforward element map

106

162 Juliane Dehnert and Peter Rittgen

Petri net are equivalent, because both accept the same executions. Note that the case that E is reached twice if F1 and F2 occur sequentially has not been excluded.

XOR

PNPN

>>

>>

XOR

EPC EPC

Fig. 2. Transformation rules for an EPC into a place/transition net (rule 1)

EE

F1 F2 F1 F2

ttta cb

>

EPC PN

Fig. 3. Transformation of the OR-Connector

To form a coherent Petri net the single modules are (automatically) connected as follows (rule 2): a) if input and output elements are different (place and transition) then the arcs are

fused

Step 2: element fusion

107

C

AA

B

C

B

tA tAB tB

A B

C

Mapping EPC elements

to PN!modules

Fusion of arcs

(Case2)

Unification of

elements

(Case1)

Step 1 Step 2

Modul combination

OR

Figure 4: Transformation of the OR-connector.

3.3.3. Step 3: Adding unique input/output places

Applying Step 1 and Step 2, an EPC is translated into a Petri net but not necessarilyinto a WF-net. If the EPC contained more than one start, and/or end event, theresulting net may have more than one start and/or sink place. There are no EPCsyntax-rules that restrict the number of start and end events. Moreover, if thereare several start events (or end events), it is not clear whether they are mutuallyexclusive or parallel. Therefore, a new start place and/or a new sink place is added.These new places are connected to the Petri net so that the places representing theprimary start events (or end events) of the EPC are initialized (cleaned up). Theconnection of the new places to the primary places is not trivial and depends onthe relation of the corresponding events in the EPC.

end

end2end1

end1 end2

end1 end2

OR

c)

end2end1end1 end2

end1 end2

AND

AND

Step3

Step1 &

Step2

b)

Step3

start1 start2

Step1 &

Step2

start1 start2

start1 start2

start

XOR

XOR

a)

Step3

Step1 &

Step2

Figure 5: Step 3: Adding new start and sink places.

One way to determine the relation would be to track the paths, starting from thedifferent start events (end events), until they joing. The connection of the new placegThe paths finally join. The EPC syntax rules state that: For every two elements there is a path

13

C

AA

B

C

B

tA tAB tB

A B

C


to PN!modules

Fusion of arcs

(Case2)

Unification of

elements

(Case1)

Step 1 Step 2

Modul combination

OR




end

end2end1

end1 end2

end1 end2

OR

c)

end2end1end1 end2

end1 end2

AND

AND

Step3

Step1 &

Step2

b)

Step3

start1 start2

Step1 &

Step2

start1 start2

start1 start2

start

XOR

XOR

a)

Step3

Step1 &

Step2



13

C

AA

B

C

B

tA tAB tB

A B

C


to PN!modules

Fusion of arcs

(Case2)

Unification of

elements

(Case1)

Step 1 Step 2

Modul combination

OR




end

end2end1

end1 end2

end1 end2

OR

c)

end2end1end1 end2

end1 end2

AND

AND

Step3

Step1 &

Step2

b)

Step3

start1 start2

Step1 &

Step2

start1 start2

start1 start2

start

XOR

XOR

a)

Step3

Step1 &

Step2



13

Step 3: add unique start / end

108

XOR start

OR end

(sometimes XOR/AND can be preferred)

Example

109

Sound?

Relaxed Soundness of Business Processes 159

marks the termination of it. For example, the event not_ok triggers the function complaint whereas the event data revised marks the termination of complaint. Furthermore, to describe more complex behaviour such as sequential, conditional, parallel, and iterative routing, connectors are introduced. These fall into two categories: splits and joins. In both we have AND, XOR and OR connectors.

>

>

complaint

not_okok

goods arrived

check goods

E16

C7

E11

C6

F8

C8

E15 E14

F10

F9

C12C11

E20

F13

E12

record receipt of

goods

XOR

XOR >

datarevised

goodsrecorded

store goods

stored

Fig. 1. Handling of incoming goods

Example

110



>

>

complaint

not_okok

goods arrived

check goods

E16

C7

E11

C6

F8

C8

E15 E14

F10

F9

C12C11

E20

F13

E12

record receipt of

goods

XOR

XOR >

datarevised

goodsrecorded

store goods

stored



amount of start and end events. A start (end) event is defined as an event without an incoming (outgoing) edge. Furthermore it is not clear whether the start (end) events are mutually exclusive. So translating the EPC into a Petri net does not necessarily lead to a Petri net with exactly one start and one sink place. In this case one further transformation step is required to yield a WF net. We add a new start place and a new sink place and connect them to Petri net-modules which initialize (clean up) the places representing the start and end events of the EPC in the right manner. The module introduced complements the first (last) connector on the paths from the start (end) events. For further particulars we refer the reader to [13] where this rule (rule 3) has been introduced and to the example below.

Applying the proposed rules 1 to 3, an EPC is transformed into a WF net. This transformation is unique, in the sense that to each EPC belongs exactly one WF net. An example for such a transformation is shown in Fig. 5. Here the EPC from Fig. 1 has been transformed into a WF net. For convenience we surrounded the Petri net-modules which correspond to the routing constructs of the EPC with dotted rectangles.

Transition t10_AND-Join and the sink place o have been added due to rule 3. Transition t10_AND-Join corresponds to an AND connector which complements the last connector on the paths from the end events E12 and E20, namely connector C12. Transition t10_AND-

Join bundles the different path and leads to the sink place o.

goods arrived

XOR

complaint

check goods

inot_ok

ok

>

AND-Split

XOR

XOR-Join

XOR-Join

OR-Join

OR-Join

OR-Join

o

>

>

revised

of goodsrecord receipt

>t1_

XOR-Splitt2_

t3_

AND-Split

t10_

t4_

t5_

t6_

t7_

t8_

t9_

AND-Join

store goods

stored

recordedgoods

data

XOR-Split

s1 s2

s6

s4

s3

s5

s7

Fig. 5. WF net “handling of incoming goods”

Let us have a closer look at the Petri net-module which replaces the OR join C7. The Petri net-module makes the behaviour of this routing construct explicit. Transition t5_OR-Join models the “straight away recording” and transition t6_OR-Join models the waiting for the revision to be completed. The alternative t7_OR-Join has been introduced as part of the corresponding Petri net-module, but has no expression in the original EPC. This alternative can not be chosen in the EPC, because of the AND-connector C6 before.

By transforming the OR connector we carry the ambiguity of the OR to the WF net. The decision whether to execute transition t5_OR-Join, t6_OR-Join or transition t7_OR-Join can not be resolved locally anymore.

Example

111

Not sound!



>

>

complaint

not_okok

goods arrived

check goods

E16

C7

E11

C6

F8

C8

E15 E14

F10

F9

C12C11

E20

F13

E12

record receipt of

goods

XOR

XOR >

datarevised

goodsrecorded

store goods

stored







goods arrived

XOR

complaint

check goods

inot_ok

ok

>

AND-Split

XOR

XOR-Join

XOR-Join

OR-Join

OR-Join

OR-Join

o

>

>

revised


>t1_

XOR-Splitt2_

t3_

AND-Split

t10_

t4_

t5_

t6_

t7_

t8_

t9_

AND-Join

store goods

stored

recordedgoods

data

XOR-Split

s1 s2

s6

s4

s3

s5

s7




Example

112

We can turn it to sound, but: changes in the net, can be hardly reflected in EPC






goods arrived

XOR

complaint

check goods

inot_ok

ok

>

AND-Split

XOR

XOR-Join

XOR-Join

OR-Join

OR-Join

OR-Join

o

>

>

revised


>t1_

XOR-Splitt2_

t3_

AND-Split

t10_

t4_

t5_

t6_

t7_

t8_

t9_

AND-Join

store goods

stored

recordedgoods

data

XOR-Split

s1 s2

s6

s4

s3

s5

s7




Relaxed soundness: formally

113

Definition: A WF net is relaxed sound if every transition belongs to a firing sequence

that starts in state i and ends in state o

(it is sound “enough”, in the sense that all transitions are covered by at least one sound execution)

⇤t ⇥ T. ⌅M,M ⇥. i �� Mt� M ⇥ �� o

Example

114

Relaxed sound?



>

>

complaint

not_okok

goods arrived

check goods

E16

C7

E11

C6

F8

C8

E15 E14

F10

F9

C12C11

E20

F13

E12

record receipt of

goods

XOR

XOR >

datarevised

goodsrecorded

store goods

stored







goods arrived

XOR

complaint

check goods

inot_ok

ok

>

AND-Split

XOR

XOR-Join

XOR-Join

OR-Join

OR-Join

OR-Join

o

>

>

revised


>t1_

XOR-Splitt2_

t3_

AND-Split

t10_

t4_

t5_

t6_

t7_

t8_

t9_

AND-Join

store goods

stored

recordedgoods

data

XOR-Split

s1 s2

s6

s4

s3

s5

s7




Example

115

Relaxed sound?



>

>

complaint

not_okok

goods arrived

check goods

E16

C7

E11

C6

F8

C8

E15 E14

F10

F9

C12C11

E20

F13

E12

record receipt of

goods

XOR

XOR >

datarevised

goodsrecorded

store goods

stored







goods arrived

XOR

complaint

check goods

inot_ok

ok

>

AND-Split

XOR

XOR-Join

XOR-Join

OR-Join

OR-Join

OR-Join

o

>

>

revised


>t1_

XOR-Splitt2_

t3_

AND-Split

t10_

t4_

t5_

t6_

t7_

t8_

t9_

AND-Join

store goods

stored

recordedgoods

data

XOR-Split

s1 s2

s6

s4

s3

s5

s7




Example

116

Relaxed sound?



>

>

complaint

not_okok

goods arrived

check goods

E16

C7

E11

C6

F8

C8

E15 E14

F10

F9

C12C11

E20

F13

E12

record receipt of

goods

XOR

XOR >

datarevised

goodsrecorded

store goods

stored







goods arrived

XOR

complaint

check goods

inot_ok

ok

>

AND-Split

XOR

XOR-Join

XOR-Join

OR-Join

OR-Join

OR-Join

o

>

>

revised


>t1_

XOR-Splitt2_

t3_

AND-Split

t10_

t4_

t5_

t6_

t7_

t8_

t9_

AND-Join

store goods

stored

recordedgoods

data

XOR-Split

s1 s2

s6

s4

s3

s5

s7




Example

117

Relaxed sound?



>

>

complaint

not_okok

goods arrived

check goods

E16

C7

E11

C6

F8

C8

E15 E14

F10

F9

C12C11

E20

F13

E12

record receipt of

goods

XOR

XOR >

datarevised

goodsrecorded

store goods

stored







goods arrived

XOR

complaint

check goods

inot_ok

ok

>

AND-Split

XOR

XOR-Join

XOR-Join

OR-Join

OR-Join

OR-Join

o

>

>

revised


>t1_

XOR-Splitt2_

t3_

AND-Split

t10_

t4_

t5_

t6_

t7_

t8_

t9_

AND-Join

store goods

stored

recordedgoods

data

XOR-Split

s1 s2

s6

s4

s3

s5

s7




Example

118

Not relaxed sound (as WF net)! But relaxed sound as EPC

(all nodes are covered by some sound execution)



>

>

complaint

not_okok

goods arrived

check goods

E16

C7

E11

C6

F8

C8

E15 E14

F10

F9

C12C11

E20

F13

E12

record receipt of

goods

XOR

XOR >

datarevised

goodsrecorded

store goods

stored







goods arrived

XOR

complaint

check goods

inot_ok

ok

>

AND-Split

XOR

XOR-Join

XOR-Join

OR-Join

OR-Join

OR-Join

o

>

>

revised


>t1_

XOR-Splitt2_

t3_

AND-Split

t10_

t4_

t5_

t6_

t7_

t8_

t9_

AND-Join

store goods

stored

recordedgoods

data

XOR-Split

s1 s2

s6

s4

s3

s5

s7




Pros and Cons

119

If the WF net is not relaxed sound: there are transitions that are not part of a

sound firing sequence

Hence their EPC counterparts need improvements

Relaxed soundness can be proven only by enumeration (of enough sound firing sequences)

No equivalent characterization is known that is more convenient to check

Open research problem…

Business Processes Modelling MPB (6 cfu, 295AA)didawiki.di.unipi.it/.../mpb/21-epc-2018.pdf · Event-driven Process Chain 3 An Event-driven Process Chain (EPC) is a particular type

Documents