Presentation of the paper "Declarative Process Modeling in BPMN" at the 27th International Conference on Advanced Information Systems Engineering (CAiSE 2015).

1. 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

2. Disclaimer for this Talk
Process = Control-flow
2

3. Trends in BPM
modeling
• Highly-variable BPs
• Metaphor: rules/constraints
Dec t i
lar
a
ev
Imperative modeling
• Traditional repetitive BPs
• Metaphor: flow-chart
3

4. Imperative Modeling
4

5. Imperative Modeling
Focus: howthings must be done
• Explicit description of the process control-flow
Closedmodeling
• All that is not explicitly modeled is forbidden
• Exceptions all to be considered at design time
5

6. BPMN
Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
received
Inform
customer
Late deliveryUndeliverable
Customer
informed
Inform
customer
Article
removed
Remove
article from
catalogue
6

7. BPMN
Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
received
Inform
customer
Late deliveryUndeliverable
Customer
informed
Inform
customer
Article
removed
Remove
article from
catalogue
Input Output
7

8. BPMN
Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
received
Inform
customer
Late deliveryUndeliverable
Customer
informed
Inform
customer
Article
removed
Remove
article from
catalogue
Input Output
8

9. Constraint-Based Modeling
9

10. Constraint-Based Modeling
Focus: whathas to be accomplished
• Explicit description of the relevant business constraints
• behavioral constraints, best practices, norms, rules, …
Openmodeling
• All behaviors are possible provided that they respect the
constraints
• Control-flow left implicit
10

11. Declare
Finalize order
Confirm
order
Reject
order
Ship
Notify
shipment issue
11

12. Declare
12

13. Declare
13

14. Declare
14

15. Pros and Cons (for dummies)
Flexibility Control
Imperative
modeling - +
Declarative
modeling + -
15

16. Ultimate Goal:
Trade-off between Flexibility and Control
16

17. Towards a Suitable Trade-Off
In 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

18. Our Approach
Translate 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

19. 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
A
B
C
S
SnewS
19

20. Declare as a Process?
Automata to the Rescue!
20

21. 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

22. Declare 2 DFA
…
…
…
'
LTLf NFA
nondeterministic
DFA
deterministic
LTLf2aut determin.
22

23. From Declare to DFA
…
…
…
'
LTLf NFA
nondeterministic
DFA
deterministic
LTLf2aut determin.
A process!
• allowed tasks: alphabet, task: symbol, trace: word
• history recognition —> word prefix recognition
• todo list —> return next symbols
• update —> transition
23

24. Example
onse constraint).
close
order
pay
receipt
invoice
Fig. 1: Example of a Declare model
clarative model, this model should be interpreted according
antics: It is possible to send a receipt or an invoice without p
so, to close an order without eventually paying. In addition,
an be executed several times. Closing an order several times
ss execution, whereas it is possible to pay several times (this i
0 1
close order
2
pay
receipt
invoice
receipt
invoice
close order
receipt
invoice
close order
pay
24

25. 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

26. Can you Digest Spaghetti?
Or: the Issue of Understandability
26

27. Declare 2 DFA: Complexity
'
LTLf NFA
nondeterministic
DFA
deterministic
LTLf2aut determin.
exponential
blow-up
exponential
blow-up
N.B.: this complexity is unavoidable
(and is not just related to concurrency)
27

28. From [Prescher et al., SIMPDA 2014]
(a) Declare model (b) Finite State Automaton
Fig. 7: The process mined out of BPIC 2013 log [33],
4.1 Implementation
In order to have the opportunity to analyze real-life de
28

29. From [Prescher et al., SIMPDA 2014]
(a) Declare model (b) Finite State Automaton
Fig. 7: The process mined out of BPIC 2013 log [33],
4.1 Implementation
In order to have the opportunity to analyze real-life de
re model
Completed
Accepted
Unmatched
Queued
Completed Queued
Accepted
Accepted
Completed
Accepted
Queued
Completed
Accepted
Completed
Accepted
Completed
Accepted
Queued
CompletedAccepted
AcceptedQueued
Completed
Accepted
Completed
Queued
Accepted
Queued
Completed
Completed
Queued
Accepted
(b) Finite State Automaton derived from the Declare model
process mined out of BPIC 2013 log [33], as Declare model and FSA
29

30. From [Prescher et al., SIMPDA 2014]
(a) Declare model (b) Finite State Automaton
Fig. 7: The process mined out of BPIC 2013 log [33],
4.1 Implementation
In order to have the opportunity to analyze real-life de
re model
Completed
Accepted
Unmatched
Queued
Completed Queued
Accepted
Accepted
Completed
Accepted
Queued
Completed
Accepted
Completed
Accepted
Completed
Accepted
Queued
CompletedAccepted
AcceptedQueued
Completed
Accepted
Completed
Queued
Accepted
Queued
Completed
Completed
Queued
Accepted
(b) Finite State Automaton derived from the Declare model
process mined out of BPIC 2013 log [33], as Declare model and FSA
q
q
q q
q q
q
q
c
c
c
c
c
c
c
c
c
c
a
a
a
a
a
a
a
a
a
a
a
u
30

31. Our Solution
BPMN-D: a declarative view on top of BPMN
BPMN-D
BPMN
Declare
31

32. BPMN-D
Core BPMN constructs
• None start/end events
• Atomic tasks
• XOR gateways
• Sequence flows
Extended, “declarative” constructs
• Extended tasks
• Extended flow connectors
32

33. 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 state
33

34. 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
ANY
A 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
34

35. Example
haviors that are allowed during the process execution, following the standard BPMN
semantics of deferred choice (i.e., choice freely taken by the resources responsible for
the 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 are
sufficient to demonstrate the extensions proposed in BPMN-D and the translation from
Declare to BPMN-D. In the remainder of the paper, we denote by ⌃ the set of all tasks
that 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 corresponds
to an execution step inside the process. Differently from BPMN, though, a BPMN-D
35

36. 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
36

37. Modular Unfolding
X
close
order XX
pay
IN {receipt, invoice} EX {pay}
IN
{receipt,invoice}
IN {pay, close order}
BPMN-D
37

38. 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
BPMN
38

39. From Declare to BPMN-D
…
…
…
X
close
order XX
pay
IN {r, i}
EX {p}
IN
{r,i}
IN {p,c}
Declare
model
Constraint
Automaton
BPMN-D
model
Declare 2 CA CA 2 BPMN-D
Correct: accepts all and
only the traces accepted by
the input Declare model
A DFA with
constraints as labels
39

40. 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
a
b
c
S1 S2
IN {a,b}
EX {d}
TASKS: {a,b,c,d}
40
d
d

41. Example
ever a payment is done, then a receipt or an invoice must be produce
esponse constraint).
close
order
pay
receipt
invoice
Fig. 1: Example of a Declare model
declarative model, this model should be interpreted according to
mantics: It is possible to send a receipt or an invoice without payi
also, to close an order without eventually paying. In addition, an
l can be executed several times. Closing an order several times ha
ocess execution, whereas it is possible to pay several times (this is th
of installments) and, also, to send invoices and receipts several tim
0 1
close order
2
pay
receipt
invoice
receipt
invoice
close order
receipt
invoice
close order
pay
41

42. Example
ever a payment is done, then a receipt or an invoice must be produce
esponse constraint).
close
order
pay
receipt
invoice
Fig. 1: Example of a Declare model
declarative model, this model should be interpreted according to
mantics: It is possible to send a receipt or an invoice without payi
also, to close an order without eventually paying. In addition, an
l can be executed several times. Closing an order several times ha
ocess execution, whereas it is possible to pay several times (this is th
of installments) and, also, to send invoices and receipts several tim
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
42

43. From CA to BPMN-D
Linear 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

44. 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

45. From CA to BPMN-D: Transitions
4. Self-loop: no effective state change; executable 0..* times
5. Proper transition: state transformation through task execution
X X
label
S
label
S1 S2
label X …
X X…labelX
45

46. Example
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
46

47. Example
X
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
X
IN {receipt, invoice}
X
EX {pay}
IN {pay, close order}
X X XX X X
47

48. Example
X
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
X
close
order
IN {receipt, invoice}
X pay
EX {pay}
IN
{receipt,invoice}
IN {pay, close order}
X X XX X X
48

49. Example
X
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
X
close
order
IN {receipt, invoice}
X pay
EX {pay}
IN
{receipt,invoice}
IN {pay, close order}
X X XX X X
49

50. Example
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
X
close
order
IN {receipt, invoice}
X pay
EX {pay}
IN
{receipt,invoice}
IN {pay, close order}
XX
50

51. 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

52. 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