Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

317 views

Published on

Invited Presentation on "DB-Nets: On The Marriage of Colored Petri Nets 
and Relational Databases" at the SOAMED 2016 Winter Retreat, 28-29/11/2016, Zeuthen (Berlin), Germany

  • Be the first to comment

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

  1. 1. On The Marriage of Colored Petri Nets 
 and Relational Databases Marco Montali Free University of Bozen-Bolzano SOAMED 2016 DB-Nets
  2. 2. Marrying processes and data
 is extremely difficult…. … but is a must 
 if we want to really understand 
 how complex dynamic systems operate. 2
  3. 3. Our Research 3 Theory Practice
  4. 4. Our Research 4 Theory Practice
  5. 5. Our Approach 5 Business Process Management Data Management Conceptual Modeling Formal Methods Artificial Intelligence
  6. 6. Dynamic Systems of Interest • Business processes • Multiagent systems • Distributed systems 6
  7. 7. Business Process Lifecycle 7 picture by Wil van der Aalst
  8. 8. 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
  9. 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? 9
  10. 10. 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. 11. 11
  12. 12. Data and Processes 12 Review Request Fill Reim- bursement Review Reim- bursement Rejected Accepted decision- making action footprint
  13. 13. 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
  14. 14. Conventional Data Modeling Focus: revelant entities, relations, static constraints Supplier ManufacturingProcurement/Supplier Sales Customer PO Line Item Work OrderMaterial PO * * spawns 0..1 Material But… how do data evolve? Where can we find the “state” of a purchase order? 14
  15. 15. Conventional Process Modeling Focus: control-flow of activities in response to events But… how do activities update data? What is the impact of canceling an order? 15
  16. 16. A Deployed Process 16
  17. 17. Do you like Spaghetti? Manage Cancelation ShipAssemble Manage Material POs Decompose Customer PO Activities Process Data Activities Process Data Activities Process Data Activities Process Data Activities Process Data Customers Suppliers&CataloguesCustomer POs Work Orders Material POs IT integration: difficult to manage, understand, evolve 17
  18. 18. Too Late! • Where are the data? • Where shall we model relevant business rules? 18 o late to reconstruct the missing pieces Where is our data? part is in the DBs, part is hidden in the process execution engine. Where are the relevant business rules, and how are they modeled? At the DB level? Which DB? How to import the process data? (Also) in the business model? How to import data from the DBs? DataProcess Supplier ManufacturingProcurement/Supplier Sales Customer PO Line Item Work OrderMaterial PO * * spawns 0..1 Determine cancelation penalty Notify penalty Material Process Engine Process State Business rules For each work order W For each material PO M in W if M has been shipped add returnCost(M) to penalty
  19. 19. 19
  20. 20. …There is Hope! 20 data-centric … … … activity-centric 1 9 9 8 … 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7 2 0 0 8 2 0 0 9 2 0 1 0 2 0 1 1 2 0 1 2 2 0 1 3 2 0 1 4 2 0 1 5 2 0 1 6 N.B.: these are “sparse” dots!!!
  21. 21. data-centric … … … activity-centric 1 9 9 8 … 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7 2 0 0 8 2 0 0 9 2 0 1 0 2 0 1 1 2 0 1 2 2 0 1 3 2 0 1 4 2 0 1 5 2 0 1 6 21 [PODS98, Abiteboul et al.] Relational Transducers [ICDT09, Vianu] 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
  22. 22. data-centric … … … activity-centric 1 9 9 8 … 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7 2 0 0 8 2 0 0 9 2 0 1 0 2 0 1 1 2 0 1 2 2 0 1 3 2 0 1 4 2 0 1 5 2 0 1 6 22 [IBM J.,Nigam and Caswell] Business Artifacts [OTM08, Hull] Survey on business artifacts [WSFM10, Hull et al.] First paper on IBM GSM First draft of OMG CMMN Start of the 
 EU Project ACSI
  23. 23. data-centric … … … activity-centric 1 9 9 8 … 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7 2 0 0 8 2 0 0 9 2 0 1 0 2 0 1 1 2 0 1 2 2 0 1 3 2 0 1 4 2 0 1 5 2 0 1 6 •[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
  24. 24. data-centric … … … activity-centric 1 9 9 8 … 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7 2 0 0 8 2 0 0 9 2 0 1 0 2 0 1 1 2 0 1 2 2 0 1 3 2 0 1 4 2 0 1 5 2 0 1 6 [ICATPN07, Lazic et al.] Data nets [CAiSE10, Sidorova et al.] Conceptual nets [TCS11, Rosa-Velardo and de Frutos-Escrig] ν-PNs (nets managing names) [FAOC16, _] Verification of PNs with names [PN16, Lasota] Survey on PNs with data [PN15, Triebel and Sürmeli] Algebraic PNs
  25. 25. data-centric … … … activity-centric 1 9 9 8 … 2 0 0 3 2 0 0 4 2 0 0 5 2 0 0 6 2 0 0 7 2 0 0 8 2 0 0 9 2 0 1 0 2 0 1 1 2 0 1 2 2 0 1 3 2 0 1 4 2 0 1 5 2 0 1 6 DB-Nets CPNs + databases [AAAI17, _] 
 RAW-SYS
 Workflow nets + databases
  26. 26. One Step Back… How do 
 contemporary 
 activity-centric BPMSs 
 account for the 
 process-data interplay? 26
  27. 27. Example: BizAgi (~) 27 Review Request Fill Reim- bursement Review Reim- bursement Rejected Accepted
  28. 28. Case and Persistent Data Review Request Fill Reim- bursement Review Reim- bursement Rejected Accepted req info result reimbursement personal info 28
  29. 29. Persistent Data Engineering persistent storage29 Review Request Fill Reim- bursement Review Reim- bursement Rejected Accepted req info result reimbursement personal info framework data model custom code
  30. 30. Case Data Engineering persistent storage30 Review Request Fill Reim- bursement Review Reim- bursement Rejected Accepted req info result reimbursement personal info framework data model custom code user forms external services
  31. 31. Recipe • Explicit control-flow • Local, case data • Global, persistent data • Queries/updates on the persistent data • External inputs • Internal generation of fresh IDs 31 DATA-AWARE ACTIVITY CENTRIC PROCESS
  32. 32. Colored Petri Nets • In ν-PNs: explicit construct to create globally fresh data values (ν variables) • No persistent data! 32
  33. 33. Recipe • Explicit control-flow • Local, case data • Global, persistent data • Queries/updates on the persistent data • External inputs • Internal generation of fresh IDs 33 COLORED PETRI NETS Using ν variables
  34. 34. Data layer: relational DB with constraints (monolithic data) Process layer: evolves an instance of the DB • Condition-action rules: action executability, provide parameters • Atomic actions: conditional CRUD operations with external inputs Data-Centric Dynamic Systems 34 unibz.itunibz.it An abstract, pristine framework to formally describe processes that manipulate data. • Captures virtually all existing approaches to data-aware processes, such as the artifact-centric paradigm. DCDS Data Layer Process Layer external service external service external service UpdateRead • Data layer: relational database (with constraints). • Process layer: condition-action rules (include service calls that input new data). Marco Montali Verification of Relational DCDSs PODS 2013 3 / 25
  35. 35. Recipe • Explicit control-flow • Local, case data • Global, persistent data • Queries/updates on the persistent data • External inputs • Internal generation of fresh IDs 35 DATA-CENTRIC DYNAMIC SYSTEMS ~ Can be simulated
  36. 36. Marriage
  37. 37. DB-Nets 37 persistence layer data logic layer control layer DB ActionsQueries View places Places Transitions fetch update populate trigger Arcs Read arcs Rollback arcs Fig. 1. The conceptual components of db-nets joint proposal with Andy Rivkin
  38. 38. Persistence Layer Typed 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
  39. 39. Persistence Layer Typed 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!
  40. 40. Example 40 Emp name: string Ticket id: int descr: string Resp emp: string ticket: int Each employee can handle at most one ticket at a given time Log ticket: int emp: string descr: string
  41. 41. Data Logic Bidirectional interface for interacting with a DB instance of the persistence layer 41 Read-mode: query • open, domain-independent FO formula • answers: substitutions of free variables s.t. the resulting FO sentence is true in the DB instance Write-mode: action • Name • Parameters • Add and delete list • Templates of facts using parameters and constants… • …to be added to/removed from the current DB instance • Transactional semantics: commit vs roll-back That’s just SQL!
  42. 42. Example: Queries • Get tickets and their description • Get “idle” employees 42 plying the update on the given database in over deletions (this is a standard approach situation in which the same fact is asserted The data logic simply exposes a set of q be used by the control layer to obtain data induce updates on the persistence layer. Definition 14 (Data logic layer). Given typed data logic layer over P is a pair hQ, Ai, queries over P; (ii) A is a finite set of action Example 2. We make the scenario of Example layer L over P. L exposes two queries to inspec • Qe(e):- Emp(e) ^ ¬9t.Resp(e, t), to extract id • Qt(t, d):- Ticket(t, d), to extract tickets and In addition, L provides three main functionali layer: ticket registration, assignment/release, a alized through four actions (where, for simplic action and its name). The registration of a ne that, given an integer t, and two strings e and ously creates a ticket identified by t and descri assigns the employee identified by e to such tic
  43. 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) Example: Actions 43
  44. 44. • 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
  45. 45. 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
  46. 46. Place Colored condition/state of the control layer • Color: ordered combination of types • Tokens carry tuples of data over the corresponding types • Two types of place, to distinguish local and global data 46
  47. 47. Normal Place • Represent case states and resources • Color: schema of the local data carried by tokens • May be seen as a special relation of the persistence layer • Tokens explicitly manipulated by the control layer, as customary in CPNs 47 Tickets h Fig. 2. Th
  48. 48. 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 Tickets h Fig. 2. Th
  49. 49. Example 49 Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees r (⌫t, Cr Tickets hempi hti Fig. 2. The control fresh input variable, Example 3. Figure layer P defined in E control layer realize int int ⇥ string int ⇥ string ↵✓ can be successfully applied to I if apply(↵✓, I) complies The application of an action instance amounts to ground all in the definition of the action as specified by the given su plying the update on the given database instance, giving p over deletions (this is a standard approach, which unambi situation in which the same fact is asserted to be added and The data logic simply exposes a set of queries and a set be used by the control layer to obtain data from the persi induce updates on the persistence layer. Definition 14 (Data logic layer). Given a D-typed persi typed data logic layer over P is a pair hQ, Ai, where: (i) Q is queries over P; (ii) A is a finite set of actions over P. Example 2. We make the scenario of Example 1 operational, in layer L over P. L exposes two queries to inspect the persistence • Qe(e):- Emp(e) ^ ¬9t.Resp(e, t), to extract idle employees;Qt(t, d):- Ticket(t, d), to extract tickets and their description. n addition, L provides three main functionalities to manipulate tickets in persistence ayer: ticket registration, assignment/release, and logging. Such functionalities are re- lized through four actions (where, for simplicity, we blur the distinction between an ction and its name). The registration of a new ticket is managed by an action reg hat, given an integer t, and two strings e and d, (reg·params = ht, e, di, simultane- Case variables: - ticket id - name of responsible employee int ⇥ string
  50. 50. Transition Atomic unit of work within the control layer • Input data: obtained by • Consuming tokens from its input places • Reading tokens from its input view places • To access tokens and their data: multisets of tuples of “matching” variables • Data guard over the input variables 50
  51. 51. Transition Atomic unit of work within the control layer • Output data: inputs + additional variables (external input) + ν variables (new ids) • Output data used to • Bind to an action of the data logic, updating the persistence layer • Produce tokens and insert them into the output places 51
  52. 52. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees r (⌫t, Cr Tickets hempi hti Fig. 2. The control fresh input variable, Example 3. Figure layer P defined in E control layer realize
  53. 53. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable.
  54. 54. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable.
  55. 55. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Emp Andy Marco TicketResp Log hAndyi hMarcoi
  56. 56. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. TicketResp Log hAndyi hMarcoi ⌫t = 1 emp = Andy descr = blah Emp Andy Marco
  57. 57. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Ticket 1 blah Resp Andy 1 Log hMarcoi Emp Andy Marco h1, Andyi
  58. 58. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Ticket 1 blah Resp Andy 1 Log hMarcoi Emp Andy Marco h1, Andyi tid = 1 emp = Andy
  59. 59. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Resp Log hAndyi hMarcoi Emp Andy Marco Ticket 1 blah h1, blahi h1, Andyi
  60. 60. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Resp Log hAndyi hMarcoi Emp Andy Marco Ticket 1 blah h1, blahi h1, Andyi ⌫t = 5 emp = Andy descr = blah
  61. 61. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Log hMarcoi Emp Andy Marco Ticket 1 blah 2 blah h1, blahi h1, Andyi Resp Andy 2 h2, Andyi h2, blahi
  62. 62. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Log hMarcoi Emp Andy Marco Ticket 1 blah 2 blah h1, Andyi Resp Andy 2 h2, Andyi tid = 1 emp = Andy h1, blahi h2, blahi
  63. 63. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Log hMarcoi Emp Andy Marco Ticket 1 blah 2 blah h1, Andyi Resp Andy 2 Andy 1 h2, Andyi tid = 1 emp = Andy h1, blahi h2, blahi
  64. 64. Rollback Flow Accounts for the production and routing of tokens when the application of a ground action fails • update ok: update committed on the DB, normal output flow used, rollback flow ignored • update violates some constraint: rollback on the DB, rollback flow used, normal output flow ignored The rollback flow can be used to model “undo” or “compensation” in the control layer when the persistence layer rejects an update 64
  65. 65. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created,
  66. 66. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets release (tid, emp) Stall assign (tid, emp) Awake Stalled tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, empi htid, empi htid,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Log hMarcoi Emp Andy Marco Ticket 1 blah 2 blah h1, Andyi Resp Andy 2 Andy 1 h2, Andyi tid = 1 emp = Andy h1, blahi h2, blahi
  67. 67. 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,em pi htid,em pi htid, empi hempi htid, descri htid,em pi Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is a fresh input variable, and descr is an arbitrary input variable. Example 3. Figure 2 shows the control layer of a db-net B, using the persistence layer P defined in Example 1 and the data logic layer L defined in Example 2.2. The control layer realizes a simple ticket processing workflow, where tickets are created, Idle Employees register (⌫t, emp, descr) CreateTicket Active tickets logData (tid, emp, id) ResolveTickets h⌫t, empi htid, emp htid,em p htid, empi hempi htid, descri Fig. 2. The control layer of a db-net for ticket manage fresh input variable, and descr is an arbitrary input var Example 3. Figure 2 shows the control layer of a db layer P defined in Example 1 and the data logic layer L control layer realizes a simple ticket processing workfl Log hMarcoi Emp Andy Marco Ticket 1 blah 2 blah h1, Andyi Resp Andy 2 h2, Andyi tid = 1 emp = Andy h1, blahi h2, blahi
  68. 68. Execution Semantics Infinite-state relational transition system • State: labeled with a DB-net snapshot <I,m> • I: DB instance for the persistence layer • m: marking of the control layer that properly fills view places w.r.t. I • Transition: firing of a control layer transition with a “legal” binding for the inscription variables • All possible snapshots and all (infinitely many) bindings are considered 68
  69. 69. … Sources of Infinity 69 …… … … … … … … … … … … Fixed initial snapshot
  70. 70. … Sources of Infinity 70 …… … … … … … … … … … … Infinite-branching 
 due to external inputs and new id generation
  71. 71. … Sources of Infinity 71 …… … … … … … … … … … … Runs visiting infinitely many DBs/markings 
 due to usage of external data
  72. 72. 72
  73. 73. Formal Verification The Conventional, Propositional Case Process control-flow (Un)desired property 73
  74. 74. (Un)desired property Finite-state transition system Propositional temporal formula|= Formal Verification The Conventional, Propositional Case Process control-flow 74
  75. 75. (Un)desired property Finite-state transition system Propositional temporal formula|= Verification via model checking 2007 Turing award: Clarke, Emerson, Sifakis Formal Verification The Conventional, Propositional Case Process control-flow 75
  76. 76. (Un)desired property Formal Verification The Data-Aware Case 76 Process+Data
  77. 77. (Un)desired property First-order temporal formula|= Process+Data Formal Verification The Data-Aware Case Infinite-state, relational transition system 77
  78. 78. (Un)desired property First-order temporal formula|= ? Formal Verification The Data-Aware Case 78 Process+Data Infinite-state, relational transition system [Vardi 2005]
  79. 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 79
  80. 80. 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) ◆
  81. 81. 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))
  82. 82. A true false BPMS and Data Correct? • BizAgi… • YAWL… 82
  83. 83. A true false BPMS and Data Correct? • BizAgi… not sure… • YAWL… YES! 83
  84. 84. The Good… DCDS are: • Markovian: Next state only depends on the current state + input. 
 Two states with identical DBs are bisimilar. • Generic: FO/SQL (as all query languages) does not distinguish structures which are identical modulo uniform renaming of data objects. —> Two isomorphic states are bisimilar 84
  85. 85. …the Bad… 85
  86. 86. …the Bad… 86 Persistence layer Control layer (without colors) Data logic layer
  87. 87. …and the Ugly Simulation of a 2-counter Minsky machine • Counter —> “size” of a unary relation • Test counter for zero: query asserting that the counter relation is empty • What matters is the # of tuples, not the actual values 87 New Increment Decrement
  88. 88. … 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
  89. 89. Problem Parameters 89 persistence layer data logic layer control layer DB ActionsQueries View places Places Transitions fetch update populate trigger Arcs Read arcs Rollback arcs Fig. 1. The conceptual components of db-nets
  90. 90. Problem Parameters 90 persistence layer data logic layer control layer DB ActionsQueries View places Places Transitions fetch update populate trigger Arcs Read arcs Rollback arcs Fig. 1. The conceptual components of db-nets Choice 1 Choice 2 … Choice 1 undecidable boring boring Choice 2 boring PTime boring Choice 3 boring boring PSpace … NP boring …
  91. 91. 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
  92. 92. Our Goal 92 First-order temporal formula |= Infinite-state transition system
  93. 93. Our Goal 93 First-order temporal formula |= Infinite-state transition system |= Finite-state abstraction Propositional temporal formula ‘
  94. 94. Our Goal 94 First-order temporal formula |= Infinite-state transition system |= Propositional temporal formula ‘ If and only if Finite-state abstraction
  95. 95. 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
  96. 96. Effect of state-boundedness 96 General State-bounded μLa undecidable LTL-FOa undecidable
  97. 97. Effect of state-boundedness 97 General State-bounded μLa undecidable decidable 
 abstraction must 
 depend on the formula! LTL-FOa undecidable undecidable
  98. 98. Effect of state-boundedness 98 General State-bounded μLa undecidable decidable 
 abstraction must 
 depend on the formula! LTL-FOa undecidable undecidable Reason? FO quantification across states.
  99. 99. Effect of state-boundedness 99 General State-bounded μLa undecidable decidable 
 abstraction must 
 depend on the formula! LTL-FOa undecidable undecidable Logic unable to isolate single runs/computations
  100. 100. 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 Persistence-Preserving µ-calculus (µLP) In some cases, objects maintain their identity only if they persist in th active domain (cf. business artifacts and their IDs). . . . StudId : 123 . . . StudId : 123 . . .dismiss(123) newStud() ID() = 123 µLA µLFOG(8s.Student(s) ! Student(s)U(Retired(s) _ Graduated(s))) 100
  101. 101. Effect of Persistent Quantification 101 General State-bounded μLa undecidable decidable 
 abstraction must 
 depend on the formula! μLp LTL-FOa undecidable undecidable LTL-FOp
  102. 102. Effect of Persistent Quantification 102 General State-bounded μLa undecidable decidable 
 abstraction must 
 depend on the formula! μLp undecidable LTL-FOa undecidable undecidable LTL-FOp undecidable
  103. 103. Effect of Persistent Quantification 103 General State-bounded μLa undecidable decidable 
 abstraction must 
 depend on the formula! μLp undecidable decidable formula-independent abstraction! LTL-FOa undecidable undecidable LTL-FOp undecidable decidable formula-independent abstraction!
  104. 104. 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
  105. 105. Example • External Input: single (new?) value • Current state: two objects (in DB and/or marking) a,b a b c de 105
  106. 106. Example a,b a b c 106 • External Input: single (new?) value • Current state: two objects (in DB and/or marking)
  107. 107. 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
  108. 108. 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
  109. 109. Recap 109 Prune Recycle
  110. 110. 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
  111. 111. 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 patterns 111
  112. 112. 112 OBDI framework Query answering Ontology languages Mappings Identity Conclusions Ontology-based data integration framework . . . . . . . . . . . . Query Result Ontology provides global vocabulary and conceptual view Mappings semantically link sources and ontology Data Sources external and heterogeneous We achieve logical transparency in accessing data: does not know where and how the data is stored. can only see a conceptual view of the data. legacy data sources conceptual data model mapping KAOS Project 
 Knowledge-Aware Operational Support trace, events, attrs… event annotations
  113. 113. OBDI framework Query answering Ontology languages Mappings Identity Conclusions Ontology-based data integration framework . . . . . . . . . . . . Query Result Ontology provides global vocabulary and conceptual view Mappings semantically link sources and ontology Data Sources external and heterogeneous We achieve logical transparency in accessing data: does not know where and how the data is stored. can only see a conceptual view of the data. legacy data sources conceptual data model mapping KAOS Project 
 Knowledge-Aware Operational Support trace, events, attrs… event annotations 113 OBDI framework Query answering Ontology languages Mappings Identity Conclusions Ontology-based data integration framework . . . . . . . . . . . . Query Result Ontology provides global vocabulary and conceptual view Mappings semantically link sources and ontology Data Sources external and heterogeneous We achieve logical transparency in accessing data: does not know where and how the data is stored. can only see a conceptual view of the data. process mining
  114. 114. Log Annotations 114 1..* * Conference creation time:DateTime conf name:String User creation time:DateTime username:String Paper creation time:DateTime title:String Review Request invitation time:DateTime Review submission time:DateTime Decision decision time:DateTime outcome: Bool Upload Submitted upload time:DateTime Upload Accepted upload time:DateTime submitted to 1 * organizer of Accepted Paper <<no time>> * reviewer 1 0..1 PhasD 1 0..1 RhasR 1 10..1 corresponds to * UhasP 1 * AhasU 1 *1 for author 1..* * by 1 * USuploadbyU creator 1 * 1* UAuploadbyU 1 * trace event event eventevent trace: follow has activity name: “decision” timestamp: decision time resource: follow by type: complete attributes: outcome trace: follow has & for activity name: “review” timestamp: submission time resource: follow RhasR & reviewer type: complete trace: follow has activity name: “upload submitted” timestamp: upload time resource: follow USuploadbyU type: complete trace: follow has & corr. to activity name: “upload accepted” timestamp: upload time resource: follow UAuploadbyU type: complete submitted to = BPM 2015
  115. 115. 115 1..* * Conference creation time:DateTime conf name:String User creation time:DateTime username:String Paper creation time:DateTime title:String Review Request invitation time:DateTime Review submission time:DateTime Decision decision time:DateTime outcome: Bool submitted to 1 * organizer of * reviewer 1 0..1 PhasD 1 0..1 RhasR 1 1sponds to sP 1 *1 for author 1..* * by 1 * creator 1 * 1 UAuploadbyU 1 trace event event trace: follow has activity name: “decision” timestamp: decision time resource: follow by type: complete attributes: outcome trace: follow has & for activity name: “review” timestamp: submission time resource: follow RhasR & reviewer type: complete submitted to = BPM 2015
  116. 116. Multiple Log Views 116 1..* * Conference creation time:DateTime conf name:String User creation time:DateTime username:String Paper creation time:DateTime title:String Review Request invitation time:DateTime Review submission time:DateTime Decision decision time:DateTime outcome: Bool Upload Submitted upload time:DateTime Upload Accepted upload time:DateTime submitted to 1 * organizer of Accepted Paper <<no time>> * reviewer 1 0..1 PhasD 1 0..1 RhasR 1 10..1 corresponds to * UhasP 1 * AhasU 1 *1 for author 1..* * by 1 * USuploadbyU creator 1 * 1* UAuploadbyU 1 * trace event trace: follow has author activity name: “decision author” timestamp: decision time resource: follow PhasD type: complete event trace: follow by activity name: “decision chair” timestamp: decision time resource: follow PhasD type: complete attributes: outcome event trace: follow has & reviewer activity name: “review” timestamp: submission time resource: follow RhasR & for type: complete event trace: follow upload by activity name: “upload submitted” timestamp: upload time resource: follow UhasP type: complete
  117. 117. 117 1..* * Conference creation time:DateTime conf name:String User creation time:DateTime username:String Paper creation time:DateTime title:String Review Request invitation time:DateTime Review submission time:DateTime Decision decision time:DateTime outcome: Bool ted me ed me submitted to 1 * organizer of er * reviewer 1 0..1 PhasD 1 0..1 RhasR 1 10..1 corresponds to * UhasP 1 *1 for author 1..* * by 1 * USuploadbyU creator 1 * 1 UAuploadbyU 1 trace event trace: follow has author activity name: “decision author” timestamp: decision time resource: follow PhasD type: complete event trace: follow by activity name: “decision chair” timestamp: decision time resource: follow PhasD type: complete attributes: outcome event trace: follow has & reviewer activity name: “review” timestamp: submission time resource: follow RhasR & for type: complete
  118. 118. 118 Conclusion
  119. 119. 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
  120. 120. Acknowledgments All coauthors of this research, 
 in particular 
 
 Diego Calvanese (UNIBZ)
 Giuseppe De Giacomo (Sapienza UNIROMA)
 Alin Deutsch (UCSD)
 Marlon Dumas (Uni Tartu)
 Fabio Patrizi (Sapienza UNIROMA)
 Andy Rivkin (UNIBZ) 120

×