Upload
marco-montali
View
97
Download
1
Embed Size (px)
Citation preview
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
3
Theory
Practice
Our Research
4
Theory
Practice
Our Approach
5
Business Process Management
Data Management
Conceptual Modeling
Formal Methods
Artificial Intelligence
Dynamic Systems of Interest
• Business processes
• Multiagent systems
• Distributed systems
6
Business Process Lifecycle
7
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
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
11
Data and Processes
12
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
13
Conventional Data ModelingFocus: revelant entities, relations, static constraints
Supplier ManufacturingProcurement/Supplier
Sales
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?
14
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?
15
A Deployed Process
16
Do you like Spaghetti?Manage
CancelationShipAssembleManage
Material POsDecompose
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: difficult to manage, understand, evolve17
Too Late!• Where are the data?
• Where shall we model relevant business rules?
18
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
Sales
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)
19
…There is Hope!20
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
N.B.: these are “sparse” dots!!!
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
21
[PODS98, Abiteboul et al.]
Relational Transducers
[ICDT09, Vianu] Verification 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, _] Verification of data-centric processes
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
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-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
•[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-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
[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…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
DB-NetsCPNs +
databases
[AAAI17, _] RAW-SYS
Workflow nets + databases
One Step Back…
How do contemporary
activity-centric BPMSs account for the
process-data interplay?
26
Example: BizAgi (~)
27
ReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
Case and Persistent DataReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
req info result reimbursement
personal info
28
Persistent Data Engineering
persistent storage29
ReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
req info result reimbursement
personal info
framework data model custom code
Case Data Engineering
persistent storage30
ReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
req info result reimbursement
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
• Explicit control-flow
• Local, case data
• Global, persistent data
• Queries/updates on the persistent data
• External inputs
• Internal generation of fresh IDs33
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
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.
DCDS
Data Layer
Process Layer
external
service
external
service
external
service
Update
Read
• 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
• Explicit control-flow
• Local, case data
• Global, persistent data
• Queries/updates on the persistent data
• External inputs
• Internal generation of fresh IDs35
DATA-CENTRIC DYNAMIC SYSTEMS
~Can be simulated
Marriage
DB-Nets
37
persistence layer
data logic layer
control layer
DB
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
38
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
39
That’s just the relational model!
Example
40
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
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
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+
, 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
i
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
�↵✓
=S
R(~y)2↵·delR(~y)✓; (ii) F
+↵✓
=S
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
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): 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
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-flow
• Evolution of tokens and their “case” data
• Interaction with the persistence layer via the data logic layer
45
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
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
48
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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+
, 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
i
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
�↵✓
=S
R(~y)2↵·delR(~y)✓; (ii) F
+↵✓
=S
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
50
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
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
EmpAndy
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
TicketResp Log
hAndyi
hMarcoi
⌫t = 1emp = Andy
descr = blah
EmpAndy
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Ticket1 blah
RespAndy 1
Log
hMarcoi
EmpAndy
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Ticket1 blah
RespAndy 1
Log
hMarcoi
EmpAndy
Marco
h1, Andyitid = 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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Resp Log
hAndyi
hMarcoi
EmpAndy
Marco
Ticket1 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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Resp Log
hAndyi
hMarcoi
EmpAndy
Marco
Ticket1 blah
h1, blahi
h1, Andyi
⌫t = 5emp = 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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Log
hMarcoi
EmpAndy
Marco
Ticket1 blah
2 blah
h1, blahi
h1, Andyi
RespAndy 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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Log
hMarcoi
EmpAndy
Marco
Ticket1 blah
2 blah
h1, Andyi
RespAndy 2
h2, Andyi
tid = 1emp = Andy
h1, blahih2, 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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Log
hMarcoi
EmpAndy
Marco
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
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Log
hMarcoi
EmpAndy
Marco
Ticket1 blah
2 blah
h1, Andyi
RespAndy 2
Andy 1
h2, Andyi
tid = 1emp = Andy
h1, blahih2, 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
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
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
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
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
Log
hMarcoi
EmpAndy
Marco
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
68
…
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
72
Formal Verification The Conventional, Propositional Case
Process control-flow
(Un)desired property73
(Un)desired property
Finite-statetransition system
Propositionaltemporal formula|= �
Formal Verification The Conventional, Propositional Case
Process control-flow
74
(Un)desired property
Finite-statetransition system
Propositionaltemporal formula|= �
Verification via model checking2007 Turing award:
Clarke, Emerson, Sifakis
Formal Verification The Conventional, Propositional Case
Process control-flow
75
(Un)desired property
Formal Verification The Data-Aware Case
76
Process+Data
(Un)desired property
First-ordertemporal formula|= �
Process+Data
Formal Verification The Data-Aware Case
Infinite-state, relational transition system 77
(Un)desired property
First-ordertemporal formula|= �
?Formal Verification
The Data-Aware Case
78
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
79
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
80
G
✓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
81
G(8s.Student(s) ! F(Retired(s) _Graduated(s))
AG(8o.Order(o) ^ Status(o, open) ! EF(mathitStatus(o, shipped))
Atrue
false
BPMS and Data
Correct?
• BizAgi…
• YAWL…
82
Atrue
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 bisimilar84
…the Bad…
85
…the Bad…
86
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
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
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.
Problem Parameters
90
persistence layer
data logic layer
control layer
DB
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.
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!
91
Our Goal
92
First-ordertemporal formula|= �
Infinite-statetransition system
Our Goal
93
First-ordertemporal formula|= �
Infinite-statetransition system
|= �
Finite-stateabstraction
Propositionaltemporal formula
‘
Our Goal
94
First-ordertemporal formula|= �
Infinite-statetransition system
|= � 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
95
Effect of state-boundedness
96
General State-bounded
μLa undecidable
LTL-FOa undecidable
Effect of state-boundedness
97
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
LTL-FOa undecidable undecidable
Effect of state-boundedness
98
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
LTL-FOa undecidable undecidable
Reason? FO quantification
across states.
Effect of state-boundedness
99
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
LTL-FOa undecidable undecidable
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
. . .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
µL
µLP
µLA
µLFO
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)))
100
Effect of Persistent Quantification
101
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
μLp
LTL-FOa undecidable undecidable
LTL-FOp
Effect of Persistent Quantification
102
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
μLp undecidable
LTL-FOa undecidable undecidable
LTL-FOp undecidable
Effect of Persistent Quantification
103
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
μLp undecidabledecidable
formula-independent abstraction!
LTL-FOa undecidable undecidable
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
104
Example• External Input: single (new?) value • Current state: two objects (in DB and/or marking)
a,babc
de
105
Example
a,babc
106
• 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!
107
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
108
Recap
109
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
112
OBDI framework Query answering Ontology languages Mappings Identity Conclusions
Ontology-based data integration framework
. . .
. . .
. . .
. . .
Query
Result
Ontologyprovides
global vocabulary
and
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
OBDI framework Query answering Ontology languages Mappings Identity Conclusions
Ontology-based data integration framework
. . .
. . .
. . .
. . .
Query
Result
Ontologyprovides
global vocabulary
and
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
113
OBDI framework Query answering Ontology languages Mappings Identity Conclusions
Ontology-based data integration framework
. . .
. . .
. . .
. . .
Query
Result
Ontologyprovides
global vocabulary
and
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)
processmining
Log Annotations
114
1..*
*
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
1
*
organizerof
AcceptedPaper<<notime>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 correspondsto
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
event
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
115
1..*
*
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
1
*
organizerof
AcceptedPaper<<notime>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 correspondsto
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
event
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
116
1..*
*
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
1
*
organizerof
AcceptedPaper<<notime>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 correspondsto
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
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
117
1..*
*
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
1
*
organizerof
AcceptedPaper<<notime>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 correspondsto
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
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
118
Conclusion
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
119
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)
120