Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Declarative Process
Modeling in BPMN
Marco Montali
Free University of Bozen-Bolzano
joint work with Giuseppe De Giacomo, F...
Disclaimer for this Talk
Process = Control-flow
2
Trends in BPM
modeling
• Highly-variable BPs
• Metaphor: rules/constraints
Dec t i
lar
a
ev
Imperative modeling
• Traditio...
Imperative Modeling
4
Imperative Modeling
Focus: howthings must be done
• Explicit description of the process control-flow
Closedmodeling
• All t...
BPMN
Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
rece...
BPMN
Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
rece...
BPMN
Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
rece...
Constraint-Based Modeling
9
Constraint-Based Modeling
Focus: whathas to be accomplished
• Explicit description of the relevant business constraints
• ...
Declare
Finalize order
Confirm
order
Reject
order
Ship
Notify
shipment issue
11
Declare
12
Declare
13
Declare
14
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-Off
In the literature: many hybrid notations
• Mix declarative and imperative constructs
• Lasagn...
Our Approach
Translate Declare into a notation that
• mediates between flexibility and control
• is a conservative extensio...
Process Responsibilities
• History recognition: given the history of a running
instance, compute the current state (or rej...
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 Decla...
Declare 2 DFA
…
…
…
'
LTLf NFA

nondeterministic
DFA

deterministic
LTLf2aut determin.
22
From Declare to DFA
…
…
…
'
LTLf NFA

nondeterministic
DFA

deterministic
LTLf2aut determin.
A process!
• allowed tasks: a...
Example
onse constraint).
close
order
pay
receipt
invoice
Fig. 1: Example of a Declare model
clarative model, this model s...
Problem Solved (?)
Convert Declare model into a DFA.

The DFA:
• accepts all and only the traces accepted by
the Declare m...
Can you Digest Spaghetti?
Or: the Issue of Understandability
26
Declare 2 DFA: Complexity
'
LTLf NFA

nondeterministic
DFA

deterministic
LTLf2aut determin.
exponential

blow-up
exponent...
From [Prescher et al., SIMPDA 2014]
(a) Declare model (b) Finite State Automaton
Fig. 7: The process mined out of BPIC 201...
From [Prescher et al., SIMPDA 2014]
(a) Declare model (b) Finite State Automaton
Fig. 7: The process mined out of BPIC 201...
From [Prescher et al., SIMPDA 2014]
(a) Declare model (b) Finite State Automaton
Fig. 7: The process mined out of BPIC 201...
Our Solution
BPMN-D: a declarative view on top of BPMN
BPMN-D
BPMN
Declare
31
BPMN-D
Core BPMN constructs
• None start/end events
• Atomic tasks
• XOR gateways
• Sequence flows
Extended, “declarative” ...
BPMN-D Tasks
Notation Name Semantics
t Atomic task As in BPMN: perform t
IN
{t1,…,tn}
Inclusive task Perform a task among ...
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...
Example
haviors that are allowed during the process execution, following the standard BPMN
semantics of deferred choice (i...
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…
•...
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
invoi...
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
...
Constraint Automaton
• A DFA can have multiple edges between same 2 states
• They represent the same state change!
• Const...
Example
ever a payment is done, then a receipt or an invoice must be produce
esponse constraint).
close
order
pay
receipt
...
Example
ever a payment is done, then a receipt or an invoice must be produce
esponse constraint).
close
order
pay
receipt
...
From CA to BPMN-D
Linear translation, in 3 steps:
1.Iterate through states, generating process
blocks
2.Interconnect block...
From CA to BPMN-D: States
1. State: introduces XOR split/join logic
2. Initial state: single start event of the process
3....
From CA to BPMN-D: Transitions
4. Self-loop: no effective state change; executable 0..* times
5. Proper transition: state ...
Example
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
46
Example
X
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
X
IN {receipt, ...
Example
X
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
X
close
order
I...
Example
X
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
X
close
order
I...
Example
0
IN {receipt, invoice}
1
close order
2
EX {pay}
pay
IN {pay, close order}
IN {receipt, invoice}
X
close
order
IN ...
Conclusion
• BPMN-D: conservative, “minor” extension of BPMN
with declarative constructs
• Can be encoded back into standa...
Ongoing/Future Work
• Include parallel gateways and exceptions
• Exception handling derived from “compensation
constraints...
Upcoming SlideShare
Loading in …5
×

CAiSE 2015 - Montali - Declarative Process Modeling in BPMN

310 views

Published on

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

  • Be the first to comment

CAiSE 2015 - Montali - Declarative Process Modeling in BPMN

  1. 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. 2. Disclaimer for this Talk Process = Control-flow 2
  3. 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. 4. Imperative Modeling 4
  5. 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. 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. 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. 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. 9. Constraint-Based Modeling 9
  10. 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. 11. Declare Finalize order Confirm order Reject order Ship Notify shipment issue 11
  12. 12. Declare 12
  13. 13. Declare 13
  14. 14. Declare 14
  15. 15. Pros and Cons (for dummies) Flexibility Control Imperative modeling - + Declarative modeling + - 15
  16. 16. Ultimate Goal:
 Trade-off between Flexibility and Control 16
  17. 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. 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. 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. 20. Declare as a Process? Automata to the Rescue! 20
  21. 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. 22. Declare 2 DFA … … … ' LTLf NFA
 nondeterministic DFA
 deterministic LTLf2aut determin. 22
  23. 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. 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. 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. 26. Can you Digest Spaghetti? Or: the Issue of Understandability 26
  27. 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. 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. 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. 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. 31. Our Solution BPMN-D: a declarative view on top of BPMN BPMN-D BPMN Declare 31
  32. 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. 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. 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. 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. 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. 37. Modular Unfolding X close order XX pay IN {receipt, invoice} EX {pay} IN {receipt,invoice} IN {pay, close order} BPMN-D 37
  38. 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. 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. 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. 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. 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. 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. 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. 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. 46. Example 0 IN {receipt, invoice} 1 close order 2 EX {pay} pay IN {pay, close order} IN {receipt, invoice} 46
  47. 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. 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. 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. 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. 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. 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

×