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.
Towards Convergence of Data and Processes
The Artifact-Centric Approach
Marco Montali
KRDB Research Centre for Knowledge a...
Outline
• From activity-centric to artifact-centric BPM.
Credits to the ACSI team, in particular Marlon Dumas.
• Artifact-...
Traditional Process Modeling
• Structural modeling of the domain of interest:
conceptual models, domain ontologies, databa...
Build-to-Order Process
1. Customer PO
Marco Montali Towards Convergence of Data and Processes December 20, 2012 4 / 45
Build-to-Order Process
1. Customer PO
2. order decomposition
Material PO
Line item
Customer PO
Marco Montali Towards Conve...
Build-to-Order Process
3. Selection and
interaction with suppliers
1. Customer PO
2. order decomposition
Material PO
Line ...
Build-to-Order Process
3. Selection and
interaction with suppliers
1. Customer PO
2. order decomposition
Material PO
Line ...
Build-to-Order Process
3. Selection and
interaction with suppliers
1. Customer PO
2. order decomposition
Material PO
Line ...
Build-to-Order Process
3. Selection and
interaction with suppliers
1. Customer PO
2. order decomposition
Material PO
Line ...
Build-to-Order Process
3. Selection and
interaction with suppliers
1. Customer PO
2. order decomposition
Material PO
Line ...
Traditional Approach
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
• Value chain construction
...
Traditional Approach
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
Activities
Process
Data
Act...
BPMN ModelHigh‐Level
BPMN
Model

4
Marco Montali Towards Convergence of Data and Processes December 20, 2012 6 / 45
Data Modeling
Customer PO Line Item
Work OrderMaterial PO
*
*
spawns
0..1
Material
Marco Montali Towards Convergence of Da...
Distribution of Responsibility
Supplier
ManufacturingProcurement/Supplier
Sales
Customer PO Line Item
Work OrderMaterial P...
Cancelation Business Rule
Supplier
ManufacturingProcurement/Supplier
Sales
Customer PO Line Item
Work OrderMaterial PO
*
*...
Cancelation Business Rule
Supplier
ManufacturingProcurement/Supplier
Sales
Customer PO Line Item
Work OrderMaterial PO
*
*...
Spaghetti Layer
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
Activities
Process
Data
Activiti...
Spaghetti Layer
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
Activities
Process
Data
Activiti...
Conceptual Modeling vs Architectures
Architectures do not really help.
• SOA + Data Integration
Activity
Task Service
Enti...
Conceptual Model or Conceptual Models?
• Business stakeholders have a single conceptualization of their
business.
• IT pro...
Rosenquist and Evolving, Living Entities (1982)
Seminar Database 75 and in the Asian Computer Year
Book.6 conceptual entit...
Rosenquist and Evolving, Living Entities (1982)
DATA ANALYSIS
B
t
T
s
i
s
s
D
p
a
(
i
t
q
s
s
Marco Montali Towards Conver...
Rosenquist and Evolving, Living Entities (1982)
•WE REAL WORLD
PROGRAM STRUCTURES
• Functional hierarchies
MA Jackson nota...
Business Artifacts on the Rescue
• Rosenquist’s vision did not become reality. . .
• . . . but the data-process divide pro...
What is an Artifact?
Definition
A key, business-relevant conceptual dynamic entity that is used in guiding
the operation of...
Artifacts in the Build-To-Order Process
The process now centres around interconnected business-relevant entities:
• Custom...
ACSI Artifact Paradigm
Marco Montali Towards Convergence of Data and Processes December 20, 2012 17 / 45
A3
M: ACSI Artifact Abstract Model
An abstract (i.e., data and process
agnostic) model for representing the
key concepts o...
Interoperation Hub
Extension of A3M to support multi-party service interoperation.
elevant conceptual dynamic entity that ...
Separation Principle and Semantic Layer
The evolution of the artifact system occurs at the artifact layer.
• Processes are...
Semantically-governed A3
M
Semantic layer: I-HUB’s conceptual schema (TBox) composed of semantic
constraints that define th...
Semantically-governed A3
M
Real data are concretely maintained at the artifact layer.
Snapshot: database instances of arti...
Semantically-governed A3
M
Each snapshot is conceptualized in the ontology, in terms of an ABox.
Mappings define how to obt...
Semantically-governed A3
M
The system evolves thanks to actions/processes executed over the artifact
layer.
Semantic layer...
Semantically-governed A3
M
Semantic governance: semantic layer used to regulate the actions’
execution at the artifact lay...
Artifact Concrete Models
Some concrete information models:
• Relational database (with nested records).
• (Description Log...
Guard-Stage-Milestone Artifacts
Information model: nested records.
Lifecycle: constituted by
• Events, triggering the prog...
Build-To-Order Process in GSM - Information model
• Conceptual schema. Customer purchase order:
1..1 1..1
Carrier Supplier...
Build-To-Order Process in GSM - Customer PO Lifecycle
Researching Ordering Assembling
all
researched
one ordered
comp.
rec...
Reasoning about Artifacts as Dynamic Entities
We want to provide a formal foundation for artifact-centric systems, and
pro...
Reasoning about Artifacts as Dynamic Entities
We want to provide a formal foundation for artifact-centric systems, and
pro...
Verification of Artifacts is Tough
What is a non-artifact example of a finite-state control process
manipulating possibly un...
Verification of Artifacts is Tough
What is a non-artifact example of a finite-state control process
manipulating possibly un...
Artifact Formal Foundations
Is there hope to find interesting decidable cases?
• This requires to identify “classes of syst...
Data-Centric Dynamic Systems (DCDS)
Data layer Process layer DCDS
Data Layer: Relational database.
• Relational schema (wi...
DCDS Example
Data Layer
Information about hotels and their price:
• Cur = Currency
• CurHotel = Hotel, Currency
• PEntry =...
Execution Semantics: Infinite-State Transition Systems
Cur(EUR)
Hotel(h,80)
CurHotel(h,USD)
Marco Montali Towards Convergen...
Execution Semantics: Infinite-State Transition Systems
Cur(EUR)
Hotel(h,80)
CurHotel(h,USD)
Conv(h1,EUR)
call conv_usd(80,E...
Execution Semantics: Infinite-State Transition Systems
Cur(EUR)
Hotel(h,80)
CurHotel(h,USD)
Conv(h1,EUR)
call conv_usd(80,E...
Execution Semantics: Infinite-State Transition Systems
Cur(EUR)
Hotel(h,80)
CurHotel(h,USD)
Conv(h1,EUR)
call conv_usd(80,E...
Verification formalisms
Remember: verification is undecidable even for propositional reachability
properties and very simple...
Verification formalisms
Remember: verification is undecidable even for propositional reachability
properties and very simple...
Verification formalisms
Remember: verification is undecidable even for propositional reachability
properties and very simple...
Conditions
Run-bounded DCDS: every run cannot accumulate more than a fixed
bound of different values.
• Still infinite-state ...
Results
Theorem
Verification of µLA over run-bounded DCDSs is decidable and can be
reduced to model checking of proposition...
Results
Theorem
Verification of µLA over run-bounded DCDSs is decidable and can be
reduced to model checking of proposition...
Results
Theorem
Verification of µLA over run-bounded DCDSs is decidable and can be
reduced to model checking of proposition...
Results
Theorem
Verification of µLA over state-bounded DCDSs is undecidable.
Idea: the logic can arbitrarily quantify over ...
Results
Theorem
Verification of µLP over run-bounded DCDSs is decidable and can be
reduced to model checking of proposition...
Results
Theorem
Verification of µLP over run-bounded DCDSs is decidable and can be
reduced to model checking of proposition...
Results
Theorem
Verification of µLP over run-bounded DCDSs is decidable and can be
reduced to model checking of proposition...
Conclusion
• Need of holistic view of data+process.
• Artifact-centric systems provide a promising answer to this
requirem...
Ongoing/Future Work
• Application of DCDSs for the verification of GSM-based artifacts.
• Further results both in the relat...
Case Management
• Seminal work by van der Aalst et al. (2005): traditional BPM, data
fragmentation and the “blind surgeon”...
CMMN: Case Management Modeling and Notation
Emerging OMG Standard for declarative case management.
• Submitters: BizAgi, C...
Thanks!
Talk
End
Questions
a	
  
iSC	
  
Marco Montali Towards Convergence of Data and Processes December 20, 2012 45 / 45
Upcoming SlideShare
Loading in …5
×

Seminar@FBK-IRST 2012 - Montali - Towards Convergence of Data and Processes: the Artifact-Centric Approach

176 views

Published on

Seminar on "Towards Convergence of Data and Processes: the Artifact-Centric Approach" at FBK-IRST, Trento (Italy), 20/12/2012.

  • Be the first to comment

  • Be the first to like this

Seminar@FBK-IRST 2012 - Montali - Towards Convergence of Data and Processes: the Artifact-Centric Approach

  1. 1. Towards Convergence of Data and Processes The Artifact-Centric Approach Marco Montali KRDB Research Centre for Knowledge and Data Free University of Bozen-Bolzano December 20, 2012 - Trento Marco Montali Towards Convergence of Data and Processes December 20, 2012 1 / 45
  2. 2. Outline • From activity-centric to artifact-centric BPM. Credits to the ACSI team, in particular Marlon Dumas. • Artifact-centric modeling. Credits to the ACSI team. • Foundations of artifact-centric systems and their formal verification. Joint work with Diego Calvanese and the KRDB “process+data” subgroup, Giuseppe De Giacomo and colleagues, Alin Deutsch. Marco Montali Towards Convergence of Data and Processes December 20, 2012 2 / 45
  3. 3. Traditional Process Modeling • Structural modeling of the domain of interest: conceptual models, domain ontologies, database schemas UML, ORM, ER, . . . • Behavioral modeling of the domain of interest: activities, services, business processes BPMN, EPC, UML, BPEL, SOA-related technologies, . . . • A divide et impera approach, to attack the complexity of the domain. Marco Montali Towards Convergence of Data and Processes December 20, 2012 3 / 45
  4. 4. Build-to-Order Process 1. Customer PO Marco Montali Towards Convergence of Data and Processes December 20, 2012 4 / 45
  5. 5. Build-to-Order Process 1. Customer PO 2. order decomposition Material PO Line item Customer PO Marco Montali Towards Convergence of Data and Processes December 20, 2012 4 / 45
  6. 6. Build-to-Order Process 3. Selection and interaction with suppliers 1. Customer PO 2. order decomposition Material PO Line item Customer PO Marco Montali Towards Convergence of Data and Processes December 20, 2012 4 / 45
  7. 7. Build-to-Order Process 3. Selection and interaction with suppliers 1. Customer PO 2. order decomposition Material PO Line item Customer PO Marco Montali Towards Convergence of Data and Processes December 20, 2012 4 / 45
  8. 8. Build-to-Order Process 3. Selection and interaction with suppliers 1. Customer PO 2. order decomposition Material PO Line item Customer PO 4. material assembly Marco Montali Towards Convergence of Data and Processes December 20, 2012 4 / 45
  9. 9. Build-to-Order Process 3. Selection and interaction with suppliers 1. Customer PO 2. order decomposition Material PO Line item Customer PO 4. material assembly 5. Shipment Marco Montali Towards Convergence of Data and Processes December 20, 2012 4 / 45
  10. 10. Build-to-Order Process 3. Selection and interaction with suppliers 1. Customer PO 2. order decomposition Material PO Line item Customer PO 4. material assembly 5. Shipment • Customer can cancel the order at any time (penalty management). Marco Montali Towards Convergence of Data and Processes December 20, 2012 4 / 45
  11. 11. Traditional Approach Manage Cancelation ShipAssemble Manage Material POs Decompose Customer PO • Value chain construction Marco Montali Towards Convergence of Data and Processes December 20, 2012 5 / 45
  12. 12. Traditional Approach Manage Cancelation ShipAssemble Manage Material POs Decompose Customer PO Activities Process Data Activities Process Data Activities Process Data Activities Process Data Activities Process Data • Value chain construction • Break-down of each phase into business functions. • Further decomposition: data component (domain description). activities (units of work) + process component (control-flow). • Impedance mismatch: data and process divide! Marco Montali Towards Convergence of Data and Processes December 20, 2012 5 / 45
  13. 13. BPMN ModelHigh‐Level
BPMN
Model
 4 Marco Montali Towards Convergence of Data and Processes December 20, 2012 6 / 45
  14. 14. Data Modeling Customer PO Line Item Work OrderMaterial PO * * spawns 0..1 Material Marco Montali Towards Convergence of Data and Processes December 20, 2012 7 / 45
  15. 15. Distribution of Responsibility Supplier ManufacturingProcurement/Supplier Sales Customer PO Line Item Work OrderMaterial PO * * spawns 0..1 Material Marco Montali Towards Convergence of Data and Processes December 20, 2012 8 / 45
  16. 16. Cancelation Business Rule Supplier ManufacturingProcurement/Supplier Sales Customer PO Line Item Work OrderMaterial PO * * spawns 0..1 For each work order W For each material PO M in W if M has been shipped add returnCost(M) to penalty Determine cancelation penalty Notify penalty Material Process Engine Process State Marco Montali Towards Convergence of Data and Processes December 20, 2012 9 / 45
  17. 17. Cancelation Business Rule Supplier ManufacturingProcurement/Supplier Sales Customer PO Line Item Work OrderMaterial PO * * spawns 0..1 For each work order W For each material PO M in W if M has been shipped add returnCost(M) to penalty Determine cancelation penalty Notify penalty Material Process Engine Process State Marco Montali Towards Convergence of Data and Processes December 20, 2012 9 / 45
  18. 18. Spaghetti Layer 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 Marco Montali Towards Convergence of Data and Processes December 20, 2012 10 / 45
  19. 19. Spaghetti Layer 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 Marco Montali Towards Convergence of Data and Processes December 20, 2012 10 / 45
  20. 20. Conceptual Modeling vs Architectures Architectures do not really help. • SOA + Data Integration Activity Task Service Entity Service Entity Service Entity Service Entity Service • Enterprise Service Bus Enterprise Service Bus Activity Entity Service Entity Service Entity Service Entity Service Task Service Marco Montali Towards Convergence of Data and Processes December 20, 2012 11 / 45
  21. 21. Conceptual Model or Conceptual Models? • Business stakeholders have a single conceptualization of their business. • IT provides support for several loosely-coupled conceptual models of the organization: rules and policies; analytics, dashboards, key performance indicators; activity-centric business processes; data. • Lack of a coherent, holistic view: process data redundancy; business rules redundancy. Marco Montali Towards Convergence of Data and Processes December 20, 2012 12 / 45
  22. 22. Rosenquist and Evolving, Living Entities (1982) Seminar Database 75 and in the Asian Computer Year Book.6 conceptual entity model DATA ANALYSIS Figure 2. The stages involved in data analysis and the information Basic diagrammatic con tives used The documentation of o systems and data structu in a common informat shown in Fig. 2. This co system conforming to th Data Dictionary Workin The basic concept of t paedia is the division of and the relation between (manual systems include i.e. the four quadrants o the total picture. As illustrated in Fig. quadrants will gradually stages: (a) conceptual an stage and (c) design stag At the time of implem documentation should b for enquiry in order to ea The information system the stages mentioned ab boundaries between the f systems encyclopaedia relationships covering a process toentities and vic which implement the fu represented, (iv) progra they utilize. The information usedMarco Montali Towards Convergence of Data and Processes December 20, 2012 13 / 45
  23. 23. Rosenquist and Evolving, Living Entities (1982) DATA ANALYSIS B t T s i s s D p a ( i t q s s Marco Montali Towards Convergence of Data and Processes December 20, 2012 13 / 45
  24. 24. Rosenquist and Evolving, Living Entities (1982) •WE REAL WORLD PROGRAM STRUCTURES • Functional hierarchies MA Jackson notation PHYSICAL DATA STRUCTURES • Extended Bachman notation (depending on the implementation vehicle) 'THE IMPLEMENTATtON' objecti version in App 'The im of the states life cyc tation for sel docum functio the me and br 'The im the do tion o benefit implem meta l syntax The languaMarco Montali Towards Convergence of Data and Processes December 20, 2012 13 / 45
  25. 25. Business Artifacts on the Rescue • Rosenquist’s vision did not become reality. . . • . . . but the data-process divide problem became more and more pressing. Richardson (Forrester) at BPM 2010: “Data and process are two sides of the same coin”. Still the focus was on establishing connections between the MDM and BPM silos. • In the meanwhile, the artifact-centric approach emerged as a foundational proposal for merging data and processes together. Data must be modeled taking into account that they will be manipulated by processes. Processes must be modeled by considering that they are meant to manipulate data. • Initial proposals by IBM (Kamal Bhattacharya, Rick Hull, late ’90). • ACSI Project for artifact-centric service interoperation. Marco Montali Towards Convergence of Data and Processes December 20, 2012 14 / 45
  26. 26. What is an Artifact? Definition A key, business-relevant conceptual dynamic entity that is used in guiding the operation of a business. Consists of: • information model - relevant data maintained by the artifact • lifecycle model - (implicit) description of the allowed information model evolutions through the execution of a process. Information model Lifecycle Artifact Goal: unified, end-to-end view of relevant entities and their possible evolutions. Marco Montali Towards Convergence of Data and Processes December 20, 2012 15 / 45
  27. 27. Artifacts in the Build-To-Order Process The process now centres around interconnected business-relevant entities: • Customer PO handles a customer order from creation to delivery. • Work Order handles one of the work orders spawned for a line item in a customer PO. • Material PO handles a material PO from request to shipment (and possible rejections). • Assembly manages the aggregation of materials and sub-assemblies. How to specify the lifecycle of such artifacts? At which level of abstraction? How and where to store data maintained by their information models? Marco Montali Towards Convergence of Data and Processes December 20, 2012 16 / 45
  28. 28. ACSI Artifact Paradigm Marco Montali Towards Convergence of Data and Processes December 20, 2012 17 / 45
  29. 29. A3 M: ACSI Artifact Abstract Model An abstract (i.e., data and process agnostic) model for representing the key concepts of an artifact system. A key, business-relevant conceptual dynamic entity that is used in guiding the operation of a business. Consists of: • information model - relevant data maintained by the artifact • lifecycle model - (implicit) description of the allowed information model evolutions through the execution of a process. Information model Lifecycle Artifact Goal: unified, end-to-end view of relevant entities and their possible evolutions. Marco Montali Towards Convergence of Data and Processes December 20, 2012 16 / 29 • information model - relevant data maintained by the artifact • lifecycle model - (implicit) description of the allowed information model evolutions through the execution of a process. Information model Lifecycle Artifact Goal: unified, end-to-end view of relevant entities and their possible evolutions. Marco Montali Towards Convergence of Data and Processes December 20, 2012 16 / 29 Definition A key, business-relevant conceptual dynamic entity that is used in guiding the operation of a business. Consists of: • information model - relevant data maintained by the artifact • lifecycle model - (implicit) description of the allowed information model evolutions through the execution of a process. Information model Lifecycle Artifact Goal: unified, end-to-end view of relevant entities and their possible evolutions. Marco Montali Towards Convergence of Data and Processes December 20, 2012 16 / 29 artifact event environment gateway • Artifact type: set of artifact instances with the same information model (database). Artifact instance = ID + database instance. • Environment gateway: data container to exchange information with the external world. • Event: data container sent at some moment in time. • Relationship: association between entities, with a stereotype. E.g.: create-event, reference, may-destroy-artifact, . . . • Static constraint: constraints that must hold in every state of the system. E.g.: information model integrity constraints. • Dynamic constraint: intra- and inter-artifact constraints about acceptable evolutions of the system. Lifecycle: intra-artifact constraints relating artifact phases across time. Marco Montali Towards Convergence of Data and Processes December 20, 2012 18 / 45
  30. 30. Interoperation Hub Extension of A3M to support multi-party service interoperation. elevant conceptual dynamic entity that is used in guiding a business. model - relevant data maintained by the artifact del - (implicit) description of the allowed information tions through the execution of a process. formation model Lifecycle Artifact d-to-end view of relevant entities and their possible Towards Convergence of Data and Processes December 20, 2012 16 / 29 information model - relevant data maintained by the artifact lifecycle model - (implicit) description of the allowed information model evolutions through the execution of a process. Information model Lifecycle Artifact : unified, end-to-end view of relevant entities and their possible utions. Marco Montali Towards Convergence of Data and Processes December 20, 2012 16 / 29 Definition A key, business-relevant conceptual dynamic entity that is used in guid the operation of a business. Consists of: • information model - relevant data maintained by the artifact • lifecycle model - (implicit) description of the allowed information model evolutions through the execution of a process. Information model Lifecycle Artifact Goal: unified, end-to-end view of relevant entities and their possible evolutions. Marco Montali Towards Convergence of Data and Processes December 20, 2012 artifact event environment gateway service participant organisational info authorisation view What is an Artifact? Definition A key, business-relevant conceptual dynamic entity that is used in guiding the operation of a business. Consists of: • information model - relevant data maintained by the artifact • lifecycle model - (implicit) description of the allowed information model evolutions through the execution of a process. Information model Lifecycle Artifact Goal: unified, end-to-end view of relevant entities and their possible evolutions. new artifact Marco Montali Towards Convergence of Data and Processes December 20, 2012 19 / 45
  31. 31. Separation Principle and Semantic Layer The evolution of the artifact system occurs at the artifact layer. • Processes are defined over the database schemas of the artifacts. The semantic layer can be added on top of the artifact layer to: • Understand the artifact system in terms of concepts and relationships relevant for the domain of interest. Unified view of the whole system. Interconnection of different artifacts that share information, though with different representation. Support to new artifacts in understanding how they could attach to the information maintained by other artifacts. Specification of queries as well as static and dynamic constraint at the conceptual level. • Govern the artifact system: regulating the introduction of new artifacts and processes in the system; ensuring that processes running over the artifact layer always manipulate data in accordance to the semantic layer. • Verify and monitor whether the artifact system satisfies dynamic constraints specified over the semantic layer. Marco Montali Towards Convergence of Data and Processes December 20, 2012 20 / 45
  32. 32. Semantically-governed A3 M Semantic layer: I-HUB’s conceptual schema (TBox) composed of semantic constraints that define the “data boundaries” of the artifact system. TBox Marco Montali Towards Convergence of Data and Processes December 20, 2012 21 / 45
  33. 33. Semantically-governed A3 M Real data are concretely maintained at the artifact layer. Snapshot: database instances of artifacts, events and gateways. Da Db Dc Artifact System Snapshot TBox Marco Montali Towards Convergence of Data and Processes December 20, 2012 22 / 45
  34. 34. Semantically-governed A3 M Each snapshot is conceptualized in the ontology, in terms of an ABox. Mappings define how to obtain the virtual ABox from the concrete data sources. Da Db Dc Artifact System Snapshot Mappings Semantic Layer Snapshot TBox ABox1 Marco Montali Towards Convergence of Data and Processes December 20, 2012 23 / 45
  35. 35. Semantically-governed A3 M The system evolves thanks to actions/processes executed over the artifact layer. Semantic layer used to understand the evolution at the conceptual level. Da Db Dc Artifact System Snapshot D'a D'b D'c Artifact System Snapshot Action execution Mappings Mappings Semantic Layer Snapshot TBox ABox1 TBox Semantic Layer Snapshot ABox2 Marco Montali Towards Convergence of Data and Processes December 20, 2012 24 / 45
  36. 36. Semantically-governed A3 M Semantic governance: semantic layer used to regulate the actions’ execution at the artifact layer. Actions leading to violate the semantic constraints are rejected. Da Db Dc Artifact System Snapshot D'a D'b D'c Artifact System Snapshot Action execution Mappings Mappings Semantic Layer Snapshot TBox ABox1 TBox Semantic Layer Snapshot ABox2 Marco Montali Towards Convergence of Data and Processes December 20, 2012 25 / 45
  37. 37. Artifact Concrete Models Some concrete information models: • Relational database (with nested records). • (Description Logic) Knowledge base. Some concrete lifecycle models: • Finite-state machines. State = phase; events trigger transitions. Implemented in the Siena IBM prototype. • Proclets (interacting Petri nets). Emphasise many-to-many relationships between artifacts. • Guard-Stage-Milestone lifecycles, based on declarative ECA-like rules. Implemented in the Barcelona IBM prototype. Marco Montali Towards Convergence of Data and Processes December 20, 2012 26 / 45
  38. 38. Guard-Stage-Milestone Artifacts Information model: nested records. Lifecycle: constituted by • Events, triggering the progression of the lifecycle. External events inject fresh data into the system, internal events mark changes of the lifecycle state. • Atomic tasks, used to create/destroy artifacts and to interact with the environment. Implemented using service. • Sentries, logical formulae combining an optional triggering event and a query over the information model (using OCL). • Milestones, business-relevant objectives at different levels of granularity. Can be achieved by making the corresponding sentry true, invalidated otherwise. • Stages, cluster of tasks and sub-stages that jointly concur to the achievement of some milestones. • Guards, sentries used to control the activation of a corresponding stage. Whenever a guard becomes true, the stage opens and must eventually reach a milestone to become closed. Marco Montali Towards Convergence of Data and Processes December 20, 2012 27 / 45
  39. 39. Build-To-Order Process in GSM - Information model • Conceptual schema. Customer purchase order: 1..1 1..1 Carrier SupplierAssembler1..1 1..1 1..1 1..1 1..1 orderID : int status : {...} Order prodName : string Product Type Component Type compName : string price : int color : string ComponentProduct companyName : string Company SSN : string address : string {0..n} Customer 1..1 1..n fulfills suppliedBy1..1 assembledBy shippedBy Ptype Ctype 1..1 orderFor 1..1 madeOf1..1 makesOrder • GSM status attributes: open/closed stages, achieved/invalidated milestones. Marco Montali Towards Convergence of Data and Processes December 20, 2012 28 / 45
  40. 40. Build-To-Order Process in GSM - Customer PO Lifecycle Researching Ordering Assembling all researched one ordered comp. received submitted shipped Submitting Shipping human task human task automatic task automatic task automatic task [carry] (Assembler) [research] (Assembler) [submit] (Customer) [create] (Customer) [receiveOrder] (Customer) [cancel] (Customer) Legend: [external event ev] ... AND ev.onEvent() [collect] (Assembler) Customer Assembler Carrier [receiveComp] (Assembler) setReceived (to Component artifact) create (a Component artifact) order (to Component artifact) [orderComp] (Assembler) [orderComp] (Assembler) all ordered all assembled [receiveComp] (Assembler) Fulfilling order assembled Processing order received order cancelled Diamond: guard. Rounded rectangle: stage. Circle: milestone. Sentries are partially hidden. Arrows denote dependencies on certain status attributes. Marco Montali Towards Convergence of Data and Processes December 20, 2012 29 / 45
  41. 41. Reasoning about Artifacts as Dynamic Entities We want to provide a formal foundation for artifact-centric systems, and provide corresponding reasoning facilities for their trustworthy design. In particular, we want to decide whether dynamic/temporal properties of interest hold over the life of such systems. • Verification of temporal formulae. • Dominance/simulation/bisimulation/containment properties. • Automated composition of artifacts-based systems. • Automated process synthesis from dynamic/temporal specifications. Marco Montali Towards Convergence of Data and Processes December 20, 2012 30 / 45
  42. 42. Reasoning about Artifacts as Dynamic Entities We want to provide a formal foundation for artifact-centric systems, and provide corresponding reasoning facilities for their trustworthy design. In particular, we want to decide whether dynamic/temporal properties of interest hold over the life of such systems. • Verification of temporal formulae. • Dominance/simulation/bisimulation/containment properties. • Automated composition of artifacts-based systems. • Automated process synthesis from dynamic/temporal specifications. Currently (2010’s) the scientific community is quite good at each of these, but only in a finite setting! However, artifacts pose two challenging problems: • the presence of data makes them infinite-state systems; • properties need to accommodate temporal operators and queries over the artifact information models → first-oder temporal formulae. Marco Montali Towards Convergence of Data and Processes December 20, 2012 30 / 45
  43. 43. Verification of Artifacts is Tough What is a non-artifact example of a finite-state control process manipulating possibly unbounded data? Marco Montali Towards Convergence of Data and Processes December 20, 2012 31 / 45
  44. 44. Verification of Artifacts is Tough What is a non-artifact example of a finite-state control process manipulating possibly unbounded data? Turing machine Halt curState == qf Transition done ... status attributes curState cellscurCell curCell = curCell.next; Head moved if curCell.next == null newCell = createCell(); newCell.value = "_"; curCell.next = newCell; newCell.prev = curCell; newCell.next = null; Tape extended if curCell.next != null curCell = createCell(); curCell.value = "_"; curState = q0;Initialized if curCell == null MovedR ... curCell.value = vR1'; curState = qR1'; if curState = qR1 && curCell.value = vR1 R1 state updated ... curCell.value = vRk'; curState = qRk'; if curState = qRk && curCell.value = vRk Rk state updated ...value prev next Transition stage State update stages Init stage Right shift stage (left transitions) (Left shift stage) . . .. . . Verification of the propositional CTL ∩ LTL reachability property “eventually milestone Halt achieved” is undecidable. Marco Montali Towards Convergence of Data and Processes December 20, 2012 31 / 45
  45. 45. Artifact Formal Foundations Is there hope to find interesting decidable cases? • This requires to identify “classes of systems” that enjoy verifiability. • First step: devise a minimal, clean mathematical framework as the basis of investigation. • Many approaches in the literature: University California San Diego, University California Santa Barbara, IBM Watson, Imperial College, Sapienza Universit`a di Roma, Free University of Bozen-Bolzano. Starting from previous work, we have defined a very rich “pristine” formal framework: Data-Centric Dynamic Systems. Note: approaches based on multi-dimensional modal logics (one dimension for data, one dimension for process) are not suitable. • Undecidability holds already for rigid roles. • No hope to isolate an interesting class. Marco Montali Towards Convergence of Data and Processes December 20, 2012 32 / 45
  46. 46. Data-Centric Dynamic Systems (DCDS) Data layer Process layer DCDS Data Layer: Relational database. • Relational schema (with constraints). • Database instance: state of the DCDS. Process Layer: • Atomic actions with params: relate the current database to the next. • Process: condition-action rules to select applicable actions+params. • Service calls: incorporation of fresh values into the system Deterministic services: e.g., historical exchange rate of Euro/USD Nondeterministic services: e.g., current exchange rate of Euro/USD Account for incoming event payloads (GSM) or user-input. Minimal interaction between the two layers:Levesque functional approach. • ASK queries, obtaining certain answers. • TELL facts, asserting new information. Marco Montali Towards Convergence of Data and Processes December 20, 2012 33 / 45
  47. 47. DCDS Example Data Layer Information about hotels and their price: • Cur = Currency • CurHotel = Hotel, Currency • PEntry = Hotel, Price Process Layer Possibility of converting the price list of a hotel from USD dollars to another currency. • Nondet. service for price conversion: conv usd(price, currency) • Process: Cur(c) ∧ CurHotel(h, US ) −→ Conv(h, c) • Conv(h, c) :   PEntry(h, p) ∧ Cur(c) PEntry(h, conv usd(p, c)) CurHotel(h, cold) ∧ Cur(c) CurHotel(h, c) Copy Rest    Marco Montali Towards Convergence of Data and Processes December 20, 2012 34 / 45
  48. 48. Execution Semantics: Infinite-State Transition Systems Cur(EUR) Hotel(h,80) CurHotel(h,USD) Marco Montali Towards Convergence of Data and Processes December 20, 2012 35 / 45
  49. 49. Execution Semantics: Infinite-State Transition Systems Cur(EUR) Hotel(h,80) CurHotel(h,USD) Conv(h1,EUR) call conv_usd(80,EUR) Marco Montali Towards Convergence of Data and Processes December 20, 2012 35 / 45
  50. 50. Execution Semantics: Infinite-State Transition Systems Cur(EUR) Hotel(h,80) CurHotel(h,USD) Conv(h1,EUR) call conv_usd(80,EUR) Cur(EUR) Hotel(h,10) CurHotel(h,EUR) Cur(EUR) Hotel(h,90) CurHotel(h,EUR) Cur(EUR) Hotel(h,160) CurHotel(h,EUR) Marco Montali Towards Convergence of Data and Processes December 20, 2012 35 / 45
  51. 51. Execution Semantics: Infinite-State Transition Systems Cur(EUR) Hotel(h,80) CurHotel(h,USD) Conv(h1,EUR) call conv_usd(80,EUR) other executable actions Cur(EUR) Hotel(h,10) CurHotel(h,EUR) Cur(EUR) Hotel(h,90) CurHotel(h,EUR) Cur(EUR) Hotel(h,160) CurHotel(h,EUR) other results Three possible sources of infinity/unboundedness: • infinite branching; • infinite runs; • unbounded database. Marco Montali Towards Convergence of Data and Processes December 20, 2012 35 / 45
  52. 52. Verification formalisms Remember: verification is undecidable even for propositional reachability properties and very simple DCDSs. . . We study variants of FO µ-calculus + bisimulations. Formulae can talk only of a fixed set of constants. HML PDLLTL CTL µL µLFO Marco Montali Towards Convergence of Data and Processes December 20, 2012 36 / 45
  53. 53. Verification formalisms Remember: verification is undecidable even for propositional reachability properties and very simple DCDSs. . . We study variants of FO µ-calculus + bisimulations. Formulae can talk only of a fixed set of constants. 1st variant: µLA. FO quantification over current active domain. • E.g.: along every run, for each student x appearing in the database, there exists a run leading to graduation of x. HML PDLLTL CTL µL µLFO µLA Marco Montali Towards Convergence of Data and Processes December 20, 2012 36 / 45
  54. 54. Verification formalisms Remember: verification is undecidable even for propositional reachability properties and very simple DCDSs. . . We study variants of FO µ-calculus + bisimulations. Formulae can talk only of a fixed set of constants. 1st variant: µLA. FO quantification over current active domain. • E.g.: along every run, for each student x appearing in the database, there exists a run leading to graduation of x. 2nd variant: µLP. FO quantification only holds over persisting individuals. • E.g.: it is always true that, whenever an artifact id is present in the information model, the corresponding artifact will be destroyed (i.e., the id will disappear) or reach a state where all its stages are closed. HML PDLLTL CTL µL µLFO µLA µLP Marco Montali Towards Convergence of Data and Processes December 20, 2012 36 / 45
  55. 55. Conditions Run-bounded DCDS: every run cannot accumulate more than a fixed bound of different values. • Still infinite-state due to infinite branching. State-bounded DCDS: every database instance cannot contain more than a fixed bound of different values. • Relaxation of run-boundedness. • Runs could be infinite, due to infinitely many values encountered in its states. • Such values cannot however accumulate in the same state. These are semantic conditions, whose checking is undecidable. We have defined sufficient, checkable syntactic conditions that guarantee them. Marco Montali Towards Convergence of Data and Processes December 20, 2012 37 / 45
  56. 56. Results Theorem Verification of µLA over run-bounded DCDSs is decidable and can be reduced to model checking of propositional µ-calculus over a finite transition system. Idea: use isomorphic types instead of actual values. Remember: runs are bounded! ............ ... Marco Montali Towards Convergence of Data and Processes December 20, 2012 38 / 45
  57. 57. Results Theorem Verification of µLA over run-bounded DCDSs is decidable and can be reduced to model checking of propositional µ-calculus over a finite transition system. Idea: use isomorphic types instead of actual values. Remember: runs are bounded! ............ ... non a-bisimilar a-bisimilar Marco Montali Towards Convergence of Data and Processes December 20, 2012 38 / 45
  58. 58. Results Theorem Verification of µLA over run-bounded DCDSs is decidable and can be reduced to model checking of propositional µ-calculus over a finite transition system. Idea: use isomorphic types instead of actual values. Remember: runs are bounded! Marco Montali Towards Convergence of Data and Processes December 20, 2012 38 / 45
  59. 59. Results Theorem Verification of µLA over state-bounded DCDSs is undecidable. Idea: the logic can arbitrarily quantify over the infinitely many values encountered during a single run, and start comparing them. Technical proof: satisfiability of LTL with freeze quantifier can be encoded as a model checking problem of µLA formulae over state-bounded DCDSs. Marco Montali Towards Convergence of Data and Processes December 20, 2012 39 / 45
  60. 60. Results Theorem Verification of µLP over run-bounded DCDSs is decidable and can be reduced to model checking of propositional µ-calculus over a finite transition system. Steps: 1 Prune infinite branching (isomorphic types). ... non p-bisimilar p-bisimilar ............ ... ... ... ... Marco Montali Towards Convergence of Data and Processes December 20, 2012 40 / 45
  61. 61. Results Theorem Verification of µLP over run-bounded DCDSs is decidable and can be reduced to model checking of propositional µ-calculus over a finite transition system. Steps: 1 Prune infinite branching (isomorphic types). 2 µLP looses track of previous values that do not exist anymore. When these values re-appear, they are interpreted as new, fresh ones. → Completely new values can be replaced with old, non-persisting ones. This eventually leads to recycle the old values without generating new ones. ... ... ... Marco Montali Towards Convergence of Data and Processes December 20, 2012 40 / 45
  62. 62. Results Theorem Verification of µLP over run-bounded DCDSs is decidable and can be reduced to model checking of propositional µ-calculus over a finite transition system. Steps: 1 Prune infinite branching (isomorphic types). 2 µLP looses track of previous values that do not exist anymore. When these values re-appear, they are interpreted as new, fresh ones. → Completely new values can be replaced with old, non-persisting ones. This eventually leads to recycle the old values without generating new ones. Marco Montali Towards Convergence of Data and Processes December 20, 2012 40 / 45
  63. 63. Conclusion • Need of holistic view of data+process. • Artifact-centric systems provide a promising answer to this requirement. • Verification of artifact-centric systems is a very challenging problem. Promising results are being produced, which also pave the way towards implementation. • Connection with other ongoing proposals: active XML, object-centric BPM, collaboration hubs, (adaptive) case management. • Foundations of artifact-centric systems combine many interesting areas of computer science: Knowledge Representation, Logic and Databases, AI, Formal Methods. Marco Montali Towards Convergence of Data and Processes December 20, 2012 41 / 45
  64. 64. Ongoing/Future Work • Application of DCDSs for the verification of GSM-based artifacts. • Further results both in the relational and knowledge-based setting (semantic artifacts, Knowledge and Action Bases). • Inconsistency-tolerant systems. • Bidirectional mappings to propagate information from the relational to the semantic layer and back. • Synthesis of semantic artifacts using knowledge-based game structures and our FO µ-calculus variants. • Implementation of the abstraction technique and embedding into a state-of-the-art model checker. • Link with organizational modeling, services (broad meaning) and commitments. Marco Montali Towards Convergence of Data and Processes December 20, 2012 42 / 45
  65. 65. Case Management • Seminal work by van der Aalst et al. (2005): traditional BPM, data fragmentation and the “blind surgeon” metaphor. • Case management philosophy: the process works over shared, visible data structures whose lifecycle is attached to the case. • Adaptive case management: exploits such shared data to deal with unpredictable/unforeseen situations; dynamic (re)planning of pathways; ad-hoc changes. → underspecification of processes; → flexibility by design and at run-time. • Concrete technologies: FLOWer by Pallas Athena (first case management system). Cordys: state machine-based process with declarative applicability rules and dynamic planning steps. IBM Case Manager: GSM-like approach centred on documents (case folders). Many similarities between the two paradigms! Marco Montali Towards Convergence of Data and Processes December 20, 2012 43 / 45
  66. 66. CMMN: Case Management Modeling and Notation Emerging OMG Standard for declarative case management. • Submitters: BizAgi, Cordys, IBM, Oracle, SAP, Singularity. • Co-authors: Agile Enterprise Design, SINTEF, TIBCO, Trisotech. Based on GSM abstraction Initiate Request Order Create Material Orders + - Planning Orders Manage Suppliers All Items Ordered Order cancelled Advanced state machines Marco Montali Towards Convergence of Data and Processes December 20, 2012 44 / 45
  67. 67. Thanks! Talk End Questions a   iSC   Marco Montali Towards Convergence of Data and Processes December 20, 2012 45 / 45

×