CAiSE 2015 - Montali - Declarative Process Modeling in BPMN

Declarative Process Modeling in BPMN

Marco Montali Free University of Bozen-Bolzano

joint work with Giuseppe De Giacomo, Fabrizio M. Maggi, Marlon Dumas

CAiSE’151

Disclaimer for this Talk

Process = Control-flow

2

Trends in BPM

modeling

• Highly-variable BPs

• Metaphor: rules/constraints

Dec t ilara ev

Imperative modeling • Traditional repetitive BPs

• Metaphor: flow-chart

3

Imperative Modeling4

Imperative Modeling

Focus: how things must be done

• Explicit description of the process control-flow

Closed modeling

• All that is not explicitly modeled is forbidden

• Exceptions all to be considered at design time

5

BPMN

Receiveorder

Check availability

Article available?

Ship articleFinancial

settlementyes

Procurement

no Paymentreceived

Inform customer

Late deliveryUndeliverable

Customerinformed

Inform customer

Articleremoved

Remove article from catalogue

6

BPMN

Receiveorder

Check availability

Article available?


settlementyes

Procurement

no Paymentreceived

Inform customer


Customerinformed

Inform customer

Articleremoved


Input Output

7

BPMN

Receiveorder

Check availability

Article available?


settlementyes

Procurement

no Paymentreceived

Inform customer


Customerinformed

Inform customer

Articleremoved


Input Output

8

Constraint-Based Modeling9

Constraint-Based Modeling

Focus: what has to be accomplished

• Explicit description of the relevant business constraints • behavioral constraints, best practices, norms, rules, …

Open modeling

• All behaviors are possible provided that they respect the constraints

• Control-flow left implicit

10

Declare

Finalize order

Confirmorder

Rejectorder

Ship

Notify shipment issue

11

Declare12

Declare13

Declare14

Pros and Cons (for dummies)

Flexibility Control

Imperative modeling - +Declarative modeling + -

15

Ultimate Goal:Trade-off between Flexibility and Control

16

Towards a Suitable Trade-OffIn the literature: many hybrid notations • Mix declarative and imperative constructs • Lasagne integration vs spaghetti integration

This suggests that new notations are needed. Bad impact on understandability.

Do we really need completely new notations? Our answer: NO!

17

Our ApproachTranslate Declare into a notation that

• mediates between flexibility and control • is a conservative extension to well-known

imperative modeling languages (BPMN)

• Looks familiar • Can be converted back into standard BPMN

But… why not plain BPMN???

18

Process Responsibilities• History recognition: given the history of a running

instance, compute the current state (or reject)

• Todo list: given the current state, tell which tasks can be executed next (including possibility of termination)

• Update: given a state and a task, determine the new state

S

AB

C

S

SnewS

19

Declare as a Process?Automata to the Rescue!

20

Declare and Temporal Logics

• Observation: Declare constraints are formalized using LTL over finite traces (LTLf) • A Declare model is simply a big LTLf formula

• LTLf corresponds to the star-free fragment of regular expressions

• Intimate connection with finite-state automata

21

Declare 2 DFA

…

…

…

'

LTLf NFAnondeterministic

DFAdeterministic

LTLf2aut determin.

22

From Declare to DFA

…

…

…

'


DFAdeterministic

LTLf2aut determin.

A process!• allowed tasks: alphabet, task: symbol, trace: word • history recognition —> word prefix recognition • todo list —> return next symbols • update —> transition

23

Example

Table 1: Semantics for some Declare templatesTemplate LTLf semantics Activation

A Bresponded existence ⌃A ! ⌃B

A Bresponse ⇤(A ! ⌃B)

A Balternate response ⇤(A ! �(¬A t B))

A Bchain response ⇤(A ! �B)

A Bprecedence (¬B t A) _ ⇤(¬B)

alternate precedence BA(¬B t A) _ ⇤(¬B)^

⇤(B ! �((¬B t A) _ ⇤(¬B)))

A Bchain precedence ⇤(�B ! A)

for traces such as t1 = ha, a, b, ci, t2 = hb, b, c, di, and t3 = ha, b, c, bi, but not fort4 = ha, b, a, ci because, in this case, the second occurrence of a is not followed byan occurrence of b. A constraint can define more than one activity for each parameterspecified in its template. In this case, we say that the parameters branch out and, in thegraphical representation, they are replaced by multiple arcs to all branched activities.In the LTLf semantics, the parameters are replaced by a disjunction of branching activ-ities. For example, the LTLf semantics of the response template with two branches onthe target parameter is ⇤(A ! ⌃(B _ C)).

Example 1. Consider the Declare model that represents a fragment of a purchase orderprocess, as shown in Figure 1. The process is as follows:

– a payment cannot be done until the order is closed (precedence constraint);– whenever a payment is done, then a receipt or an invoice must be produced (branch-

ing response constraint).

close order pay

receipt

invoice

Fig. 1: Example of a Declare model

Like any declarative model, this model should be interpreted according to an “open-world” semantics: It is possible to send a receipt or an invoice without paying before-hand and, also, to close an order without eventually paying. In addition, an activity inthe model can be executed several times. Closing an order several times has no effecton the process execution, whereas it is possible to pay several times (this is the case, forexample, of installments) and, also, to send invoices and receipts several times.

0 1close order 2pay

receipt

invoice

receipt

invoice

close orderreceipt

invoice

close order

pay

24

Problem Solved (?)Convert Declare model into a DFA. The DFA: • accepts all and only the traces accepted by

the Declare model • can be easily converted into workflow nets,

BPMN, … • is apt to be post-processed

• E.g., theory of region to discover concurrent parts (cf. [Prescher et al., SIMPDA 2014])

25

Can you Digest Spaghetti? Or: the Issue of Understandability

26

Declare 2 DFA: Complexity

'


DFAdeterministic

LTLf2aut determin.

exponentialblow-up

exponentialblow-up

N.B.: this complexity is unavoidable (and is not just related to concurrency)

27

From [Prescher et al., SIMPDA 2014]

(a) Declare model (b) Finite State Automaton derived from the Declare model

Fig. 7: The process mined out of BPIC 2013 log [33], as Declare model and FSA

4.1 Implementation

In order to have the opportunity to analyze real-life declarative process models, wehave integrated our approach with a tool for the mining of declarative control flowsfrom event logs (see Figure 5), namely MINERful [15]. The MINERful frameworkcomes with an integrated support of a library called dk.bricks.automaton [28], for thegeneration of FSAs out of Regular Expressions. We extended the integrated MINERful-dk.bricks.automaton tool in order to make it capable of serializing FSAs into TSML-encoded files. TSML (Transition System Markup Language) is indeed a format sup-ported by ProM, the Process Mining Toolkit [3]. In this way, we have been able to ap-ply the ProM plug-in by van Dongen (see [5]), capable of converting a TSML-encodedTransition System into a Petri net, by using Petrify (see [10]).

4.2 Application to the BPI Challenge 2013

As a real-world data set for validating the approach, we selected the “BPI Challenge2013, closed problems” log [33] as an application case. For the control-flow dis-covery task, we have considered the activities’ names as their identifiers (Accepted,Completed, Queued and Unmatched). We have set MINERful up in order to returnthose constraints proven to be valid in every trace (support threshold equal to 1). Thediscovered model consisted of the following 10 constraints:

Response(Queued,Accepted)NotChainSuccession(Queued,Completed)Response(Queued,Completed)NotChainSuccession(Queued,Unmatched)Response(Accepted,Completed)

End(Completed)NotSuccession(Completed,Unmatched)AtMostOne(Unmatched)RespondedExistence(Unmatched,Accepted)AlternateResponse(Unmatched,Completed)

The graphical representation of the model is depicted in Figure 7a. Figure 7b drawsthe Finite State Automaton derived from the Declare model, and Figure 8 shows thefinal outcome, as a Petri net. What we can observe from the comparison of the Declaremodel and the behavior-equivalent Petri net is the multiplication of various activities.

28




4.1 Implementation







(a) Declare model

Completed

Accepted

Unmatched

Queued

Completed Queued

Accepted

Accepted

Completed

Accepted

Queued

Completed

AcceptedCompleted

Accepted

Completed

Accepted

Queued

CompletedAccepted

AcceptedQueued

Completed

AcceptedCompleted

Queued

AcceptedQueued

Completed

Completed

Queued

Accepted

(b) Finite State Automaton derived from the Declare model


4.1 Implementation







29




4.1 Implementation







(a) Declare model

Completed

Accepted

Unmatched

Queued

Completed Queued

Accepted

Accepted

Completed

Accepted

Queued

Completed

AcceptedCompleted

Accepted

Completed

Accepted

Queued

CompletedAccepted

AcceptedQueued

Completed

AcceptedCompleted

Queued

AcceptedQueued

Completed

Completed

Queued

Accepted

(b) Finite State Automaton derived from the Declare model


4.1 Implementation







q

q

q q

q q

qq

c

c

c

c

c

c

c

c

c

c

a

a

a

a

aa

a

a

a

a

au

Fig. 8: The Petri net derived from the Finite State Automaton representing the De-clare model mined out of BPIC 2013 log [33]. Labels are abbreviated: a = “Accepted”,c = “Completed”, u = “Unmatched”, q = “Queued”.

Although the Declare model seems to be more compact in terms of its nodes and edges,it must be noted that the Petri net is presented as it was produced, i.e., it has not beensubject to any post-processing for reducing its complexity. However, the defined chainof transformations provide us with the basis to study the trade-off between compactnessof the model and richness of the language in future experiments, conducted on behavior-equivalent Petri nets and Declare models.

5 Related work

The stream of research on the comparison of declarative and imperative modeling ap-proaches has been discussed considering different perspectives. In [32], Pichler et al.investigate both imperative and declarative languages with respect to process modelunderstanding. The issue of maintainability for both languages is discussed in [20]. Anopen problem for this experimental stream of research has been the question of whata fair comparison is for declarative and imperative models. In this regard, the work of[35] and [36] elaborates on mixed representations as a combination of both approachesfrom a modeling perspective.

Furthermore, research on automatic process discovery techniques has been definedbased on different representations and different techniques of discovery beyond theclassical alpha miner [2]. Our selection is not meant to be exhaustive, but rather high-lights those approaches that use constraints, automata or transition systems. Van derAalst et al. propose a two-step approach in [5] in order to discover transition systemswhich are then synthesized to Petri nets using the “theory of regions”. As well as Vander Aalst et al., Maruster et al. suggested an approach for process discovery in whichthey deal with noise and imbalance in process logs ([23]). A tool manipulating concur-rent specifications, synthesis and optimization of asynchronous controllers is presentedin [10]. In order to come up with a better understanding of the mutual strengths andweaknesses of these approaches, De Weerdt et al. ([34]) provide an extensive, multi-dimensional survey of existing process discovery algorithms using real-life event logs.Different representations are, however, not discussed in this survey. In this way, ourwork provides a basis for an extensive comparison in the future.

30

Our SolutionBPMN-D: a declarative view on top of BPMN

BPMN-DBPMN

Declare

31

BPMN-DCore BPMN constructs

• None start/end events • Atomic tasks • XOR gateways • Sequence flows

Extended, “declarative” constructs • Extended tasks • Extended flow connectors

32

BPMN-D Tasks

Notation Name Semantics

t Atomic task As in BPMN: perform t

IN{t1,…,tn} Inclusive task Perform a task among t1, . . . , tn

EX{t1,…,tn} Exclusive task Perform a task different from t1, . . . , tn

ANY Any task Perform any task from those available in the business context

Table 2: Overview of BPMN-D activity nodes

A flow connector is a binary, directed relation between nodes in the process. It indi-cates an ordering relationship between the connected nodes, and implicitly also the stateof the process when the process has traversed the source node but has still to traversethe destination node. Differently from BPMN, in BPMN-D sequence-flow connectorsdo not only represent a direct ordering relationship (stating that the destination nodecomes next to the source one), but also a “loose” ordering relationship, which indicatesthat the destination node will be traversed after the source one, but that other BPMN-Dtasks can be performed in between. First of all, BPMN-D supports the ordinary BPMNsequence flow, adopting its semantics and notation (a solid arrow from the source to thedestination node). Loose flow connectors are instead visually depicted as an interruptedsolid arrow, and their specific semantics is defined by labeling and annotating the con-nector with additional information, similarly to the case of BPMN-D activity nodes.As summarized in Table 3, three loose connectors are supported. The first two, namelyinclusive flow and exclusive flow, label the flow connectors with a set of T of tasks,and indicate that while moving from the source to the destination node along the flowconnector, 0 or more repetitions of tasks respectively from or not in T can be executed.To distinguish between the two cases, the set T is also annotated with a property IN orEX, so as to indicate whether the flow connector is inclusive or exclusive. For example,in Fig. 2, the first flow connector indicates that when the process starts, 0 or more repe-titions of tasks receipt and invoice may occur while moving to the first decision point.In addition, we consider also the case in which while moving from a node to anothernode, 0 or more repeatitions of any task may occur. In this case, we assume that theflow connector is just labeled with label ANY, and we consequently call it any flow.

3.2 BPMN-D Models

We now turn to the formal definition of BPMN-D model, substantiating the overviewof the previous section. Given a set ⌃ of tasks, a BPMN-D model M is a tuplehN, typeN , `N , F, typeF , `F i, where:

– N is a finite set of nodes, partitioned into activity nodes, event nodes, and gateways.– typeN is a total function from N to a finite set of node types; the following types

are considered in this paper:• ATOMIC-TASK, IN-TASK, EX-TASK, and ANY-TASK for activity nodes (cf. Ta-

ble 2);

33

BPMN-D Flow Connectors

Notation Name Semantics

A B Sequence flow As in BPMN: node B is traversed next to A

IN {t1,…,tn}A B Inclusive flow B is traversed after A, with 0 or more repetitions of tasks

from t1, . . . , tn in between

EX {t1,…,tn}A B Exclusive flow B is traversed after A, with 0 or more repetitions of tasks

different from t1, . . . , tn in between

ANYA B Any flow B is traversed after A, with 0 or more repetitions of tasks in

between

Table 3: Overview of BPMN-D flow connectors

• START and END for event nodes;• XOR-SPLIT and XOR-JOIN for gateways.

We consequently define:• the set A of activity nodes as

{n | n 2 N and typeN (n) 2 {ATOMIC-TASK, IN-TASK, EX-TASK, ANY-TASK}};• the set E of event nodes as {n | n 2 N and typeN (n) 2 {START, END}};• the set G of gateways as {n | n 2 N and typeN (n) 2 {XOR-SPLIT, XOR-JOIN}};

Notice that N = A ] E ]G.– `N : A �! 2⌃ is a function that assigns task names to activity nodes in N . To

guarantee that each activity node is mapped to a set of tasks consistently with itsspecific type, `N must satisfy the following conditions:• for every a 2 A such that typeN (a) = ATOMIC-TASK, |`N (a)| = 1;• for every a 2 A such that typeN (a) 2 {IN-TASK, EX-TASK}, ; ⇢ `N (a) ⇢ ⌃;• for every a 2 A such that typeN (a) = ANY-TASK, `N (a) = ;.

– F ✓ N ⇥ N is a set of flow connectors that obeys to the following restrictions:(i) every start event node has no incoming sequence flow, and a single outgoingsequence flow; (ii) every end event node has a single incoming sequence flow, andno outgoing sequence flow; (iii) every activity node has a single incoming and asingle outgoing sequence flow; (iv) every XOR split gateway has a single incomingand at least two outgoing sequence flows; (v) every XOR join gateway has a singleoutgoing and at least two incoming sequence flows.4

– typeF is a total function from F to the finite set of flow connector types{SEQ-FLOW, IN-FLOW, EX-FLOW, ANY-FLOW} (cf. Table 3).

– `F : F �! 2⌃ is a function that assigns task names to flow connectors in F . Toguarantee that each flow connector is mapped to a set of tasks consistently with itsspecific type, `F must satisfy the following conditions:• for every f 2 F such that typeF (f) 2 {SEQ-FLOW, ANY-TASK}, `F (f) = ;;• for every f 2 F such that typeF (f) 2 {IN-TASK, EX-TASK}, ; ⇢ `F (f) ⇢ ⌃.

4 Graphically, we sometimes collapse a XOR join, connected to a XOR split via a standardBPMN sequence flow, into a single XOR gateway acting simultaneously as split/join.

34

Example

3.1 Overview

BPMN-D is an extension of BPMN partly inspired by BPMN-Q [2] – a language pre-viously proposed to capture queries over collections of BPMN models. Like BPMN-Q,BPMN-D is a conservative (additive) extension of BPMN, implying that any BPMNmodel is also a BPMN-D model. Fig. 2 shows an example of a BPMN-D model. Inparticular, a BPMN-D model may have start and end event nodes, with the same se-mantics as in standard BPMN. For instance, in Fig. 2, there is one start event and twoend events. Similarly, behavioral XOR split/join represents (exclusive) alternative be-haviors that are allowed during the process execution, following the standard BPMNsemantics of deferred choice (i.e., choice freely taken by the resources responsible forthe process execution). As shown in Fig. 2, the graphical representation for a XOR gate-way is the same as in BPMN. In this paper, we only discuss XOR gateways as they aresufficient to demonstrate the extensions proposed in BPMN-D and the translation fromDeclare to BPMN-D. In the remainder of the paper, we denote by ⌃ the set of all tasksthat can be performed in a given business context.

X close order

IN {receipt, invoice}X pay

EX {pay}

IN{receipt,invoice}

IN {pay, close order}X

Fig. 2: Example of a BPMN-D model

BPMN-D extends only two constructs in BPMN, namely activity nodes and se-quence flows connectors. An activity node represents a task in the process, and is repre-sented as a labeled, rounded rectangle. As in standard BPMN, this in turn correspondsto an execution step inside the process. Differently from BPMN, though, a BPMN-Dactivity node can be labeled not only with a single task name t 2 ⌃, but with a set Tof multiple tasks, such that T is nonempty and does not coincide with ⌃. When thelabel denotes a single task t, the semantics coincides with that of BPMN: the activitynode is executed whenever t is performed. When the label is instead a set T of tasks,the activity node is considered to be executed whenever a task t is executed, such thateither t 2 T (inclusive task), or t /2 T (exclusive task). To distinguish between thesetwo cases, a set-labeled BPMN-D task is also annotated with a property IN or EX, so asto indicate whether the task is inclusive or exclusive. For example, in Fig. 2, the pay-labeled activity node indicates that a payment must be done, whereas the set-labeledactivity node IN({receipt , invoice}) indicates that one task between receipt or invoicemust be performed. In addition to these three types of activity nodes, we consider alsothe case in which the process expects participants to do “something”, that is, to engagein an execution step by freely choosing a task from the global set ⌃. In this case, weassume that the activity node is just labeled with label ANY. The different BPMN-Dactivity nodes are summarized in Table 2.

35

From BPMN-D to BPMN• BPMN-D is just a “view” on top of (a fragment of) BPMN

• Once the set of available tasks is known… • EX constructs can be converted into IN constructs via set-difference • IN constructs can be modularly turned into standard BPMN

BPMN-D Translation into BPMN

IN {t1,…,tn}

A B A B

t1

tn

X X…

IN {t1,…,tn}A B

A B

t1

tnX X…

X X

Table 4: Translation of the key BPMN-D elements into standard BPMN

3.3 Translating BPMN-D to Standard BPMN

Any BPMN-D diagram can be faithfully represented as a (trace-equivalent) correspond-ing standard BPMN diagram, at the price of conciseness. In this section, we discuss thistranslation, which has a twofold purpose: (i) it shows that, in principle, a BPMN-D pro-cess can be enacted on top of a standard BPMN engine; (ii) it provides an implicitexecution semantics for BPMN-D in terms of standard BPMN.

For the translation, we assume that the overall set of tasks ⌃ is fixed. In this respect,it is sufficient to discuss how elements annotated with IN or ANY have to be translated:each label of the kind EX(T ) can be in fact equivalently re-expressed as IN(⌃ \ T ). Asshown in Table 4 (top row), an inclusive task with label {t1, . . . , tn} is translated intoa deferred choice where one of the tasks t1, . . . , tn is selected. An ANY-labeled taskis translated in the same way, considering all tasks in ⌃ as possible alternatives. Thetranslation of an inclusive path sequence flow with label {t1, . . . , tn} is also depictedin Table 4 (bottom row). In this case, two alternative behaviors are obtained: eitherthe inclusive path sequence flow behaves as a normal sequence flow (thereby directlyconnecting node A to node B), or it allows the executors to repeatedly execute taskst1, . . . , tn in between. As for tasks, also the case of a ANY-labeled sequence flow ishandled in the same way, just considering all tasks in ⌃ as possible alternatives. Figure 3shows the result obtained by applying this translation procedure to the BPMN-D modelshown in Figure 2.

4 From Declare to BPMN-D

We now propose a translation mechanism that, given a declarative, constraint-basedprocess model, produces a corresponding readable BPMN-D diagram that faithfullyrepresents the original intended behaviors. As source language, we consider LinearTemporal Logic on finite traces (LTLf ), which is the logic underpinning the Declarenotation. However, it is worth noting that our approach can be directly applied to themore expressive logic LDLf [5], which has been recently adopted to formalize andmonitor Declare constraints and meta-constraints [4].

36

Modular Unfolding

X close order XX

pay

IN {receipt, invoice} EX {pay}

IN{receipt,invoice}

IN {pay, close order}

BPMN-D

37

Modular Unfolding

X close orderX XX

receipt

invoice XX XX

receipt

invoice

close order

XX

pay

close order pay

receipt

invoice

XX X X

Fig. 3: Standard BPMN representation of the BPMN-D diagram of Figure 2

The algorithm proceeds in two phases. In the first phase, the given Declare (orLTLf /LDLf ) specification is translated into a corresponding finite-state automaton thatemploys a form of declarative labels, and can therefore represent the given specifica-tion more compactly than for standard finite-state automata. In the second phase, thisso-called “constraint automaton” is translated into a corresponding BPMN-D model.Both steps are such that the produced model accepts exactly the same traces as theinput model, in turn guaranteeing that the BPMN-D model is a faithful, equivalent rep-resentation of the input Declare model.

In the remainder of this section, we provide a detailed account of these two phases.

4.1 From Declare to Constraint Automata

It is well-known that a Declare model can be transformed into a corresponding finite-state automaton that accepts exactly those traces that satisfy all the constraints presentin the model [20, 4, 16]. A finite-state automaton (FSA) is a tuple h⌃, S, I, F, �i, where:(i) ⌃ is the alphabet of symbols; (ii) S is a finite set of states; (iii) I ✓ S is the set ofinitial states; (iv) F ✓ S is the set of final states; (v) � : S ⇥⌃ ! 2S is the state tran-sition function, which maps each state and symbol to a set of successor states. Hereby,we assume that symbols represent atomic tasks, and consequently that the symbol al-phabet is constituted by all atomic tasks that can be executed in the targeted domain.The language of an FSA A, written L(A), is the set of finite traces (i.e., words) over ⌃that are accepted by A. The notions of deterministic finite-state automaton (DFA) andof minimal automaton are as usual.

Once the Declare model is translated into its corresponding FSA, the FSA can bedeterminized and minimized using standard techniques. This minimal DFA can be usedto enact the Declare model [14]: at any time, the DFA states whether the process can beterminated or not, and indicates which tasks that can/must be executed next.

A drawback of this automata-based representation is that every transition of the au-tomaton is labeled with a single, atomic task. This means that the same pair of statescan be connected through several transitions, each associated to a different task. All

BPMN

38

From Declare to BPMN-D

…

…

…

X

close order XX

pay

IN {r, i}

EX {p}

IN{r,i}

IN {p,c}

Declaremodel

Constraint Automaton

BPMN-Dmodel

Declare 2 CA CA 2 BPMN-D

Correct: accepts all and only the traces accepted by

the input Declare modelA DFA with

constraints as labels

39

Constraint Automaton• A DFA can have multiple edges between same 2 states

• They represent the same state change!

• Constraint automaton combines them into a single “constraint transition” that resembles BPMN-D

• “t” —> normal transition • IN T —> move with a symbol in the set T • EX T —> move with a symbol not in the set T • ANY —> move with any symbol

• Procedure: Declare to DFA, then “compact” the DFA into a constraint automaton

S1 S2

a

b

ab

c

S1 S2

IN {a,b}

EX {d}

TASKS: {a,b,c,d}

40

d

d

Example








⇤(B ! �((¬B t A) _ ⇤(¬B)))






close order pay

receipt

invoice



0 1close order 2pay

receipt

invoice

receipt

invoice

close orderreceipt

invoice

close order

pay

41

Example








⇤(B ! �((¬B t A) _ ⇤(¬B)))






close order pay

receipt

invoice



0

IN {receipt, invoice}

1close order 2

EX {pay}

pay



42

From CA to BPMN-DLinear translation, in 3 steps:

1.Iterate through states, generating process blocks

2.Interconnect blocks through tasks obtained from transitions

3.Remove unnecessary gateways that have only one input and one output

43

From CA to BPMN-D: States

1. State: introduces XOR split/join logic

2. Initial state: single start event of the process

3. Final state: choice of termination

S X X

start XS0 X

Sf X X

44

From CA to BPMN-D: Transitions4. Self-loop: no effective state change; executable 0..* times

5. Proper transition: state transformation through task execution

X X

label

Slabel

S1 S2label X … X X…labelX

45

Example0


1close order 2

EX {pay}

pay



46

Example

X

0


1close order 2

EX {pay}

pay



XIN {receipt, invoice}

XEX {pay}


X X XX X X

47

Example

X

0


1close order 2

EX {pay}

pay



X close order


X payEX {pay}

IN{receipt,invoice}


X X XX X X

48

Example

X

0


1close order 2

EX {pay}

pay



X close order


X payEX {pay}

IN{receipt,invoice}


X X XX X X

49

Example0


1close order 2

EX {pay}

pay



X close order


X payEX {pay}

IN{receipt,invoice}


XX

50

Conclusion• BPMN-D: conservative, “minor” extension of BPMN

with declarative constructs • Can be encoded back into standard BPMN

• Translation mechanism from Declare to BPMN-D • Tackles directly all regular expressions / LDLf

• Lessons learnt: • We don’t need completely new notations • We cannot apply standard techniques off-the-shelf

51

Ongoing/Future Work• Include parallel gateways and exceptions

• Exception handling derived from “compensation constraints” [De Giacomo et al., BPM 2014]

• Tooling and benchmarking with case studies • Synthesis of “just sound” BPMN-D processes

• Compliant by-design, but not necessarily accepting all the original intended behaviors

• “Tuning knob” for trade-off between understandability and coverage of behaviors

52

CAiSE 2015 - Montali - Declarative Process Modeling in BPMN

Presentations & Public Speaking

Transcript of CAiSE 2015 - Montali - Declarative Process Modeling in BPMN