seminar@fbk-irst 2012 - montali - towards convergence of data and processes: the artifact-centric...

Towards Convergence of Data and ProcessesThe Artifact-Centric Approach

Marco Montali

KRDB Research Centre for Knowledge and DataFree University of Bozen-Bolzano

December 20, 2012 - Trento

Marco Montali Towards Convergence of Data and Processes December 20, 2012 1 / 45

Outline

• From activity-centric to artifact-centric BPM.I Credits to the ACSI team, in particular Marlon Dumas.

• Artifact-centric modeling.I Credits to the ACSI team.

• Foundations of artifact-centric systems and their formal verification.I Joint work with Diego Calvanese and the KRDB “process+data”

subgroup, Giuseppe De Giacomo and colleagues, Alin Deutsch.


Traditional Process Modeling• Structural modeling of the domain of interest:

conceptual models, domain ontologies, database schemasI UML, ORM, ER, . . .

• Behavioral modeling of the domain of interest:activities, services, business processes

I BPMN, EPC, UML, BPEL, SOA-related technologies, . . .

• A divide et impera approach, to attack the complexity of the domain.


Build-to-Order Process

1. Customer PO

• Customer can cancel the order at any time (penalty management).



1. Customer PO

2. order decomposition

Material PO

Line item

Customer PO




3. Selection and interaction with suppliers

1. Customer PO


Material PO

Line item

Customer PO





1. Customer PO


Material PO

Line item

Customer PO

4. material assembly





1. Customer PO


Material PO

Line item

Customer PO


5. Shipment





1. Customer PO


Material PO

Line item

Customer PO


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

Traditional Approach

Manage Cancelation

ShipAssembleManageMaterial POs

DecomposeCustomer PO

• Value chain construction

• Break-down of each phase into business functions.• Further decomposition:

I data component (domain description).I activities (units of work) + process component (control-flow).

• Impedance mismatch: data and process divide!


Traditional Approach

Manage Cancelation



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:

I data component (domain description).I activities (units of work) + process component (control-flow).

• Impedance mismatch: data and process divide!


BPMN ModelHigh‐LevelBPMNModel

4


Data Modeling

Customer PO Line Item

Work OrderMaterial PO

*

*

spawns

0..1

Material


Distribution of Responsibility

Supplier

ManufacturingProcurement/Supplier

Sales



*

*

spawns

0..1

Material


Cancelation Business Rule

Supplier

ManufacturingProcurement/Supplier

Sales



*

*

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

penaltyNotify penalty

Material

Process Engine

Process State


Spaghetti Layer

Manage Cancelation



Activities

Process

Data

Activities

Process

Data

Activities

Process

Data

Activities

Process

Data

Activities

Process

Data

Customers Suppliers&CataloguesCustomer POs Work Orders Material POs


Conceptual Modeling vs ArchitecturesArchitectures 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


Conceptual Model or Conceptual Models?

• Business stakeholders have a single conceptualization of theirbusiness.

• IT provides support for several loosely-coupled conceptual models ofthe organization:

I rules and policies;I analytics, dashboards, key performance indicators;I activity-centric business processes;I data.

• Lack of a coherent, holistic view:I process data redundancy;I business rules redundancy.


Rosenquist and Evolving, Living Entities (1982)

C. J. ROSENQUIST

Professor Dijkstra was also quoted for his criticism ofthe computer science fraternity for its sensitivity both tofads and fashions and to the market place. These trendswere described as symptoms of immaturity: 'Write apaper promising salvation, make it structured somethingor a virtual something or abstract or distributed or higherorder applicative, and you can be almost certain ofhaving started a new cult.' He continued: 'An unmistak-able symptom of maturity in computer science would bea consensus "about what matters" among its leaders.'

The present paper is an attempt to apply computerscience to 'what matters' and to get away from the 'L'artpour l'art' principle adopted by most computer scientistsand computer science educational institutions. The paperdescribes research carried out as part of a set ofcommercial projects in a business environment, and thesolutions and tools described have all been applied to theimplementation of a number of information systems. Anumber of methods and techniques are provided fordescription of what Dijkstra calls the 'Uniprogrammingtrace' as a sequence of states and events, for relation ofthese uniprogramme descriptions in a multi-directionalframework (network of entity life cycles), thus illustratingthe information systems life history.

The content of the paper is based on research anddevelopment carried out in an attempt to combinemodelling using Petri-nets4 and finite state machines fordesign and verification of computer systems, as describedin papers presented at the Infotec State-of-the-ArtSeminar Database 75s and in the Asian Computer YearBook.6

Information systems development life cycle

The triangular logo used in Fig. 1 illustrates the stages ofan information systems development life cycle. In thislogo each stage in the life cycle is covering an area of thetriangle proportional to the amount of work anddocumentation processed during the stage.

This paper will cover in brief the stages jointly referredto as 'data analysis' and will extend the coverage to 'datastructure and program design'. The parts of data analysisand program design, which are known under severalsynonyms, e.g. functional analysis, top-down design,structured design, functional decomposition, etc., will becovered in more detail, as the emphasis of this paper ison the dynamic aspects of entities and entity modelling.

Figure 2 illustrates the stages covered in this paper andshows the information flow between these. As illustratedin the figure, data analysis essentially consists of twoseparate analytical areas, entity analysis and functionalanalysis.

The basic phases of entity analysis are (i) preliminaryentity modelling, (ii) conceptual entity modelling, (iii)detailed entity modelling, (iv) verification and consoli-dation with entity life cycle documentation, and (v)access path analysis.

The basic phases of functional analysis are (i) establishapplication areas and define first level of entity life cycleanalysis, (ii) entity life cycle analysis, (iii) detailed lifecycle analysis, (iv) verification and consolidation withconceptual entity models and (v) access path analysis.

DATA ANALYSIS

Figure 2. The stages involved in data analysis and the informationflow between them.

Basic diagrammatic conventions and construction primi-tives used

The documentation of observations and the design of thesystems and data structures are assumed to be gatheredin a common information systems encyclopaedia, asshown in Fig. 2. This could be any manual or automatedsystem conforming to the outline design specified by theData Dictionary Working Party of the BCS.7

The basic concept of this information systems encyclo-paedia is the division of the meta data about information,and the relation between the information and the systems(manual systems included) using it, into four categories,i.e. the four quadrants of a circle, each covering 90° ofthe total picture.

As illustrated in Fig. 2 the information held in thesequadrants will gradually be supplied during the followingstages: (a) conceptual analysis stage, (b) detailed analysisstage and (c) design stage.

At the time of implementation and live running all thedocumentation should be readily available for DP stafffor enquiry in order to ease the burden of maintenance.

The information systems encyclopaedia created duringthe stages mentioned above is illustrated in Fig. 3. Theboundaries between the four quadrants in the informationsystems encyclopaedia are traversed by bidirectionalrelationships covering all relevant meta data, e.g. (i)process to entities and vice versa, (ii) functions to moduleswhich implement the functions, (iii) files to the entitiesrepresented, (iv) programs to the items (e.g. pointers)they utilize.

The information used to establish the cross-boundaryrelationships is the information concerned with the

3 0 8 THE COMPUTER JOURNAL, VOL. 25, NO. 3,1982 © Heyden & Son Ltd, 1982

at Free University of B

olzano on Decem

ber 19, 2012http://com

jnl.oxfordjournals.org/D

ownloaded from


Rosenquist and Evolving, Living Entities (1982)

ENTITY LIFE CYCLE MODELS AND THEIR APPLICABILITY TO INFORMATION SYSTEMS DEVELOPMENT

•THE REAL WORLD-

•IHEIMPL EMENTATION'

Figure 3. The information systems encyclopaedia concept 'the realworld'.

dynamics of the object system. This paper is concentrat-ing on the task of arriving at this information and thedescription (modelling) of this.

In order to achieve this, the information systemsencyclopaedia is utilized as a common reference framefor the analysis process. The meta languages used fordiagrammatic representation of the structures compiledin the four quadrants are chosen in order to provide themaximal ease of understanding for the parties involvedin the different aspects of the development cycle.

Figure 4 illustrates the meta languages utilized in eachof the quadrants, a detailed description of the metalanguages is provided in Appendices 1-4.

'The real world' process structures. The real world processstructure should be described in the systems encyclopae-dia in terms of conceptual descriptions of events affectingthe processing of entity occurrences, and conceptualdescriptions of the processing involved. These descrip-tions should be related to the states of the entities inquestion in a precedence network showing the interde-pendencies of processes, states and events. The method-ology used for this purpose is described under the separateheading 'entity life cycle analysis'.

•WE REAL WORLD

PROGRAM STRUCTURES• Functional hierarchiesMA Jackson notation

PHYSICAL DATA STRUCTURES• Extended Bachman notation(depending on the implementation vehicle)

'THE IMPLEMENTATtON'

Figure 4. The meta languages utilized to communicate theinformation system structures related to the systems encyclopaedia'the real world'.

'The real world' entity model. Various schemes have beensuggested for the modelling of real world data structures,or more concisely conceptual entity models. Most of theschemes are based on the Bachman diagrams.8 The metalanguage notation suggested in this paper has beenchosen with the following objectives in mind: (i) toprovide as many details as required, (ii) to be significantlydifferent from the implementation level meta languagenotation, (iii) to be easy to draw and (iv) to be easy tocomprehend and hence distinguish between entity typesand entity occurrences.

The reasoning behind the objectives set out above forthe meta language selection, deserve a few comments.The conceptual level documentation of an entity modelis used as a means of communication between DP peopleand users, hence has to relate as much as possible to theusers' world, i.e. it is necessary to have details which arerelevant to the end user of the documentation. Thesecould, for example, be names of attributes, since attributenames often are more real to an end user than an abstract,all embracing, entity name.

The conceptual level entity model is a user relatedmodel of the real world, and should not be confused withwhat is implemented, hence the necessity to make theappearance of the conceptual entity model as differentfrom the implementation model as possible, i.e. it is nogood to use Bachman diagrams or variations of thesediagrams for both 'real world' models and 'implementa-tion models'.

The conceptual model is a very volatile model, whichwill go through a great number of iterations, hence shouldbe easy to draw.

The end users are normally not familiar with theconcept of entity types and entity occurrences, hence therequirement to distinguish between entity types andentity occurrences in the meta language used at this levelof the documentation procedure.

The only meta language notation the author has beenable to trace in the literature which fulfils all theseobjectives is the Lindgreen notation.9 An enhancedversion of the Lindgreen notation is explained in detailin Appendix 2 of this report.

'The implementation' systems/program structure. At this levelof the documentation procedure the sequence of events,states and processes should be defined in terms of entitylife cycle diagrams. These diagrams and their implemen-tation in a computer system, provide the initial algorithmsfor selection of programs and subprograms. The finaldocumentation of the actual program design and thefunctions within a program are best documented usingthe meta language originally developed by M. A. Jacksonand briefly mentioned in Appendix 3.

'The implementation' database/file structure. At this level ofthe documentation process, the meta language descrip-tion of the database and file structure is purely for thebenefit of the DP professionals working with theimplementation of the information system, hence themeta language used should be as close as possible to thesyntax of the implementation vehicle used.

The most well known implementation level metalanguage notation for communication of database struc-tures, is the extended Bachman diagram. The Bachmandiagram is known to have been extended for IDMS (ICL,

©Heyden& Son Ltd, 1982 THE COMPUTER JOURNAL. VOL. 25, NO. 3,1982 3 0 9

at Free University of B

olzano on Decem

ber 19, 2012http://com

jnl.oxfordjournals.org/D

ownloaded from


Business Artifacts on the Rescue

• Rosenquist’s vision did not become reality. . .• . . . but the data-process divide problem became more and more

pressing.I Richardson (Forrester) at BPM 2010: “Data and process are two sides

of the same coin”.I 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.I Data must be modeled taking into account that they will be

manipulated by processes.I 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.


What is an Artifact?

DefinitionA key, business-relevant conceptual dynamic entity that is used in guidingthe 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 possibleevolutions.


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?


ACSI Artifact Paradigm


A3M: ACSI Artifact Abstract Model

An abstract (i.e., data and processagnostic) model for representing thekey concepts of an artifact system.






















artifact

event

environmentgateway

• 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 theexternal 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.I Lifecycle: intra-artifact constraints relating artifact phases across time.


Interoperation HubExtension of A3M to support multi-party service interoperation.






















artifact

event

environmentgateway

service

participant

organisational info

authorisationview








new artifact


Separation Principle and Semantic LayerThe 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 relationshipsrelevant for the domain of interest.

I Unified view of the whole system.I Interconnection of different artifacts that share information, though

with different representation.I Support to new artifacts in understanding how they could attach to the

information maintained by other artifacts.I Specification of queries as well as static and dynamic constraint at the

conceptual level.• Govern the artifact system:

I regulating the introduction of new artifacts and processes in the system;I 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

Semantically-governed A3MSemantic layer: I-HUB’s conceptual schema (TBox) composed of semanticconstraints that define the “data boundaries” of the artifact system.

TBox


Semantically-governed A3MReal data are concretely maintained at the artifact layer.Snapshot: database instances of artifacts, events and gateways.

Da

Db

Dc

Artifact System Snapshot

TBox


Semantically-governed A3MEach snapshot is conceptualized in the ontology, in terms of an ABox.Mappings define how to obtain the virtual ABox from the concrete datasources.

Da

Db

Dc


Mappings

Semantic Layer Snapshot

TBox

ABox1


Semantically-governed A3MThe system evolves thanks to actions/processes executed over the artifactlayer.Semantic layer used to understand the evolution at the conceptual level.

Da

Db

Dc


D'a

D'b

D'c


Actionexecution

Mappings Mappings


TBox

ABox1

TBox


ABox2


Semantically-governed A3MSemantic governance: semantic layer used to regulate the actions’execution at the artifact layer. Actions leading to violate the semanticconstraints are rejected.

Da

Db

Dc


D'a

D'b

D'c


Actionexecution

Mappings Mappings


TBox

ABox1

TBox


ABox2


Artifact Concrete ModelsSome concrete information models:

• Relational database (with nested records).• (Description Logic) Knowledge base.

Some concrete lifecycle models:• Finite-state machines. State = phase; events trigger transitions.

I Implemented in the Siena IBM prototype.• Proclets (interacting Petri nets).

I Emphasise many-to-many relationships between artifacts.• Guard-Stage-Milestone lifecycles, based on declarative ECA-like rules.

I Implemented in the Barcelona IBM prototype.Marco Montali Towards Convergence of Data and Processes December 20, 2012 26 / 45

Guard-Stage-Milestone ArtifactsInformation model: nested records.Lifecycle: constituted by

• Events, triggering the progression of the lifecycle. External eventsinject fresh data into the system, internal events mark changes of thelifecycle state.

• Atomic tasks, used to create/destroy artifacts and to interact withthe environment. Implemented using service.

• Sentries, logical formulae combining an optional triggering event anda query over the information model (using OCL).

• Milestones, business-relevant objectives at different levels ofgranularity. Can be achieved by making the corresponding sentry true,invalidated otherwise.

• Stages, cluster of tasks and sub-stages that jointly concur to theachievement of some milestones.

• Guards, sentries used to control the activation of a correspondingstage. Whenever a guard becomes true, the stage opens and musteventually reach a milestone to become closed.


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 : intstatus : {...}

Order

prodName : stringProduct Type

Component TypecompName : stringprice : intcolor : string

ComponentProduct

companyName : stringCompany

SSN : stringaddress : string {0..n}

Customer

1..1 1..n

fulfills

suppliedBy1..1 assembledBy

shippedBy

Ptype Ctype

1..1

orderFor

1..1

madeOf 1..1

makesOrder

• GSM status attributes: open/closed stages, achieved/invalidatedmilestones.


Build-To-Order Process in GSM - Customer PO Lifecycle

Researching Ordering Assembling

allresearched

one ordered

comp.received

submitted shipped

Submitting Shipping

humantask

humantask

automatictask

automatictask

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

allassembled

[receiveComp](Assembler)

Fulfilling

orderassembled

Processing

orderreceived

ordercancelled

Diamond: guard. Rounded rectangle: stage. Circle: milestone.Sentries are partially hidden.Arrows denote dependencies on certain status attributes.


Reasoning about Artifacts as Dynamic EntitiesWe want to provide a formal foundation for artifact-centric systems, andprovide corresponding reasoning facilities for their trustworthy design.

In particular, we want to decide whether dynamic/temporal properties ofinterest 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.


Reasoning about Artifacts as Dynamic EntitiesWe want to provide a formal foundation for artifact-centric systems, andprovide corresponding reasoning facilities for their trustworthy design.

In particular, we want to decide whether dynamic/temporal properties ofinterest 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

Verification of Artifacts is ToughWhat is a non-artifact example of a finite-state control processmanipulating possibly unbounded data?

Turing machine

HaltcurState == 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.


Verification of Artifacts is ToughWhat is a non-artifact example of a finite-state control processmanipulating possibly unbounded data? Turing machine

HaltcurState == 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.


Artifact Formal FoundationsIs 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:

I University California San Diego, University California Santa Barbara,IBM Watson, Imperial College, Sapienza Universita di Roma, FreeUniversity of Bozen-Bolzano.

I 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 dimensionfor data, one dimension for process) are not suitable.

• Undecidability holds already for rigid roles.• No hope to isolate an interesting class.


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

I Deterministic services: e.g., historical exchange rate of Euro/USDI 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.


DCDS ExampleData LayerInformation about hotels and their price:

• Cur = 〈Currency〉• CurHotel = 〈Hotel,Currency〉• PEntry = 〈Hotel,Price〉

Process LayerPossibility of converting the price list of a hotel from USD dollars toanother currency.

• Nondet. service for price conversion: conv usd(price, currency)• Process: Cur(c) ∧ CurHotel(h, ′US′) 7−→ 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


Execution Semantics: Infinite-State Transition Systems

Cur(EUR)

Hotel(h,80)CurHotel(h,USD)

Three possible sources of infinity/unboundedness:• infinite branching;• infinite runs;• unbounded database.



Cur(EUR)


Conv(h1,EUR)call conv_usd(80,EUR)




Cur(EUR)



Cur(EUR)

Hotel(h,10)CurHotel(h,EUR)

Cur(EUR)


Cur(EUR)





Cur(EUR)



otherexecutable

actions

Cur(EUR)


Cur(EUR)


Cur(EUR)


other results



Verification formalismsRemember: verification is undecidable even for propositional reachabilityproperties 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 currentactive domain.

• E.g.: along every run, for each student x appearingin the database, there exists a run leading tograduation of x.

2nd variant: µLP . FO quantification only holds overpersisting individuals.

• E.g.: it is always true that, whenever an artifact idis present in the information model, thecorresponding artifact will be destroyed (i.e., the idwill disappear) or reach a state where all its stagesare closed.

HML

PDLLTL CTL

µL

µLFO

µLA

µLP


Conditions

Run-bounded DCDS: every run cannot accumulate more than a fixedbound of different values.

• Still infinite-state due to infinite branching.

State-bounded DCDS: every database instance cannot contain more thana 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 havedefined sufficient, checkable syntactic conditions that guarantee them.


ResultsTheoremVerification of µLA over run-bounded DCDSs is decidable and can bereduced to model checking of propositional µ-calculus over a finitetransition system.

Idea: use isomorphic types instead ofactual values.

Remember: runs are bounded!

......

......

...





......

......

...

non a-bisimilar

a-bisimilar


Results

TheoremVerification of µLA over state-bounded DCDSs is undecidable.

Idea: the logic can arbitrarily quantify over the infinitely many valuesencountered during a single run, and start comparing them.

Technical proof: satisfiability of LTL with freeze quantifier can be encodedas a model checking problem of µLA formulae over state-bounded DCDSs.


ResultsTheoremVerification of µLP over run-bounded DCDSs is decidable and can bereduced to model checking of propositional µ-calculus over a finitetransition system.

Steps:1 Prune infinite branching (isomorphic types).

2 µLP looses track of previous valuesthat do not exist anymore. When thesevalues re-appear, they are interpreted asnew, fresh ones.→ Completely new values can bereplaced with old, non-persisting ones.This eventually leads to recycle the oldvalues without generating new ones.

...

non p-bisimilar

p-bisimilar

......

......

...

...

...

...



Steps:1 Prune infinite branching (isomorphic types).2 µLP looses track of previous values

that do not exist anymore. When thesevalues re-appear, they are interpreted asnew, fresh ones.→ Completely new values can bereplaced with old, non-persisting ones.This eventually leads to recycle the oldvalues without generating new ones.

...

...

...



Steps:1 Prune infinite branching (isomorphic types).2 µLP looses track of previous values

that do not exist anymore. When thesevalues re-appear, they are interpreted asnew, fresh ones.→ Completely new values can bereplaced with old, non-persisting ones.This eventually leads to recycle the oldvalues without generating new ones.


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 waytowards implementation.

• Connection with other ongoing proposals: active XML, object-centricBPM, collaboration hubs, (adaptive) case management.

• Foundations of artifact-centric systems combine many interestingareas of computer science: Knowledge Representation, Logic andDatabases, AI, Formal Methods.


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) andcommitments.


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

I unpredictable/unforeseen situations;I dynamic (re)planning of pathways;I ad-hoc changes.

→ underspecification of processes;→ flexibility by design and at run-time.

• Concrete technologies:I FLOWer by Pallas Athena (first case management system).I Cordys: state machine-based process with declarative applicability rules

and dynamic planning steps.I IBM Case Manager: GSM-like approach centred on documents (case

folders).F Many similarities between the two paradigms!


CMMN: Case Management Modeling and NotationEmerging 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

InitiateRequest Order

Create Material Orders

+-

Planning Orders

Manage Suppliers

All Items Ordered

Order cancelled

Advanced state machines


Thanks!

TalkEnd

Questions

a i S C Marco Montali Towards Convergence of Data and Processes December 20, 2012 45 / 45

seminar@fbk-irst 2012 - montali - towards convergence of data and processes: the artifact-centric...

Presentations & Public Speaking