0% found this document useful (0 votes)
8 views43 pages

BPM5. Declarative Process Modelling

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views43 pages

BPM5. Declarative Process Modelling

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 43

BPM5.

Declarative Process Modelling

Prof. Dr. Jochen De Weerdt


Lecture overview

1. Introduction

2. Declarative process modelling

3. Declare

4. Declare constraints and execution

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

• Objectives: (1) descriptive, (2) prescriptive, (3) explanatory

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

• Denoted with a tilde marker Assess


Evaluate prior
financial
performance
stability

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

• In a procedural model, we often overspecify by choosing one (or


a few) particular sequence(s):
• E.g.
• ABC
• BCA
• But what about:
• BAC

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/

• Example: treatment process

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

• Captures the notion of rules, which can be satisfied in multiple ways


Precedence
• Satisfied: the constraint is satisfied A B
• Temporarily violated: the constraint is not fulfilled, but can still become fulfilled in the
future
• Permanently violated: the constraint is violated and cannot become fulfilled anymore

19

Succession
Declarative process modeling using
constraints (in Declare) Response

• E.g. a Precedence constraint:


A B

• Activity B, if it occurs, has to be preceded by (at least one) activity A.

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

• Activity B, if it occurs, has to be preceded by (at least one) activity A.


Succession
• Examples: A B
✓ AAAB
✓ ABBBBAA These constraints
✓ ABAAABBAB are hard to model
✓ ABCAAB in BPMN
✓ CCCA
✓ AAA

× 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

• When activity A is executed,


A activity B hasB to be executed afterwards
Precedence

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

• Response(A,B) & precedence(A,B)


• When activity A is executed, activity B has to be executed afterwards eventually.
Activity B, if it occurs, has to be preceded by (at least one) activity A.
• Examples:
✓AABAAB
✓ABBBAB

× 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

• But certainly for a combined set


A
of constraints:
Succession
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

• Accepting state 1 Gives a natural way to both model


a process and maintain the notion of
rule verification
• Transition A
1 2

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)

• No other activity influences the outcome of the constraint


29
Example Permanently violated state
(no transitions to accepting state
exist anymore)

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)

• Absence(A,n+1): A can occur at most n times


• Existence(A,n): A has to occur at least n times
Existence(A,2)
• Exactly(A,n): A has to occur exactly n times
(Existence+Absence)
Exactly(A,2)

32
Binary Declare constraints

33
Declare constraints – Binary
A p1
Responded
existence
• Position-agnostic: A B A p1 p
Responded

• Responded existence(A,B): when A


existence
A B B p2

occurs, B has to occur as well1


B p2
• E.g.: ACAABA, BBA, CCCB, BB Responded Existence(A,B)
• Not: ACC, AA, CAA
A

• Co-existence(A,B): when A occurs, B has A


p1
to occur and vice versa1 Co-existence
p1
• E.g.: CCC, AABCBBA, BA, AB A
Co-existence
B p

• Not: ACAAAC, CBCC


A B p2

Co-existence(A,B)
p2
B

1The number of A’s and B’s is not important 34


Declare constraints – Simple ordered
• Response(A,B): when A occurs, B has to Response End
occur afterwards eventually A
A Response
Response
B
B A
A
p1
p1

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

before B can happen


A B A p1 B

• E.g.: ACAABA, A, CCC, AA


• Not: BACC, BB, CB, CBA Precedence(A,B)
Succession
End
A Succession B p2
• Succession(A,B): both Precedence(A,B) A
Succession B p2
and Response(A,B) hold A B
A
p2
p1
• E.g.: CCC, ABBBAB, AB, AAB, ABB, CACCABB A p1
A p1 B
• Not: ACC, AABBA, ACBCA, BBA, A, B
Succession(A,B)
35
Declare constraints – Alternating ordered
1
Alternate p1
response
A B 1
Alternate p1
response 1
A Alternate B p1
• Alternate response(A,B): every occurrence of response A p2

A has to be followed by a new occurrence of B


A B
A p2
• E.g.: ABAB, BBABBAB, ACCCBAB, CCB Alternate response(A,B)
A p2
• Not: AABB, CA, A, ACAABB Alternate
precedence
A Alternate B A p1
• Alternate precedence(A,B): B can occur only A
precedence
Alternate B A p1
after the next occurrence of A A
precedence
B A p1
• E.g.: AAA, CCC, AC, ABAA, ABACCBA, C
• Not: ABB, CB, ABBA
Alternate Alternate precedence(A,B)
• Alternate succession(A,B): both Alternate Alternate
succession 1
precedence(A,B) and Alternate response(A,B) A
A
succession
Alternate
B
B p1
p1
1
hold succession 1
• E.g.: CCC, AB, ACCB, ACCBCCACCB A B
A A
p1
p2 p2
• Not: ACC, AABBA, ACBCA, BBA, A, B
A p2
Alternate succession(A,B)

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

occurrence of A, only B can occur A B A p1 B

• E.g.: ABABBB, BB, CC, ABCBCCABB Chain response(A,B)


• Not: ACB, CA, CCAC Chain
C
C1
precedence
Chain
• Chain precedence(A,B): B can occur only A
Chain
precedence
B A C 1
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

• E.g.: CCC, AB, CCABC


• Not: ACC, AABBA, ACBCA, BA, A, B Chain succession(A,B)

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)

• Exclusive choice(A,B): A and B cannot occur together, butB at least one


has to occur Exclusive
choice A p1
• E.g.: AAA, AC, CBBB, B A B Exclusive 1
• Not: AABB, BA, ACABB, CC choice p2 A End p1
A B 1
B p3 p2 End

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

• C has to occur exactly two times – if A fires, B has to occur eventually


afterwards – if B fires, C has to occur eventually afterwards

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

You might also like