BPM5. Declarative Process Modelling
BPM5. Declarative Process Modelling
1. Introduction
3. Declare
5. Conclusion
Many of the slides in this presentation are based upon lecture material from J. Vanthienen (KU Leuven) 2
Lecture material
• Dumas, M., La Rosa, M., Mendling, J., Reijers, H. (2018)
Fundamentals of Business Process Management.
• Chapter 10 (10.4)
3
1. Introduction
4
Business Process Models
• Definition: A business process model is a collection of related,
structured activities or tasks that produce a specific service or
product (serve a particular goal) for a customer or customers
Review Pay
Register Check
Screen
Claim Insurance
Expert
Expert Visit
Review
5
Balancing Flexibility and Control
human transaction
collaboration system
6
The procedural approach to business
process modeling
• The procedural or imperative business process modeling paradigm
focuses on defining an activity sequence that will result in obtaining the
related corporate goal. These activity sequences can be easily represented
in graph-based languages (BPMN, Petri Nets, …)
• Potential problems:
• Inflexible, all execution paths must be anticipated
• Overspecification
• Maintainability
• Difficulties with demonstrating compliance
7
Uncontrolled Repetition in BPMN:
Ad-hoc sub-process
• The ad-hoc sub-process contains activities (tasks or sub-
processes) to be executed in arbitrary order and time
• May define order of sub-set of activities by sequence flow
• Can be used in an early version of a process diagram when the
order of execution is still unknown
Review company’s KPIs
Profile Interview
products and corporate
services executives
~
8
Procedural versus declarative approach
to business process modeling
• The declarative business process modeling paradigm focuses
on capturing and defining regulatory or internal directives in
constraints, e.g. sequence relationships among the different
activities.
• With a minimum specification of the relevant business
concerns, some freedom is left for the exact activity sequence
9
2. Declarative process modelling
10
Declarative process modeling paradigm
• The declarative business process modeling paradigm focuses
on capturing and defining regulatory or internal directives in
constraints, e.g. sequence relationships among the different
activities.
• With a minimum
specification of the
relevant business
concerns, some
freedom is left for
the exact activity
sequence
11
Dynamic, goal-driven execution
• Unlike procedural process modeling, declarative process
modeling does not involve the pre-computation of task control
flows, information flows and work allocation schemes.
• During the execution of a declarative process model, a suitable
execution scenario is constructed (either by a human or
machine coordinator) that realizes the business goals of the
process model. The latter is called goal driven execution
(planning).
12
Assumption bias
• Because procedural process models are the result of an implicit
precomputation of task dependencies, it is not generally
guaranteed that procedural process models do not include a
number of additional assumptions that overly specify the
underlying business process.
• Procedural process models are often overspecified.
13
Overspecification
• In a declarative model, we specify the constraints:
• E.g. 3 activities A, B, C have to be executed, but B has to come before C
14
Declarative process modelling languanges
• A common idea of declarative business process modeling is
that a process is seen as a trajectory in a state space and that
declarative constraints are used to define the valid movements
in that state space.
• The differences between declarative process languages can in
part be brought back to a different perception of state space,
transition types, and transition constraints.
• Important languages
• CMMN
• DCR
• Declare
15
CMMN
• https://www.omg.org/c
mmn/
• Example: claims
processing
• If you want to know
more (not part of this
course!):
https://www.youtube.com/watch?v
=hoqJFasQaUk
16
DCR
• Dynamic Condition Response
Graphs
• https://documentation.dcr.design/histor
y-of-dcr/
17
3. Declare
18
Declare
• Body of process model constraints
• Stems from model checking, where Linear Temporal Logic (LTL) is used to
check for properties (does A always happen before B?)
• Goes beyond using separate constraints and can be used in a model
• Modeling: with symbolic arcs, e.g. Response(A,B): Response
A B
19
Succession
Declarative process modeling using
constraints (in Declare) Response
Precedence
A B
• Others
• Co-existence constraints Succession
A B
• Ordered relations
• Precedence, response, succession
• Alternating ordered relations (Alternate Precedence, response, succession) -> each in turn
• Chain ordered relations (Chain Precedence, response, succession) -> immediately chained
20
Precedence
Precedence A B
× BAA
× BAB
• “no B before an A, or never B”. Note that this is a very relaxed relation of precedence,
because B does not have to execute straight after A, and another A can be executed
between the first A and B
• E.g. before you can take a course (B), you need to come and see us (A)
21
Response
Response
A B
eventually.
• Examples:
✓BABBB Succession
A B
✓ABAB
✓ABAAB
✓CCAAB
×BAABA
• After having a meal (A), you need to clean the table (B)
22
Succession
Succession A B
× BAAB
× AAA
× AABA
• If you invoice (B), you should have delivered something (A), you cannot deliver
without invoicing.
23
Declarative models
Response
• All these types of behavior are hard to, tidily,
A B specify into, e.g.
BPMN models or Petri nets
• Even for one constraint Precedence
A B
2
A B C vs
response response
24
Example: PhD trajectory
• Content creation can occur at any moment.
• Conference and journal paper can only happen after a new occurrence of
content creation when they are not enabled already.
• First seminar can only happen after conference, second seminar after
journal paper.
• First and second seminar must be followed eventually by defense.
25
Declarative Process Model – PhD
First Second
Defense
Seminar Seminar
Succession Succession
Precedence
1..*
Precedence
Conference
Alternate
precedence
Content
Creation
2..*
Journal
Alternate Paper
precedence
26
4. Declare constraints and execution
27
Declare – Execution
• For execution, regular expressions are used (which can be
represented as finite state machines)
• Finite state machines
These types of states map to
• Initial state 0 - Satisfied
- Temporarily and
permanently violated
• Non-accepting state 1
28
Example
• Exactly(A,n=2): A has to occur exactly 2 times
• Begin state:
• A has not occurred yet, #A<2 -> non-accepting, temporarily violated (accepting state still
reachable)
• A fires:
• A has fired one time, #A<2 -> non-accepting, temporarily violated
• A fires:
• A has fired 2 times, #A=2 -> accepting
• A fires:
• A has fired 3 times, #A>2 -> non-accepting, permanently violated (no way back)
Accepting state
Temporarily violated state
(there still exist transitions to an
accepting state)
30
Declare constraints
• Body of constraints: structured and hierarchical
• Unary and binary constraints
• Unary constraints:
31
Unary Declare constraints
• Position-related: Init(A)
• Init(A): activity A has to occur first
• End/Last(A): activity A has to occur as the last
activity Last(A)
• Numerosity-based: Absence(A,2)
32
Binary Declare constraints
33
Declare constraints – Binary
A p1
Responded
existence
• Position-agnostic: A B A p1 p
Responded
Co-existence(A,B)
p2
B
Response(A,B)
• E.g.: ACAAAB, ABB, AAAB, ACCBAB, BB A B A p1 B
• Not: AABBBA, A
Precedence
A Precedence B A p1
• Precedence(A,B): A has to happen A
Precedence B A p1
36
Declare constraints – Chain ordered
C
Chain C
response
Chain
A B A C p1
response
Chain
• Chain response(A,B): Right after an A
response
B A p1
right after A A
A
precedence
B
B
A
A 1
p1
p1
B
• E.g.: AAA, CCC, AC, ABAA, C
• Not: AABB, CB, B, ACAABB, ABAAACCBA
C
Chain Chain precedence(A,B)
• Chain succession(A,B): both Chain
C 1
succession
Chain
precedence(A,B) and Chain response(A,B) A B A C p1 1
p2
succession
Chain
hold A
A
succession
B
B
A
A
p1
p1
1
p2
p2
37
Declare constraints – Choice
• Choice(A,B): Either A or B has to occur, or both
• E.g.: ABAA, ABAAB, CCA, B, A, BC 1
A p1 End
• Not: CCC
1
Choice
A B A p1 End
Choice
A B B
Choice(A,B)
B p3
Exclusive choice(A,B)
38
Declare models
• Multiplication of all constraints to obtain a model (you do not have to know
how this is done exactly)
• Constraints interact, e.g. ✓ CABBBAABC
2
✓ ABCC
A B C
response response ✓ CC
✓ ACBC
✓ BCC
× ABBC
× ACC
× CBCB
× AABCBAC
39
Declare models
• Declare constraints are well-suited for:
• Looping behavior:
• Alternates have different ways of defining a loop
• Global behavior/long distance dependencies
• Chain constraints: affect all activities as they can stop the whole model to let one activity
occur
• BPMN would require a |A|-1 arcs to model this
• Execute something n times (counting):
• Choice and unary constraints
• BPMN would require special gateways, multiple instance activities (only sequential), duplicate
activities,…
• Negative constraints (extra, not considered here)
• Explicitly specifying what is not allowed
40
Conclusion
41
Key takeaways
• Two different business process modelling paragdigms
• Procedural vs. declarative
• When flexibility is required, the declarative approach can be
preferred
• Case management systems
• Knowledge Intensive Processes
• Several declarative modelling languages exist
• Adoption in practice has been slow
42
What should you know and what should
you be able to do?
• You should know:
• what declarative process modelling is about
• how the declarative modelling paradigm is different from the procedural one
• the basics of Declare: types of constraints, behavioural interpretation
• You should be able to:
• recognize a DCR, CMMN, and Declare model
• match declare rules and example sequences of behaviour, i.e. know whether a
sequence fulfills a constraint, or whether a constraint holds for a particular sequence
• given a Declare model, you should be able to determine whether certain traces fit the
model or not
43