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 datais extremely difficult….

… but is a must if we want to really understand

how complex dynamic systems operate.2

Our Research

Theory

Practice

Our Research

Theory

Practice

Our Approach

Business Process Management

Data Management

Conceptual Modeling

Formal Methods

Artificial Intelligence

Dynamic Systems of Interest

• Business processes

• Multiagent systems

• Distributed systems

Business Process Lifecycle

picture by Wil van der Aalst

Formal Verification

Automated analysis of a formal model of the system

against a property of interest, considering all possible system behaviors

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?

Two Questions

• How to formally and conceptually account for the process+data interplay in conventional, activity-centric BP models?

• How to verify such BPMs?

Business Turing Machines

Data and Processes

ReviewRequest

Fill Reim-bursement

Review Reim-bursement

Rejected

Accepted

decision-making action

footprint

Is this Synergy Reflected 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

Conventional Data ModelingFocus: revelant entities, relations, static constraints

Supplier ManufacturingProcurement/Supplier

Customer PO Line Item

Work OrderMaterial PO

spawns0..1

Material

But… how do data evolve? Where can we find the “state” of a purchase order?

Conventional Process ModelingFocus: control-flow of activities in response to events

But… how do activities update data? What is the impact of canceling an order?

A Deployed Process

Do you like Spaghetti?Manage

CancelationShipAssembleManage

Material POsDecompose

Customer PO

Activities

Process

Activities

Process

Activities

Process

Activities

Process

Activities

Process

Customers Suppliers&CataloguesCustomer POs Work Orders Material POs

IT integration: difficult to manage, understand, evolve17

Too Late!• Where are the data?

• Where shall we model relevant business rules?

Too 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

Customer PO Line Item

Work OrderMaterial PO

spawns0..1

Determine cancelation

penaltyNotify penalty

Material

Process Engine

Process State

Business rulesFor each work order W For each material PO M in W if M has been shipped add returnCost(M) to penalty

Diego Calvanese (FUB) Foundations of Data-Aware Process Analysis INRIA Saclay Paris – 18/3/2016 (10/1)

…There is Hope!20

data-centric…

activity-centric1998

…2003

N.B.: these are “sparse” dots!!!

data-centric…

…2003

[PODS98, Abiteboul et al.]

Relational Transducers

[ICDT09, Vianu] Verification of artifact-centric

processes

[ICDT05, Vardi] Model checking

for database theoreticians

[ECAI12, _] Knowledge and action

[PODS13, _] Data-Centric

Dynamic Systems

[STTT16, _] Case-centric

[PODS13, _] Verification of data-centric processes

data-centric…

…2003

[IBM J.,Nigam and Caswell] Business Artifacts

[OTM08, Hull] Survey on

business artifacts

[WSFM10, Hull et al.] First paper on IBM

First draft of OMG CMMN

Start of the EU Project

data-centric…

…2003

•[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 •

data-centric…

…2003

[ICATPN07, Lazic et al.]

Data nets

[CAiSE10, Sidorova et al.]

Conceptual nets

[TCS11, Rosa-Velardo and de Frutos-Escrig]

ν-PNs (nets managing names)

[FAOC16, _] Verification of

PNs with names

[PN16, Lasota] Survey on PNs

with data

[PN15, Triebel and Sürmeli]

Algebraic PNs

data-centric…

…2003

DB-NetsCPNs +

databases

[AAAI17, _] RAW-SYS

Workflow nets + databases

One Step Back…

How do contemporary

activity-centric BPMSs account for the

process-data interplay?

Example: BizAgi (~)

ReviewRequest

Fill Reim-bursement

Rejected

Accepted

Case and Persistent DataReviewRequest

Fill Reim-bursement

Rejected

Accepted

req info result reimbursement

personal info

Persistent Data Engineering

persistent storage29

ReviewRequest

Fill Reim-bursement

Rejected

Accepted

personal info

framework data model custom code

Case Data Engineering

persistent storage30

ReviewRequest

Fill Reim-bursement

Rejected

Accepted

personal info

framework data model custom code

user forms

external services

Recipe

• Explicit control-flow

• Local, case data

• Global, persistent data

• Queries/updates on the persistent data

• External inputs

• Internal generation of fresh IDs31

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

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

unibz.itunibz.it

IntroductionData-Centric Dynamic Systems (DCDSs)An abstract, pristine framework to formally describe processes that manipulatedata.

• Captures virtually all existing approaches to data-aware processes, such asthe artifact-centric paradigm.

Data Layer

Process Layer

external

service

external

service

external

service

Update

• Data layer: relational database (with constraints).• Process layer: condition-action rules (include service calls that input new

data).

Marco Montali Verification of Relational DCDSs PODS 2013 3 / 25

Recipe

• External inputs

DATA-CENTRIC DYNAMIC SYSTEMS

~Can be simulated

Marriage

DB-Nets

persistence layer

data logic layer

control layer

ActionsQueries

View places Places Transitions

fetch update

populate trigger

ArcsRead arcsRollback arcs

Fig. 1. The conceptual components of db-nets

it employs workflow nets [1] for capturing the process control flow, without lever-aging the advanced capabilities of CPNs. Taking inspiration from [15], we thenpropose db-nets, a new, balanced formal model for data-aware processes, rootedin CPNs and relational databases. We rigorously describe the abstractions of-fered by the model, and formalize its execution semantics. We finally invite theresearch community to build on this new model, discussing its potential alongthree subjects: modeling, verification, and simulation.

2 The DB-Net Model

In our formal model, called db-net, we combine the distinctive features of CPNsand relational databases into a coherent framework, sketched in Figure 1. Themodel is structured in three layers:• persistence layer, capturing a full-fledged relational database with constraints,and used to store background data, and data that are persistent across cases.

• control layer, employing a variant of CPNs to capture the process control-flow,case data, and possibly the resources involved in the process execution.

• data logic layer, interconnecting in the persistence and the control layer.Thanks to the data logic, the control layer is supported in querying the un-derlying persistent data and tunes its own behavior depending on the obtainedanswers. Furthermore, the data logic may be exploited by the control layer to up-date the persistent data depending on the current state, the data locally carriedby tokens, and additional data obtained from the external world. We formalizethe framework layer by layer, from the bottom to the top.

2.1 Persistence Layer

The persistence layer maintains the relevant data in the domain of interest. Tothis end, we rely on standard relational databases equipped with constraints,in the spirit of [9]. First-order (FO) constraints allow for the formalization ofconventional database constraints, such as keys and functional dependencies, aswell as semantic constraints reflecting the domain of interest. Di↵erently from[9], though, we also consider data types, on the one hand resembling concretelogical schemas of relational databases (where table columns are typed), and onthe other reconciling the persistence layer with the notion of “color” in CPNs.

joint proposal with Andy Rivkin

Persistence LayerTyped relational DB with constraints • DB: set of relation schemas with typed components • Type: data domain with rigidly defined predicates • Constraints: Domain-independent FO sentences

• Keys, FKs, dependencies, multiplicities, … DB Instance: finite set of typed facts over DB, satisfying all constraints

Persistence LayerTyped relational DB with constraints • DB: set of relation schemas with typed components • Type: data domain with rigidly defined predicates • Constraints: Domain-independent FO sentences

• Keys, FKs, dependencies, multiplicities, … DB Instance: finite set of typed facts over DB, satisfying all constraints

That’s just the relational model!

Example

Empname: string

Ticketid: int descr: string

Respemp: string ticket: int

Each employee can handle at most one ticket at a given time

Logticket: int emp: string descr: string

Data LogicBidirectional interface for interacting with a DB instance of the persistence layer

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

To query the database instance, we use FO(D) queries as in Definition 5. Toupdate the database instance, we instead resort to the literature on data-centricprocesses [33, 11], where actions are typically used to apply CRUD (create-read-update-delete) operations over a relational database. Specifically, we adopt aminimalistic approach, keeping the actions as simple as possible. The approachis inspired by the well-known STRIPS language for planning, which has beenadopted also in for data-centric processes [5]. More sophisticated forms of actions,as those in [9], can be seamlessly introduced.

Definition 12 (Action). A (parameterized) action over a D-typed persistencelayer hR, Ei is tuple hn, ~p, F+

�i, where: (i) n is the action name; (ii) ~p is atuple of pairwise distinct typed variables from VD, denoting the action (formal)parameters. (iii) F

+ and F

� respectively represent a finite set of R-facts over~p, to be added to and deleted from the current database instance. Given a typedrelation R(D1, . . . ,Dn

) 2 R, an R-fact over ~p has the form R(y1, . . . , yn), suchthat for every i 2 {1, . . . , n}, y

is either a value o 2 �Di , or a variable x 2 ~p

with type(x) = Di

. An R-fact is an R-fact for some relation R from R. ⇤

To access the di↵erent components of an action ↵ = hn, ~p, F+, F

�i, we use a dotnotation: ↵·name = n, ↵·params = ~p, ↵·add = F

+, and ↵·del = F

�.We now turn to the semantics of actions. Actions are executed by grounding

their parameters to values. Given an action ↵ and a (parameter) substitution✓ for ↵, we call action instance ↵✓ the (ground) action resulting from ↵ bysubstituting its parameters with corresponding values, as specified by ✓.

Definition 13 (Action instance application). Let P = hR, Ei be aD-typedpersistence layer, I be a D-typed database instance I compliant with D, ↵ be anaction over P, and ✓ be a substitution for action·params. The application of ↵✓ onI, written apply(↵✓, I), is a database instance overR obtained as (I\F�

↵✓

)[F+↵✓

,where: (i) F

�↵✓

R(~y)2↵·delR(~y)✓; (ii) F

+↵✓

R(~y)2↵·addR(~y)✓. We say that↵✓ can be successfully applied to I if apply(↵✓, I) complies with P. ⇤

The application of an action instance amounts to ground all the facts containedin the definition of the action as specified by the given substitution, then ap-plying the update on the given database instance, giving priority to additionsover deletions (this is a standard approach, which unambiguously handles thesituation in which the same fact is asserted to be added and deleted).

The data logic simply exposes a set of queries and a set of actions that canbe used by the control layer to obtain data from the persistence layer, and toinduce updates on the persistence layer.

Definition 14 (Data logic layer). Given a D-typed persistence layer P, a D-typed data logic layer over P is a pair hQ,Ai, where: (i) Q is a finite set of FO(D)queries over P; (ii) A is a finite set of actions over P. ⇤

Example 2. We make the scenario of Example 1 operational, introducing a data logiclayer L over P. L exposes two queries to inspect the persistence layer:• Qe(e):-Emp(e) ^ ¬9t.Resp(e, t), to extract idle employees;

• Qt(t, d):-Ticket(t, d), to extract tickets and their description.In addition, L provides three main functionalities to manipulate tickets in persistencelayer: ticket registration, assignment/release, and logging. Such functionalities are re-alized through four actions (where, for simplicity, we blur the distinction between anaction and its name). The registration of a new ticket is managed by an action reg

that, given an integer t, and two strings e and d, (reg·params = ht , e, di, simultane-ously creates a ticket identified by t and described by d into the persistence layer, andassigns the employee identified by e to such ticket (thus making her busy):

reg·del = {Emp(e, idle)} reg·add = {Ticket(t , d),Resp(e, t)}

Two specular actions assign and release are exposed to assign or release a ticketto/from an employee, making her busy or idle. Both actions take as input a string forthe employee name and an integer for a ticket it (assign·params = release·params =he, ti), and update e by removing or adding that e is responsible of t:

release·del = assign·add = {Resp(e, t)} release·add = assign·del = ;

Finally, an action log with log·params = ht , e, di is exposed to flush the informationrelated to a ticket into a log table. The action erases all information about the ticket,and logs that it has been processed, also recalling its employee and description:

log·del = {Ticket(t , d),Resp(e, t)} log·add = {Log(t , e, d)}

2.3 Control Layer

The control layer employs a variant of CPNs to capture the process control flow,and how it interacts with an underlying persistence layer through the function-alities provided by the idata logic. The spirit is to conceptually ground CPNsby adopting a data-oriented approach. This is done by introducing dedicatedconstructs exploiting such functionalities, as well as simple, declarative patternsto capture the typical token consumption/creation mechanism of CPNs.

Before introducing the di↵erent constitutive elements of the control layertogether with their graphical appearance, we fix some preliminary notions. Weconsider the standard notion of amultiset. Given a set A, the set of multisets overA, written A

�, is the set of mappings of the form m : A ! N. Given a multisetS 2 A

� and an element a 2 A, S(a) 2 N denotes the number of times a appearsin S. Given a 2 A and n 2 N, we write a

n 2 S if S(a) = n. We also consider theusual operations on multisets. Given S1, S2 2 A

�: (i) S1 ✓ S2 (resp., S1 ⇢ S2)if S1(a) S2(a) (resp., S1(a) < S2(a)) for each a 2 A; (ii) S1 + S2 = {an |a 2 A and n = S1(a) + S2(a)}; (iii) if S1 ✓ S2, S2 � S1 = {an | a 2 A and n =S2(a)� S1(a)}; (iv) given a number k 2 N, k · S1 = {akn | an 2 S1}.2

Places. The control layer contains a finite set P of places, which in turn areclassified in two groups. On the one hand, so-called control places play the roleof standard places in classical Petri nets: they represent conditions/states of adynamic system. On the other hand, so-called view places are used as an interface

2 Hence, given a multiset S, we have 0 · S = ;.

• 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): flush and log the info related to ticket t• Del Ticket(t,d), Resp(e,t) • Add Log(t,e,d)

Example: Actions

• 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): flush 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

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-flow

• Evolution of tokens and their “case” data

• Interaction with the persistence layer via the data logic layer

PlaceColored 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

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

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

h⌫t, empi htid, empi htid, empi

htid, empi

htid, descri

Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.

Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled

Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application

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 identifies where the control layer needs to

“read” from the persistence layer • Not modified explicitly by the control layer • Implicitly updated by applying actions on the

persistence layer, and recomputing the view

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Example

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

int int⇥ string int⇥ string

To query the database instance, we use FO(D) queries as in Definition 5. Toupdate the database instance, we instead resort to the literature on data-centricprocesses [33, 11], where actions are typically used to apply CRUD (create-read-update-delete) operations over a relational database. Specifically, we adopt aminimalistic approach, keeping the actions as simple as possible. The approachis inspired by the well-known STRIPS language for planning, which has beenadopted also in for data-centric processes [5]. More sophisticated forms of actions,as those in [9], can be seamlessly introduced.

Definition 12 (Action). A (parameterized) action over a D-typed persistencelayer hR, Ei is tuple hn, ~p, F+

�i, where: (i) n is the action name; (ii) ~p is atuple of pairwise distinct typed variables from VD, denoting the action (formal)parameters. (iii) F

+ and F

� respectively represent a finite set of R-facts over~p, to be added to and deleted from the current database instance. Given a typedrelation R(D1, . . . ,Dn

) 2 R, an R-fact over ~p has the form R(y1, . . . , yn), suchthat for every i 2 {1, . . . , n}, y

is either a value o 2 �Di , or a variable x 2 ~p

with type(x) = Di

. An R-fact is an R-fact for some relation R from R. ⇤

To access the di↵erent components of an action ↵ = hn, ~p, F+, F

�i, we use a dotnotation: ↵·name = n, ↵·params = ~p, ↵·add = F

+, and ↵·del = F

�.We now turn to the semantics of actions. Actions are executed by grounding

their parameters to values. Given an action ↵ and a (parameter) substitution✓ for ↵, we call action instance ↵✓ the (ground) action resulting from ↵ bysubstituting its parameters with corresponding values, as specified by ✓.

Definition 13 (Action instance application). Let P = hR, Ei be aD-typedpersistence layer, I be a D-typed database instance I compliant with D, ↵ be anaction over P, and ✓ be a substitution for action·params. The application of ↵✓ onI, written apply(↵✓, I), is a database instance overR obtained as (I\F�

↵✓

)[F+↵✓

,where: (i) F

�↵✓

R(~y)2↵·delR(~y)✓; (ii) F

+↵✓

R(~y)2↵·addR(~y)✓. We say that↵✓ can be successfully applied to I if apply(↵✓, I) complies with P. ⇤

The application of an action instance amounts to ground all the facts containedin the definition of the action as specified by the given substitution, then ap-plying the update on the given database instance, giving priority to additionsover deletions (this is a standard approach, which unambiguously handles thesituation in which the same fact is asserted to be added and deleted).

The data logic simply exposes a set of queries and a set of actions that canbe used by the control layer to obtain data from the persistence layer, and toinduce updates on the persistence layer.

Definition 14 (Data logic layer). Given a D-typed persistence layer P, a D-typed data logic layer over P is a pair hQ,Ai, where: (i) Q is a finite set of FO(D)queries over P; (ii) A is a finite set of actions over P. ⇤

Example 2. We make the scenario of Example 1 operational, introducing a data logiclayer L over P. L exposes two queries to inspect the persistence layer:• Qe(e):-Emp(e) ^ ¬9t.Resp(e, t), to extract idle employees;• Qt(t, d):-Ticket(t, d), to extract tickets and their description.

In addition, L provides three main functionalities to manipulate tickets in persistencelayer: ticket registration, assignment/release, and logging. Such functionalities are re-alized through four actions (where, for simplicity, we blur the distinction between anaction and its name). The registration of a new ticket is managed by an action reg

that, given an integer t, and two strings e and d, (reg·params = ht , e, di, simultane-ously creates a ticket identified by t and described by d into the persistence layer, andassigns the employee identified by e to such ticket (thus making her busy):

reg·del = {Emp(e, idle)} reg·add = {Ticket(t , d),Resp(e, t)}

Two specular actions assign and release are exposed to assign or release a ticketto/from an employee, making her busy or idle. Both actions take as input a string forthe employee name and an integer for a ticket it (assign·params = release·params =he, ti), and update e by removing or adding that e is responsible of t:

release·del = assign·add = {Resp(e, t)} release·add = assign·del = ;

Finally, an action log with log·params = ht , e, di is exposed to flush the informationrelated to a ticket into a log table. The action erases all information about the ticket,and logs that it has been processed, also recalling its employee and description:

log·del = {Ticket(t , d),Resp(e, t)} log·add = {Log(t , e, d)}

2.3 Control Layer

The control layer employs a variant of CPNs to capture the process control flow,and how it interacts with an underlying persistence layer through the function-alities provided by the idata logic. The spirit is to conceptually ground CPNsby adopting a data-oriented approach. This is done by introducing dedicatedconstructs exploiting such functionalities, as well as simple, declarative patternsto capture the typical token consumption/creation mechanism of CPNs.

Before introducing the di↵erent constitutive elements of the control layertogether with their graphical appearance, we fix some preliminary notions. Weconsider the standard notion of amultiset. Given a set A, the set of multisets overA, written A

�, is the set of mappings of the form m : A ! N. Given a multisetS 2 A

� and an element a 2 A, S(a) 2 N denotes the number of times a appearsin S. Given a 2 A and n 2 N, we write a

n 2 S if S(a) = n. We also consider theusual operations on multisets. Given S1, S2 2 A

�: (i) S1 ✓ S2 (resp., S1 ⇢ S2)if S1(a) S2(a) (resp., S1(a) < S2(a)) for each a 2 A; (ii) S1 + S2 = {an |a 2 A and n = S1(a) + S2(a)}; (iii) if S1 ✓ S2, S2 � S1 = {an | a 2 A and n =S2(a)� S1(a)}; (iv) given a number k 2 N, k · S1 = {akn | an 2 S1}.2

Places. The control layer contains a finite set P of places, which in turn areclassified in two groups. On the one hand, so-called control places play the roleof standard places in classical Petri nets: they represent conditions/states of adynamic system. On the other hand, so-called view places are used as an interface

2 Hence, given a multiset S, we have 0 · S = ;.

Case variables: - ticket id - name of responsible employee

int⇥ string

TransitionAtomic 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

TransitionAtomic 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

Example

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Example

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Example

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

EmpAndy

TicketResp Log

hAndyi

hMarcoi

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

TicketResp Log

hAndyi

hMarcoi

⌫t = 1emp = Andy

descr = blah

EmpAndy

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Ticket1 blah

RespAndy 1

hMarcoi

EmpAndy

h1, Andyi

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Ticket1 blah

RespAndy 1

hMarcoi

EmpAndy

h1, Andyitid = 1

emp = Andy

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Resp Log

hAndyi

hMarcoi

EmpAndy

Ticket1 blah

h1, blahi

h1, Andyi

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Resp Log

hAndyi

hMarcoi

EmpAndy

Ticket1 blah

h1, blahi

h1, Andyi

⌫t = 5emp = Andy

descr = blah

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

hMarcoi

EmpAndy

Ticket1 blah

2 blah

h1, blahi

h1, Andyi

RespAndy 2

h2, Andyi

h2, blahi

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

hMarcoi

EmpAndy

Ticket1 blah

2 blah

h1, Andyi

RespAndy 2

h2, Andyi

tid = 1emp = Andy

h1, blahih2, blahi

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

hMarcoi

EmpAndy

Ticket1 blah

2 blah

h1, Andyi

RespAndy 2

Andy 1

h2, Andyi

tid = 1emp = Andy

h1, blahih2, blahi

Rollback FlowAccounts 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

Example: “Undo”

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

hMarcoi

EmpAndy

Ticket1 blah

2 blah

h1, Andyi

RespAndy 2

Andy 1

h2, Andyi

tid = 1emp = Andy

h1, blahih2, blahi

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

pihtid, empi

htid, descri

Idle Employees

register

(⌫t, emp, descr)

CreateTicket

Active tickets

release

(tid, emp)

assign

(tid, emp)

Stalled tickets

logData

(tid, emp, id)

ResolveTickets

htid, empi

htid, descri

hMarcoi

EmpAndy

Ticket1 blah

2 blah

h1, Andyi

RespAndy 2

h2, Andyi

tid = 1emp = Andy

h1, blahih2, blahi

Execution SemanticsInfinite-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

Sources of Infinity

69……

………

……

……… …

Fixed initial snapshot

Sources of Infinity

70……

………

……

……… …

Infinite-branching due to external inputs and new id generation

Sources of Infinity

71……

………

……

……… …

Runs visiting infinitely many DBs/markings due to usage of external data

Formal Verification The Conventional, Propositional Case

Process control-flow

(Un)desired property73

(Un)desired property

Finite-statetransition system

Propositionaltemporal formula|= �

Finite-statetransition system

Propositionaltemporal formula|= �

Verification via model checking2007 Turing award:

Clarke, Emerson, Sifakis

Formal Verification The Data-Aware Case

Process+Data

First-ordertemporal formula|= �

Process+Data

Formal Verification The Data-Aware Case

Infinite-state, relational transition system 77

?Formal Verification

The Data-Aware Case

Process+Data

Infinite-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

quantification across states • Example:

It is always the case that every order is eventually either cancelled or paid

Why FO Temporal Logics• To inspect data: FO queries• To capture system dynamics: temporal

modalities• To track the evolution of objects: FO

quantification across states • Example:

It is always the case that every order is eventually either cancelled or paid

✓8x.Order(x)

! F�State(x, cancelled) _ State(x, paid)

�◆

Which logics?• First-order temporal logics with active domain

quantification

• Branching-time: μLa

• Linear-time: LTL-FOa

• Only initial constants can explicitly appear in the formulae

• Corresponding notions of bisimulation/trace equivalence

G(8s.Student(s) ! F(Retired(s) _Graduated(s))

AG(8o.Order(o) ^ Status(o, open) ! EF(mathitStatus(o, shipped))

BPMS and Data

Correct?

• BizAgi…

• YAWL…

BPMS and Data

Correct?

• BizAgi… not sure…

• YAWL… YES!

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 bisimilar84

…the Bad…

Persistence layer

Control layer (without colors)

Data logic layer

…and the UglySimulation 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

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

Problem Parameters

persistence layer

data logic layer

control layer

ActionsQueries

fetch update

populate trigger

2 The DB-Net Model

Problem Parameters

persistence layer

data logic layer

control layer

ActionsQueries

fetch update

populate trigger

2 The DB-Net Model

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

• Infinitely many cases may appear in the life of the system, but only boundedly many coexist• Resources!

Our Goal

Infinite-statetransition system

Our Goal

|= �

Finite-stateabstraction

Propositionaltemporal formula

Our Goal

|= � Propositionaltemporal formula

‘If and only if

Finite-stateabstraction

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

Effect of state-boundedness

General State-bounded

μLa undecidable

LTL-FOa undecidable

μLa undecidabledecidable

abstraction must depend on the formula!

LTL-FOa undecidable undecidable

Reason? FO quantification

across states.

Logic unable to isolate single runs/computations

Logics with Persistent Quantification

• 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

unibz.itunibz.it

Persistence-Preserving µ-calculus (µLP

)In some cases, objects maintain their identity only if they persist in theactive domain (cf. business artifacts and their IDs).

. . .StudId : 123

. . .dismiss(123) newStud()ID() = 123

µLP restricts µLA to quantification over persistingobjects only, i.e., objects that continue to be live.

÷x.� ; ÷x.live(x) · �È≠Í�(x̨) ; live(x̨) · È≠Í�(x̨)[≠]�(x̨) ; live(x̨) · [≠]�(x̨) PDLLTL CTL

Example (“weak persistence”)‹X .(’x.live(x) · Stud(x) æ

µY .(÷y.live(y) · Grad(x, y) ‚ (live(x) æ È≠ÍY )) · [≠]X)Along every path, it is always true, for each student x, that there exists anevolution in which either x does not persist, or she eventually graduates.

Marco Montali Verification of Relational DCDSs PODS 2013 12 / 25

G(8s.Student(s) ! Student(s)U(Retired(s) _Graduated(s)))

Effect of Persistent Quantification

LTL-FOp

μLp undecidable

LTL-FOp undecidable

μLp undecidabledecidable

formula-independent abstraction!

LTL-FOp undecidabledecidable

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

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

a,babc

Example

a,babc

• External Input: single (new?) value • Current state: two objects (in DB and/or marking)

Compacting Infinite Runs• Key observation: due to persistent quantification, 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!

Compacting Infinite Runs

• [Calvanese et al, 2013]: if the system is size-bounded, the recycling technique reaches a point were no new objects are needed—> finite-state transition system

• N.B.: the technique does not need to know the value of the bound

Prune Recycle

Is My System State-Bounded?

• For a fixed 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,_] • Sufficient, 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 reflect real-world patterns

• Idea: apply CPN simulation techniques on top of DB-Nets • Result: synthetic DB indirectly mirroring the

process patterns111

OBDI framework Query answering Ontology languages Mappings Identity Conclusions

Ontology-based data integration framework

Result

Ontologyprovides

global vocabulary

conceptual view

Mappingssemantically link

sources and

ontology

Data Sourcesexternal 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.

Diego Calvanese (FUB) Ontologies for Data Integration FOfAI 2015, Buenos Aires – 27/7/2015 (7/52)

legacy data sources

conceptual data model

mapping

KAOS Project Knowledge-Aware Operational Support

trace, events, attrs… event annotations

Result

Ontologyprovides

global vocabulary

conceptual view

sources and

ontology

heterogeneous

legacy data sources

conceptual data model

mapping

KAOS Project Knowledge-Aware Operational Support

trace, events, attrs… event annotations

Result

Ontologyprovides

global vocabulary

conceptual view

sources and

ontology

heterogeneous

processmining

Log Annotations

Conferencecreationtime:DateTime

confname:String

Usercreationtime:DateTime

username:String

Papercreationtime:DateTime

title:String

ReviewRequestinvitationtime:DateTime

Reviewsubmissiontime:DateTime

Decisiondecisiontime:DateTime

outcome:Bool

UploadSubmitteduploadtime:DateTime

UploadAccepteduploadtime:DateTime

submittedto

organizerof

AcceptedPaper<<notime>>

reviewer

10..1 correspondsto

*1 for

author

USuploadbyU

creator

UAuploadbyU

eventevent

trace:followhasactivityname:“decision”timestamp:decisiontime

resource:followbytype:complete

attributes:outcome

trace:followhas&foractivityname:“review”

timestamp:submissiontimeresource:followRhasR&reviewer

type:complete

trace:followhasactivityname:“uploadsubmitted”

timestamp:uploadtimeresource:followUSuploadbyU

type:complete

trace:followhas&corr.toactivityname:“uploadaccepted”

timestamp:uploadtimeresource:followUAuploadbyU

type:complete

submittedto=BPM2015

confname:String

username:String

title:String

outcome:Bool

submittedto

organizerof

reviewer

10..1 correspondsto

*1 for

author

USuploadbyU

creator

UAuploadbyU

eventevent

trace:followhasactivityname:“decision”timestamp:decisiontime

resource:followbytype:complete

attributes:outcome

trace:followhas&foractivityname:“review”

timestamp:submissiontimeresource:followRhasR&reviewer

type:complete

trace:followhasactivityname:“uploadsubmitted”

timestamp:uploadtimeresource:followUSuploadbyU

type:complete

trace:followhas&corr.toactivityname:“uploadaccepted”

timestamp:uploadtimeresource:followUAuploadbyU

type:complete

submittedto=BPM2015

Multiple Log Views

confname:String

username:String

title:String

outcome:Bool

submittedto

organizerof

reviewer

10..1 correspondsto

*1 for

author

USuploadbyU

creator

UAuploadbyU

trace:followhasauthoractivityname:“decisionauthor”

timestamp:decisiontimeresource:followPhasD

type:complete

eventtrace:followby

activityname:“decisionchair”timestamp:decisiontimeresource:followPhasD

type:completeattributes:outcome

eventtrace:followhas&revieweractivityname:“review”

timestamp:submissiontimeresource:followRhasR&for

type:complete

eventtrace:followuploadby

activityname:“uploadsubmitted”timestamp:uploadtimeresource:followUhasP

type:complete

confname:String

username:String

title:String

outcome:Bool

submittedto

organizerof

reviewer

10..1 correspondsto

*1 for

author

USuploadbyU

creator

UAuploadbyU

trace:followhasauthoractivityname:“decisionauthor”

timestamp:decisiontimeresource:followPhasD

type:complete

eventtrace:followby

activityname:“decisionchair”timestamp:decisiontimeresource:followPhasD

type:completeattributes:outcome

eventtrace:followhas&revieweractivityname:“review”

timestamp:submissiontimeresource:followRhasR&for

type:complete

eventtrace:followuploadby

activityname:“uploadsubmitted”timestamp:uploadtimeresource:followUhasP

type:complete

Conclusion

• State-boundedness: a robust condition towards the effective verifiability of such systems

• Complexity: exponential in the “data that can be changed” • Same formal model for execution and verification

Marriage between processes and data is challenging, but necessary

DB-nets

AcknowledgmentsAll 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)

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

Presentations & Public Speaking

Stochastic Petri nets

Stochastic Petri nets - unipi.it

Petri Nets and Model Checking - Universitetet i oslo · Petri Nets and Model Checking Natasa Gkol Petri Nets Petri Nets : I mathematically founded formalism I concurrency I synchronization

1 Petri nets Classical Petri nets: The basic model

Modeling with Petri Nets

Petri Nets 2000 - tidsskrift.dk

Hardware and Petri nets Performance analysis of asynchronous circuits using Petri nets

24 Petri Nets - edisciplinas.usp.br

Coloured Petri Nets

Generalized Stochastic Petri Nets

Petri Nets:

Hardware and Petri nets

Introduction to Petri Nets

Elementary Petri Nets - cas.mcmaster.ca

arXiv:1611.03680v1 [cs.DB] 11 Nov 2016 · DB-Nets:on TheMarriage of Colored Petri Nets andRelational Databases Marco Montali and Andrey Rivkin Free University of Bozen-Bolzano, Piazza

Petri Nets Peterson

1 Petri Nets Ina Koch and Monika Heiner. 2 Petri Nets(1962) Carl Adam Petri

Haskell-Coloured Petri Nets

Petri Nets 2000

FLUID STOCHASTIC PETRI NETS: THEORY, APPLICATIONS… · FLUID STOCHASTIC PETRI NETS: THEORY, APPLICATIONS, AND SOLUTION ... Fluid Stochastic Petri Nets: Theory, Applications,