Montali - DB-Nets: On The Marriage of Colored Petri Nets  and Relational Databases

On The Marriage of Colored Petri Nets  
and Relational Databases
Marco Montali
Free University of Bozen-Bolzano
SOAMED 2016
DB-Nets

Marrying processes and data 
is extremely difﬁcult….
… but is a must  
if we want to really understand  
how complex dynamic systems operate.
2

Our Research
3
Theory
Practice

Our Research
4
Theory
Practice

Our Approach
5
Business Process
Management
Data
Management
Conceptual
Modeling
Formal
Methods
Artiﬁcial
Intelligence

Dynamic Systems of Interest
• Business processes
• Multiagent systems
• Distributed systems
6

Business Process Lifecycle
7
picture by Wil van der Aalst

Formal Veriﬁcation
Automated analysis
of a formal model of the system
against a property of interest,
considering all possible system behaviors
8
picture by Wil van der Aalst

Two Questions
How to formally and conceptually  
account for the process+data interplay  
in conventional, activity-centric BP models?
How to verify such BPMs?
9

Two Questions
• How to formally and conceptually
account for the process+data interplay in
conventional, activity-centric BP models?
• How to verify such BPMs?
10
Business
Turing
Machines
BTMs

Data and Processes
12
Review
Request
Fill Reim-
bursement
Review Reim-
bursement
Rejected
Accepted
decision-
making
action
footprint

Is this Synergy Reﬂected
by Models?
Survey by Forrester [Karel et al, 2009]: lack of interaction
between data and process experts.
• BPM professionals: data are subsidiary to processes
• Master data managers: data are the main driver for the
company’s existence
• 83/100 companies: no interaction at all between these
two groups
• This isolation propagates to models, languages and tools
13

Conventional Data Modeling
Focus: revelant entities, relations, static constraints
Supplier ManufacturingProcurement/Supplier
Sales
Customer PO Line Item
Work OrderMaterial PO
*
*
spawns
0..1
Material
But… how do data evolve?
Where can we ﬁnd the “state” of a purchase order?
14

Conventional Process Modeling
Focus: control-ﬂow of activities in response to events
But… how do activities update data?
What is the impact of canceling an order?
15

Do you like Spaghetti?
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Customers Suppliers&CataloguesCustomer POs Work Orders Material POs
IT integration: difﬁcult to manage, understand, evolve
17

Too Late!
• Where are the data?
• Where shall we model relevant business rules?
18
o late to reconstruct the missing pieces
Where is our data?
part is in the DBs,
part is hidden in the process execution engine.
Where are the relevant business rules, and how are they modeled?
At the DB level? Which DB? How to import the process data?
(Also) in the business model? How to import data from the DBs?
DataProcess
Supplier ManufacturingProcurement/Supplier
Sales
Customer PO Line Item
Work OrderMaterial PO
*
*
spawns
0..1
Determine
cancelation
penalty
Notify penalty
Material
Process Engine
Process State
Business rules
For each work order W
For each material PO M in W
if M has been shipped
add returnCost(M) to penalty

…There is Hope!
20
data-centric
…
…
…
activity-centric
1
9
9
8
…
2
0
0
3
2
0
0
4
2
0
0
5
2
0
0
6
2
0
0
7
2
0
0
8
2
0
0
9
2
0
1
0
2
0
1
1
2
0
1
2
2
0
1
3
2
0
1
4
2
0
1
5
2
0
1
6
N.B.: these are “sparse” dots!!!

data-centric
…
…
…
activity-centric
1
9
9
8
…
2
0
0
3
2
0
0
4
2
0
0
5
2
0
0
6
2
0
0
7
2
0
0
8
2
0
0
9
2
0
1
0
2
0
1
1
2
0
1
2
2
0
1
3
2
0
1
4
2
0
1
5
2
0
1
6
21
[PODS98,
Abiteboul et al.]
Relational
Transducers
[ICDT09, Vianu]
Veriﬁcation of
artifact-centric
processes
[ICDT05, Vardi]
Model checking
for database
theoreticians
[ECAI12, _]
Knowledge
and action
bases
[PODS13, _]
Data-Centric
Dynamic
Systems
[STTT16, _]
Case-centric
DCDS
[PODS13, _]
Veriﬁcation of data-centric processes

data-centric
…
…
…
activity-centric
1
9
9
8
…
2
0
0
3
2
0
0
4
2
0
0
5
2
0
0
6
2
0
0
7
2
0
0
8
2
0
0
9
2
0
1
0
2
0
1
1
2
0
1
2
2
0
1
3
2
0
1
4
2
0
1
5
2
0
1
6
22
[IBM J.,Nigam and Caswell]
Business Artifacts
[OTM08, Hull]
Survey on
business artifacts
[WSFM10, Hull et al.]
First paper on IBM
GSM
First draft of
OMG CMMN
Start of the  
EU Project
ACSI

data-centric
…
…
…
activity-centric
1
9
9
8
…
2
0
0
3
2
0
0
4
2
0
0
5
2
0
0
6
2
0
0
7
2
0
0
8
2
0
0
9
2
0
1
0
2
0
1
1
2
0
1
2
2
0
1
3
2
0
1
4
2
0
1
5
2
0
1
6
•[BPM2010, Richardson] BPM vs master data dichotomy
•Data+Process integration key to: 
- assess value of processes and evaluate KPIs [Meyer et al, 2011] 
- aggregate relevant info, elicit business rules [ABDIS11, Dumas]
•[Reichert, 2012]: “Process and data are just two sides of the
same coin”
[BPM09WS, Kūnzle and Reichert]
First paper on Philharmonic Flows •
23

data-centric
…
…
…
activity-centric
1
9
9
8
…
2
0
0
3
2
0
0
4
2
0
0
5
2
0
0
6
2
0
0
7
2
0
0
8
2
0
0
9
2
0
1
0
2
0
1
1
2
0
1
2
2
0
1
3
2
0
1
4
2
0
1
5
2
0
1
6
[ICATPN07,
Lazic et al.]
Data
nets
[CAiSE10,
Sidorova et al.]
Conceptual
nets
[TCS11, Rosa-Velardo
and de Frutos-Escrig]
ν-PNs
(nets managing names)
[FAOC16, _]
Veriﬁcation of
PNs with names
[PN16, Lasota]
Survey on PNs
with data
[PN15, Triebel
and Sürmeli]
Algebraic PNs

data-centric
…
…
…
activity-centric
1
9
9
8
…
2
0
0
3
2
0
0
4
2
0
0
5
2
0
0
6
2
0
0
7
2
0
0
8
2
0
0
9
2
0
1
0
2
0
1
1
2
0
1
2
2
0
1
3
2
0
1
4
2
0
1
5
2
0
1
6
DB-Nets
CPNs +
databases
[AAAI17, _]  
RAW-SYS 
Workﬂow nets +
databases

One Step Back…
How do  
contemporary  
activity-centric BPMSs  
account for the  
process-data interplay?
26

Example: BizAgi (~)
27
Review
Request
Fill Reim-
bursement
Review Reim-
bursement
Rejected
Accepted

Case and Persistent Data
Review
Request
Fill Reim-
bursement
Review Reim-
bursement
Rejected
Accepted
req info result reimbursement
personal
info
28

Persistent Data Engineering
persistent
storage29
Review
Request
Fill Reim-
bursement
Review Reim-
bursement
Rejected
Accepted
personal
info
framework data model custom code

Case Data Engineering
persistent
storage30
Review
Request
Fill Reim-
bursement
Review Reim-
bursement
Rejected
Accepted
personal
info
framework data model custom code
user forms
external services

Recipe
• Explicit control-ﬂow
• Local, case data
• Global, persistent data
• Queries/updates on the persistent data
• External inputs
• Internal generation of fresh IDs
31
DATA-AWARE ACTIVITY CENTRIC PROCESS

Colored Petri Nets
• In ν-PNs: explicit construct to create globally fresh data
values (ν variables)
• No persistent data!
32

Recipe
• External inputs
33
COLORED PETRI NETS
Using ν variables

Data layer: relational DB with constraints (monolithic data)
Process layer: evolves an instance of the DB
• Condition-action rules: action executability, provide parameters
• Atomic actions: conditional CRUD operations with external
inputs
Data-Centric Dynamic Systems
34
unibz.itunibz.it
An abstract, pristine framework to formally describe processes that manipulate
data.
• Captures virtually all existing approaches to data-aware processes, such as
the artifact-centric paradigm.
DCDS
Data Layer
Process Layer
external
service
external
service
external
service
UpdateRead
• Data layer: relational database (with constraints).
• Process layer: condition-action rules (include service calls that input new
data).
Marco Montali Veriﬁcation of Relational DCDSs PODS 2013 3 / 25

Recipe
• External inputs
35
DATA-CENTRIC DYNAMIC SYSTEMS
~
Can be simulated

DB-Nets
37
persistence layer
data logic layer
control layer
DB
ActionsQueries
View places Places Transitions
fetch update
populate trigger
Arcs
Read arcs
Rollback arcs
Fig. 1. The conceptual components of db-nets
joint proposal with Andy Rivkin

Persistence Layer
Typed relational DB with constraints
• DB: set of relation schemas with typed components
• Type: data domain with rigidly deﬁned predicates
• Constraints: Domain-independent FO sentences
• Keys, FKs, dependencies, multiplicities, …
DB Instance: ﬁnite set of typed facts over DB, satisfying all constraints
38

Persistence Layer
Typed relational DB with constraints
• DB: set of relation schemas with typed components
• Type: data domain with rigidly deﬁned predicates
• Constraints: Domain-independent FO sentences
• Keys, FKs, dependencies, multiplicities, …
DB Instance: ﬁnite set of typed facts over DB, satisfying all constraints
39
That’s just the relational model!

Example
40
Emp
name: string
Ticket
id: int descr: string
Resp
emp: string ticket: int
Each employee can handle at
most one ticket at a given time
Log
ticket: int emp: string descr: string

Data Logic
Bidirectional interface for interacting with a DB
instance of the persistence layer
41
Read-mode: query
• open, domain-independent FO
formula
• answers: substitutions of free
variables s.t. the resulting FO
sentence is true in the DB instance
Write-mode: action
• Name
• Parameters
• Add and delete list
• Templates of facts using
parameters and constants…
• …to be added to/removed from
the current DB instance
• Transactional semantics: commit vs
roll-back
That’s just SQL!

Example: Queries
• Get tickets and their description
• Get “idle” employees
42
plying the update on the given database in
over deletions (this is a standard approach
situation in which the same fact is asserted
The data logic simply exposes a set of q
be used by the control layer to obtain data
induce updates on the persistence layer.
Definition 14 (Data logic layer). Given
typed data logic layer over P is a pair hQ, Ai,
queries over P; (ii) A is a finite set of action
Example 2. We make the scenario of Example
layer L over P. L exposes two queries to inspec
• Qe(e):- Emp(e) ^ ¬9t.Resp(e, t), to extract id
• Qt(t, d):- Ticket(t, d), to extract tickets and
In addition, L provides three main functionali
layer: ticket registration, assignment/release, a
alized through four actions (where, for simplic
action and its name). The registration of a ne
that, given an integer t, and two strings e and
ously creates a ticket identified by t and descri
assigns the employee identified by e to such tic

• REGISTER(t,d,e): register ticket t with description d, assigning it to
employee e
• Add Ticket(t,d), Resp(e,t)
• ASSIGN(e,t): assign employee e to ticket t
• Add Resp(e,t)
• RELEASE(e,t): release employee e from managing ticket t
• Del Resp(e,t)
• LOG(t,e,d): ﬂush and log the info related to ticket t
• Del Ticket(t,d), Resp(e,t)
• Add Log(t,e,d)
Example: Actions
43

• REGISTER(t,d,e): register ticket t with description d, assigning it to
employee e
• Add Ticket(t,d), Resp(e,t)
• ASSIGN(e,t): assign employee e to ticket t
• Add Resp(e,t)
• RELEASE(e,t): release employee e from managing ticket t
• Del Resp(e,t)
• LOG(t,e,d): ﬂush and log the info related to ticket t
• Del Ticket(t,d), Resp(e,t)
• Add Log(t,e,d)
Rolls back if e is
already managing another
Example: Actions
44
Roll back if e is already
managing another ticket
Rolls back if t already exists
with a different description

Control Layer
A “data-oriented” CPN
• Process control-ﬂow
• Evolution of tokens and their “case” data
• Interaction with the persistence layer via the
data logic layer
45

Place
Colored condition/state of the control layer
• Color: ordered combination of types
• Tokens carry tuples of data over the corresponding
types
• Two types of place, to distinguish local and global
data
46

Normal Place
• Represent case states and resources
• Color: schema of the local data carried by tokens
• May be seen as a special relation of the
persistence layer
• Tokens explicitly manipulated by the control layer,
as customary in CPNs
47
Tickets
h
Fig. 2. Th

View Place
• “View” of the persistence layer provided to the
control layer
• Hosts the answers to a query from the data logic
• Color must be compatible with the returned answers
• Clearly identiﬁes where the control layer needs to
“read” from the persistence layer
• Not modiﬁed explicitly by the control layer
• Implicitly updated by applying actions on the
persistence layer, and recomputing the view
48
Tickets
h
Fig. 2. Th

Example
49
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a
fresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistence
layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The
control layer realizes a simple ticket processing workflow, where tickets are created,
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, emp
htid,em
p
htid, empi
hempi
htid, descri
Fig. 2. The control layer of a db-net for ticket manage
fresh input variable, and descr is an arbitrary input var
Example 3. Figure 2 shows the control layer of a db
layer P defined in Example 1 and the data logic layer L
control layer realizes a simple ticket processing workfl
Idle Employees
r
(⌫t,
Cr
Tickets
hempi
hti
Fig. 2. The control
fresh input variable,
Example 3. Figure
layer P defined in E
control layer realize
int int ⇥ string int ⇥ string
↵✓ can be successfully applied to I if apply(↵✓, I) complies
The application of an action instance amounts to ground all
in the definition of the action as specified by the given su
plying the update on the given database instance, giving p
over deletions (this is a standard approach, which unambi
situation in which the same fact is asserted to be added and
The data logic simply exposes a set of queries and a set
be used by the control layer to obtain data from the persi
induce updates on the persistence layer.
Definition 14 (Data logic layer). Given a D-typed persi
typed data logic layer over P is a pair hQ, Ai, where: (i) Q is
queries over P; (ii) A is a finite set of actions over P.
Example 2. We make the scenario of Example 1 operational, in
layer L over P. L exposes two queries to inspect the persistence
• Qe(e):- Emp(e) ^ ¬9t.Resp(e, t), to extract idle employees;Qt(t, d):- Ticket(t, d), to extract tickets and their description.
n addition, L provides three main functionalities to manipulate tickets in persistence
ayer: ticket registration, assignment/release, and logging. Such functionalities are re-
lized through four actions (where, for simplicity, we blur the distinction between an
ction and its name). The registration of a new ticket is managed by an action reg
hat, given an integer t, and two strings e and d, (reg·params = ht, e, di, simultane-
Case variables:
- ticket id
- name of responsible employee
int ⇥ string

Transition
Atomic unit of work within the control layer
• Input data: obtained by
• Consuming tokens from its input places
• Reading tokens from its input view places
• To access tokens and their data: multisets of tuples
of “matching” variables
• Data guard over the input variables
50

Transition
Atomic unit of work within the control layer
• Output data: inputs + additional variables (external
input) + ν variables (new ids)
• Output data used to
• Bind to an action of the data logic, updating the
persistence layer
• Produce tokens and insert them into the output
places
51

Example
52
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
r
(⌫t,
Cr
Tickets
hempi
hti
Fig. 2. The control
fresh input variable,
Example 3. Figure
layer P deﬁned in E
control layer realize

Example
53
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi

Example
54
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi

Run!
55
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Emp
Andy
Marco
TicketResp Log
hAndyi
hMarcoi

Run!
56
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
TicketResp Log
hAndyi
hMarcoi
⌫t = 1
emp = Andy
descr = blah
Emp
Andy
Marco

Run!
57
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Ticket
1 blah
Resp
Andy 1
Log
hMarcoi
Emp
Andy
Marco
h1, Andyi

Run!
58
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Ticket
1 blah
Resp
Andy 1
Log
hMarcoi
Emp
Andy
Marco
h1, Andyi
tid = 1
emp = Andy

Run!
59
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Resp Log
hAndyi
hMarcoi
Emp
Andy
Marco
Ticket
1 blah
h1, blahi
h1, Andyi

Run!
60
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Resp Log
hAndyi
hMarcoi
Emp
Andy
Marco
Ticket
1 blah
h1, blahi
h1, Andyi
⌫t = 5
emp = Andy
descr = blah

Run!
61
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Log
hMarcoi
Emp
Andy
Marco
Ticket
1 blah
2 blah
h1, blahi
h1, Andyi
Resp
Andy 2
h2, Andyi
h2, blahi

Run!
62
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Log
hMarcoi
Emp
Andy
Marco
Ticket
1 blah
2 blah
h1, Andyi
Resp
Andy 2
h2, Andyi
tid = 1
emp = Andy
h1, blahi
h2, blahi

Run?
63
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Log
hMarcoi
Emp
Andy
Marco
Ticket
1 blah
2 blah
h1, Andyi
Resp
Andy 2
Andy 1
h2, Andyi
tid = 1
emp = Andy
h1, blahi
h2, blahi

Rollback Flow
Accounts for the production and routing of tokens when
the application of a ground action fails
• update ok: update committed on the DB, normal output
flow used, rollback flow ignored
• update violates some constraint: rollback on the DB,
rollback flow used, normal output flow ignored
The rollback flow can be used to model “undo” or
“compensation” in the control layer when the persistence
layer rejects an update
64

Example: “Undo”
65
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi

Run!
66
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Log
hMarcoi
Emp
Andy
Marco
Ticket
1 blah
2 blah
h1, Andyi
Resp
Andy 2
Andy 1
h2, Andyi
tid = 1
emp = Andy
h1, blahi
h2, blahi

Run!
67
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
pi
htid,em
pi
htid, empi
hempi
htid, descri
htid,em
pi
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
logData
(tid, emp, id)
ResolveTickets
htid,em
p
htid, empi
hempi
htid, descri
Log
hMarcoi
Emp
Andy
Marco
Ticket
1 blah
2 blah
h1, Andyi
Resp
Andy 2
h2, Andyi
tid = 1
emp = Andy
h1, blahi
h2, blahi

Execution Semantics
Infinite-state relational transition system
• State: labeled with a DB-net snapshot <I,m>
• I: DB instance for the persistence layer
• m: marking of the control layer that properly fills view
places w.r.t. I
• Transition: firing of a control layer transition with a “legal”
binding for the inscription variables
• All possible snapshots and all (infinitely many) bindings
are considered
68

…
Sources of Inﬁnity
69
……
…
…
…
…
…
…
…
…
…
…
Fixed initial
snapshot

…
70
……
…
…
…
…
…
…
…
…
…
…
Inﬁnite-branching  
due to external inputs
and new id generation

…
71
……
…
…
…
…
…
…
…
…
…
…
Runs visiting inﬁnitely many DBs/markings  
due to usage of external data

The Conventional, Propositional Case
Process control-ﬂow
(Un)desired property
73

Finite-state
transition
system
Propositional
temporal formula|=
74

Finite-state
transition
system
Propositional
temporal formula|=
Veriﬁcation
via model checking
2007 Turing award:
Clarke, Emerson, Sifakis
75

The Data-Aware Case
76
Process+Data

First-order
temporal formula|=
Process+Data
The Data-Aware Case
Inﬁnite-state, relational
transition system 77

First-order
temporal formula|=
?
The Data-Aware Case
78
Process+Data
Inﬁnite-state, relational
transition system [Vardi 2005]

Why FO Temporal Logics
• To inspect data: FO queries
• To capture system dynamics: temporal
modalities
• To track the evolution of objects: FO
quantiﬁcation across states
• Example:  
It is always the case that every order  
is eventually either cancelled or paid
79

Why FO Temporal Logics
• To inspect data: FO queries
• To capture system dynamics: temporal
modalities
• To track the evolution of objects: FO
quantiﬁcation across states
• Example:  
It is always the case that every order  
is eventually either cancelled or paid
80
G
✓
8x.Order(x)
! F State(x, cancelled) _ State(x, paid)
◆

Which logics?
• First-order temporal logics with active domain
quantiﬁcation
• Branching-time: μLa 
• Linear-time: LTL-FOa 
• Only initial constants can explicitly appear in the formulae
• Corresponding notions of bisimulation/trace equivalence
81
G(8s.Student(s) ! F(Retired(s) _ Graduated(s))
AG(8o.Order(o) ^ Status(o, open) ! EF(mathitStatus(o, shipped))

A
true
false
BPMS and Data
Correct?
• BizAgi…
• YAWL…
82

A
true
false
BPMS and Data
Correct?
• BizAgi… not sure…
• YAWL… YES!
83

The Good…
DCDS are:
• Markovian: Next state only depends on the
current state + input.  
Two states with identical DBs are bisimilar.
• Generic: FO/SQL (as all query languages) does
not distinguish structures which are identical
modulo uniform renaming of data objects.
—> Two isomorphic states are bisimilar
84

…the Bad…
86
Persistence
layer
Control layer (without colors)
Data logic layer

…and the Ugly
Simulation of a 2-counter Minsky machine
• Counter —> “size” of a unary relation
• Test counter for zero: query asserting that the counter
relation is empty
• What matters is the # of tuples, not the actual values
87
New
Increment Decrement

… and the Ugly (Again)
• By removing the persistence layer, DB-nets
become as expressive as Petri nets with names
• A lot of undecidability results
• Recall that CTL model checking is undecidable
already for P/T nets
88

Problem Parameters
89
persistence layer
data logic layer
control layer
DB
ActionsQueries
fetch update
populate trigger
Arcs
Read arcs
Rollback arcs

Problem Parameters
90
persistence layer
data logic layer
control layer
DB
ActionsQueries
fetch update
populate trigger
Arcs
Read arcs
Rollback arcs
Choice 1 Choice 2 …
Choice 1 undecidable boring boring
Choice 2 boring PTime boring
Choice 3 boring boring PSpace
… NP boring …

Bottom Line
• We want at least reachability
• We want robust conditions for decidability
• We would like to reuse conventional model
checking techniques
• Inﬁnitely many cases may appear in the life of the
system, but only boundedly many coexist
• Resources!
91

Our Goal
92
First-order
temporal formula
|=
Inﬁnite-state
transition system

Our Goal
93
First-order
temporal formula
|=
Inﬁnite-state
transition system
|=
Finite-state
abstraction
Propositional
temporal formula
‘

Our Goal
94
First-order
temporal formula
|=
Inﬁnite-state
transition system
|= Propositional
temporal formula
‘
If and only if
Finite-state
abstraction

State-Boundedness
[PODS 2013]
Put a pre-defined bound on the DB size 
and on the number of tokens moving around
• Resulting transition system: still infinite-state
(even in the 1-bounded case)
• But: infinitely-many encountered values along a
run cannot be “accumulated” in a single state
95

Effect of state-boundedness
96
General State-bounded
μLa undecidable
LTL-FOa undecidable

97
μLa undecidable
decidable  
abstraction must  
depend on the formula!
LTL-FOa undecidable undecidable

98
μLa undecidable
decidable  
Reason?
FO quantiﬁcation
across states.

99
μLa undecidable
decidable  
Logic unable to isolate
single runs/computations

Logics with
Persistent Quantiﬁcation
• Intuition: control the ability of the logic to quantify
across states
• Only objects that persist in the active domain of
some node can be tracked
• When an object is lost, the formula trivializes to true
or false
• E.g.: “guarded” until
Persistence-Preserving µ-calculus (µLP)
In some cases, objects maintain their identity only if they persist in th
active domain (cf. business artifacts and their IDs).
. . .
StudId : 123
. . .
StudId : 123
. . .dismiss(123) newStud()
ID() = 123
µLA
µLFOG(8s.Student(s) ! Student(s)U(Retired(s) _ Graduated(s)))
100

Effect of Persistent
Quantiﬁcation
101
μLa undecidable
decidable  
μLp
LTL-FOp

Quantiﬁcation
102
μLa undecidable
decidable  
μLp undecidable
LTL-FOp undecidable

Quantiﬁcation
103
μLa undecidable
decidable  
μLp undecidable
decidable
formula-independent
abstraction!
LTL-FOp undecidable
decidable
formula-independent
abstraction!

Pruning Infinite-Branching
• Consider a DB-net snapshot
• Fixed number of external inputs —> only
boundedly many isomorphic types relating the
input objects and those appearing in the snapshot
• Input configurations in the same isomorphic type
produce isomorphic snapshots
• Keep only one representative successor state
per isomorphic type
The “pruned” transition system is finite-
branching and bisimilar to the original one
104

Example
• External Input: single (new?) value
• Current state: two objects (in DB and/or marking)
a,b
a
b
c
de
105

Example
a,b
a
b
c
106
• External Input: single (new?) value
• Current state: two objects (in DB and/or marking)

Compacting Inﬁnite Runs
• Key observation: due to persistent quantiﬁcation, the
logic is unable to distinguish local freshness from
global freshness
• So we modify the transition system construction:  
whenever we need to consider a fresh representative
object…
• … Is there an old, recyclable object? —> use that one
• … If not —> pick a globally fresh object
This recycling technique preserves bisimulation!
107

Compacting Inﬁnite Runs
• [Calvanese et al, 2013]: if the system is size-
bounded, the recycling technique reaches a
point were no new objects are needed 
—> ﬁnite-state transition system
• N.B.: the technique does not need to know
the value of the bound
108

Is My System State-
Bounded?
• For a ﬁxed k: decidable.
• For “some” bound: undecidable.
• Classes of DB-nets for which state-boundedness is
decidable
• Reasonable for the control layer, not for the data
logic [KR2014,_]
• Sufﬁcient, syntactic conditions [PODS2013,_]
[KR2014,_]
• Methodologies to guarantee state-boundedness by
design [CIKM14,_] [STTT16,_] [FAOC16,_]
110

DB-Nets for Data Benchmarking
• Data management: huge databases required to
test developed techniques
• Data are everywhere, but where are benchmarks?
• Synthetic data do not reﬂect real-world patterns
• Idea: apply CPN simulation techniques on top of
DB-Nets
• Result: synthetic DB indirectly mirroring the
process patterns
111

112
OBDI framework Query answering Ontology languages Mappings Identity Conclusions
Ontology-based data integration framework
. . .
. . .
. . .
. . .
Query
Result
Ontology
provides
global vocabulary
and
conceptual view
Mappings
semantically link
sources and
ontology
Data Sources
external and
heterogeneous
We achieve logical transparency in accessing data:
does not know where and how the data is stored.
can only see a conceptual view of the data.
legacy data sources
conceptual data model
mapping
KAOS Project  
Knowledge-Aware Operational Support
trace, events, attrs… event annotations

. . .
. . .
. . .
. . .
Query
Result
Ontology
provides
global vocabulary
and
conceptual view
Mappings
semantically link
sources and
ontology
Data Sources
external and
heterogeneous
legacy data sources
conceptual data model
mapping
KAOS Project  
Knowledge-Aware Operational Support
trace, events, attrs… event annotations
113
. . .
. . .
. . .
. . .
Query
Result
Ontology
provides
global vocabulary
and
conceptual view
Mappings
semantically link
sources and
ontology
Data Sources
external and
heterogeneous
process
mining

Log Annotations
114
1..*
*
Conference
creation time:DateTime
conf name:String
User
username:String
Paper
title:String
Review Request
invitation time:DateTime
Review
submission time:DateTime
Decision
decision time:DateTime
outcome: Bool
Upload Submitted
upload time:DateTime
Upload Accepted
submitted to
1
*
organizer of
Accepted Paper
<<no time>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 corresponds to
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
event
eventevent
trace: follow has
activity name: “decision”
timestamp: decision time
resource: follow by
type: complete
attributes: outcome
trace: follow has & for
activity name: “review”
timestamp: submission time
resource: follow RhasR & reviewer
type: complete
trace: follow has
activity name: “upload submitted”
timestamp: upload time
resource: follow USuploadbyU
type: complete
trace: follow has & corr. to
activity name: “upload accepted”
resource: follow UAuploadbyU
type: complete
submitted to = BPM 2015

115
1..*
*
Conference
conf name:String
User
username:String
Paper
title:String
Review Request
Review
Decision
outcome: Bool
submitted to
1
*
organizer of
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
1sponds to
sP
1
*1 for
author
1..*
*
by
1
*
creator
1
*
1
UAuploadbyU
1
trace
event
event
trace: follow has
activity name: “decision”
resource: follow by
type: complete
attributes: outcome
trace: follow has & for
resource: follow RhasR & reviewer
type: complete
submitted to = BPM 2015

Multiple Log Views
116
1..*
*
Conference
conf name:String
User
username:String
Paper
title:String
Review Request
Review
Decision
outcome: Bool
Upload Submitted
Upload Accepted
submitted to
1
*
organizer of
Accepted Paper
<<no time>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
trace: follow has author
activity name: “decision author”
resource: follow PhasD
type: complete
event
trace: follow by
activity name: “decision chair”
type: complete
attributes: outcome
event
trace: follow has & reviewer
resource: follow RhasR & for
type: complete
event
trace: follow upload by
activity name: “upload submitted”
resource: follow UhasP
type: complete

117
1..*
*
Conference
conf name:String
User
username:String
Paper
title:String
Review Request
Review
Decision
outcome: Bool
ted
me
ed
me
submitted to
1
*
organizer of
er
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
*
UhasP
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1
UAuploadbyU
1
trace
event
trace: follow has author
activity name: “decision author”
type: complete
event
trace: follow by
activity name: “decision chair”
type: complete
attributes: outcome
event
trace: follow has & reviewer
resource: follow RhasR & for
type: complete

Conclusion
• State-boundedness: a robust condition towards the
effective veriﬁability of such systems
• Complexity: exponential in the “data that can be changed”
• Same formal model for execution and veriﬁcation
119
Marriage between processes and data  
is challenging, but necessary
DB-nets

Acknowledgments
All coauthors of this research,  
in particular  
 
Diego Calvanese (UNIBZ) 
Giuseppe De Giacomo (Sapienza UNIROMA) 
Alin Deutsch (UCSD) 
Marlon Dumas (Uni Tartu) 
Fabio Patrizi (Sapienza UNIROMA) 
Andy Rivkin (UNIBZ)
120

Montali - DB-Nets: On The Marriage of Colored Petri Nets  and Relational Databases

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Montali - DB-Nets: On The Marriage of Colored Petri Nets  and Relational Databases

Semelhante a Montali - DB-Nets: On The Marriage of Colored Petri Nets  and Relational Databases (20)

Mais de Faculty of Computer Science - Free University of Bozen-Bolzano

Mais de Faculty of Computer Science - Free University of Bozen-Bolzano (20)

Último

Último (20)