The document introduces declarative process modeling notation (DECLARE) which specifies constraints for permitted behavior rather than explicit execution paths. It provides templates for constraint types like existence, activation-target relations, mutual relations, and negatives. Constraints can be used to declaratively specify a paper submission process and an invoice handling process. Compliance of process instances can be checked against the specified constraints.

1. Introduction to the
declarative specification
of processes
Claudio Di Ciccio
WS 2018-19
From models to execution constraints

2.  Business process defined as set of constraints
 Rules to be respected during the execution
 No explicit specification of every possible execution path
 Instead: restrictions
 “DECLARE” is a declarative process modelling notation
What is a declarative specification of a
business process?
Imperative: closed model Declarative: open model
DECLARATIVE PROCESS MODELLINGPAGE 2

3. Declarative process specification
 “Open model”
 Specify constraints for permitted
behaviour
 Every execution that complies with
them is acceptable
SEITE 3

4.  Check stock availability must occur right after the start
 Right after Check stock availability, either Manufacture product or
Retrieve product from warehouse will occur
 Confirm order may occur once only after Manufacture product or Retrieve
product from warehouse
 Emit invoice and Ship product must occur once after Confirm order
 Receive payment will occur once after Emit invoice
 Archive order may occur once only after Emit invoice and Confirm order
 Archive order must occur right before the end
Declarative specification
of a process model
Check
stock
availability
Manufac-
ture
product
Retrieve
product
from
warehouse
Confirm
order
Ship
product
Archive
order
Emit
invoice
Receive
payment
PAGE 4

5. Init(a)
Every process instance starts with activity a
 bcaad  adcac  dabce  aeb  aabde
End(a)
Every process instance ends with activity a
 abcde  cedea  aacbaa  ababac  aabde
Participation(a)
Activity a occurs at least once
 bbcd  bedcca  bcaeda  dbdeb  aabde
AtMostOne(a)
Activity a occurs at most once
 baea  beed  acccd  edbcd  aabde
DECLARE templates:
Existence constraints
PAGE 5
a
Init
a
End
a
1..*
a
0..1

6. RespondedExistence(a, b)
If a occurs, b has to occur at some point, no matter when
 bcdd  bdca  addcd  adaab  bdaacb
Response(a, b)
If a occurs, b has to occur after a
 bdaac  adbbc  cddce  aadccba  bdaacb
AlternateResponse(a, b)
If a occurs, b has to occur after a, with no a in-between
 aabbd  aedbab  beedcd  abababa  bdaacb
ChainResponse(a, b)
b has to occur immediately after a
 cbaab  dabbab  aba  bdbababb  bdaacb
DECLARE templates:
Relation constraints I
Activation Target
PAGE 6
ba
ba
ba
ba
strictness

7. RespondedExistence(b, a)
If b occurs, a has to occur at some point, no matter when
 acdd  bdca  bddcd  adabb  acbeead
Precedence(a, b)
If b occurs, then a has to occur before b
 cbdac  adbbc  cddcea  aadccba  acbeead
AlternatePrecedence(a, b)
Each time b occurs, it is preceded by a, with no b in-between
 aabd  adbbab  beead  abababa  acbeead
ChainPrecedence(a, b)
If b occurs, then a has to occur immediately beforehand
 ccbab  abbab  aba  abaab  acbeead
DECLARE templates:
Relation constraints II
PAGE 7
ba
ba
ba
ba
ActivationTarget
strictness

8. CoExistence(a, b)
RespondedExistence(a, b) and RespondedExistence(b, a) hold
 bcdd  cddc  addcd  adaab  dbdaacb
Succession(a, b)
Response(a, b) and Precedence(b, a) hold
 bdaac  adbbc  cddce  aadccba  dbdaacb
AlternateSuccession(a, b)
AlternateResponse(a, b) and AlternatePrecedence(b, a) hold
 aabbd  addbab  beedcd  ababab  dbdaacb
ChainSuccession(a, b)
ChainResponse(a, b) and ChainPrecedence(b, a) hold
 ccbab  dabbab  dabab  babab  dbdaacb
DECLARE templates:
Mutual relation constraints
PAGE 8
ba
ba
ba
ba
ActivationTarget
Activation Target
strictness

9. NotCoExistence(a, b)
a and b cannot co-occur
 bdaac  adeec  cddce  cbdcb  aadccba
NotSuccession(a, b)
b cannot occur after a and a cannot occur before b
 aabad  adccda  bcdaed  dbabc  aadccba
NotChainSuccession(a, b)
b cannot occur immediately after a
 cbbab  adadbb  aba  aaadbbb  aadccba
DECLARE templates:
Negative relation constraints
PAGE 9
ba
ba
ba
ActivationTarget
Activation Target
strictness

10. PAGE 10
Constraints subsumption (strictness)
hierarchy

11. PAGE 11
DECLARE in everyday life
Take left lane Turn right

12. A declarative process specification
in DECLARE
 If an abstract is submitted, a new paper
had been written or will be written
 After the paper submission, a
confirmation email is sent
 After the paper submission, the paper will
be reviewed;
there can be no review without a
preceding submission
 A paper can be accepted only after it has
been reviewed
 After the rejection, no further submission
follows
 Paper cannot be both accepted and
rejected
Submit abstract Write new paper
Submit paper
Send
confirmation
email
Submit paper Review paper
Review paper Accept paper
Reject paper Submit paper
Accept paper Reject paper
= activation task
RespondedExistence(Submit abstract, Write new paper)
Response(Submit paper, Send confirmation email)
Succession(Submit paper, Review paper)
Precedence(Review paper, Accept paper)
NotSuccession(Reject paper, Submit paper)
NotCoExistence(Accept paper, Reject paper)
Template Tasks
DECLARATIVE BUSINESS PROCESSESPAGE 12

13. A declarative process specification
Submit abstract
Write new paper Submit paper
Send
confirmation
email
Review paper Accept paper
Reject paper
DECLARATIVE BUSINESS PROCESSESPAGE 13

14.  Every process instance starts with
receiving an invoice.
 Whenever an invoice is recorded
into the database, it was received
beforehand.
 When an invoice is received, the
current account will be checked at
some point afterwards. No current
account is checked, unless an
invoice was received at some point
before.
 The account will be checked at least
once in every process instance.
 Every single time an invoice is
settled, the current account was
checked before.
Specification
Exercise: from description to
specification
Description
DECLARATIVE PROCESS MODELLINGPAGE 14
Init

15.  cbda
 cba
 cda
 c
 cbdaabaaadaa
 caadabda …
Specification
Exercise: list possible cases
Possible cases
 bdca
 bca
 dbdca
 ebca
 bcaeeca
 ddbddcca …
DECLARATIVE PROCESS MODELLINGPAGE 15
End
Init
1..1

16.  Init(a)
 Participation(d)
 NotCoExistence(d,e)
 NotChainSuccession(a,d)
 End(d)
 Precedence(b,d)
 CoExistence(b,c)
 Response(a,c)
Model
PAGE 16
Compliance checking
Constraints

17.  Init(a)
 Participation(d)
 NotCoExistence(d,e)
 NotChainSuccession(a,d)
 End(d)
 Precedence(b,d)
 CoExistence(b,c)
 Response(a,c)
Model
PAGE 17
Compliance checking
Constraints

18.  Init(a)
 Participation(d)
 NotCoExistence(d,e)
 NotChainSuccession(a,d)
 End(d)
 Precedence(b,d)
 CoExistence(b,c)
 Response(a,c)
Model
PAGE 18
Modelling of a specification
(not necessarily a concurrent system!)
Constraints