SEFM 2010, 15/09/2010 11

Timed data-centric analysis of graphical business process

models in ReoNatallia Kokash and Christian Krause

Centrum Wiskunde & Informatica (CWI)Erik de Vink, TU Eindhoven

The Netherlands

SEFM 2010, 15/09/2010 22

Overview Channel-based coordination language Reo

Graphical notation, semantic models Formalization of business process models with Reo mCRL2 specification language and model checking toolset Translation from Reo to mCRL2

Basic mapping Compositional translation Data and time support Abstraction

Tool support Example – Auction process Related work Conclusions and future work

SEFM 2010, 15/09/2010 3

Motivation: analysis of business processes

Goal: automatically analyze workflow models

Safety properties “Something bad will not happen”

Liveness properties “Something good will eventually happen”

Control flow analysis Deadlocks/livelocks/temporal constraints in data-agnostic

models Data flow analysis

Deadlocks/livelocks/temporal constraints in data-aware models (with multiple variables, abstract data types and data manipulation)

Service compatibility checking

3

SEFM 2010, 15/09/2010 4

Channel-based coordination with Reo

Channels are binary components that define constraints on input and output data items

Channel ends (ports) can be both source ends or both sink ends

Channel ends can be joint together and form source, sink or mixed nodes

Source nodes behave like synchronous replicators Sink nodes behave like non-deterministic mergers

SEFM 2010, 15/09/2010 55

Formalization of business process models with Reo

Arbab, F., N. Kokash and M. Sun, Towards using Reo for Compliance-aware Business Process, ISoLA 2008 (2008), pp. 108–123.

Tasharofi, S., M. Vakilian, R. Z. Moghaddam and M. Sirjani, Modeling web service interactions using the coordination language Reo, Proc. of the Int. Workshop on Web Services and Formal Methods, LNCS 4937 (2008), pp. 108–123.

Changizi, B., Kokash, N., Arbab, F.: A Unified Toolset for Business Process Model Formalization, proc of the Int. Workshop on Formal Engineering approaches to Software Components and Architectures (FESCA), 2010.

SEFM 2010, 15/09/2010 6

Semantic models for Reo

Basic model Constraint automata (Baier, C., Sirjani, M., Arbab, F., Rutten, J.: Modeling

Component Connectors in Reo by Constraint Automata. Science of Computer Programming 61 (2006) 75–113)

Reo with context dependent channels Coloring semantics (Clarke, D., Costa, D., Arbab, F.: Connector coloring I:

Synchronization and context dependency. Science of Computer Programming 66 (2007) 205–225)

Intentional automata (Costa, D.: Formal Models for Context Dependent Connectors for Distributed Software Components and Services. PhD thesis, CWI (2010))

Reo automata (Bonsangue, M., Clarke, D., Silva, A.: Automata for context-dependent connectors. In: Proc. Coordination’ 09. Volume 5521 of LNCS., Springer (2009) 184–203)

Reo with timed channels Timed constraint automata (Arbab, F., Baier, C., de Boer, F., Rutten, J.:

Models and temporal logical specifications for timed component connectors. Software and Systems Modeling 6(1) (2007) 59–82)

Reo with probabilistic channels Probabilistic constraint automata (Baier, C.: Probabilistic models for Reo

connector circuits. Journal of Universal Computer Science 11(10) (2005) 1718–1748)

SEFM 2010, 15/09/2010 7

Constraint automata semantics for basic Reo channels and nodes

SEFM 2010, 15/09/2010 8

(Timed) constraint automata

A constraint automaton

SEFM 2010, 15/09/2010 99

mCRL2

Behavioral specification language Associated toolset

Developed at TU Eindhoven (+ LaQuSo, CWI and Twente University)

Based on the algebra of communicating processes (ACP)

Extended with data and time Built-in data types: Bool, Nat, Pos, Int, Real Algebraic data types

constructors, recognition and projection functions Built-in support for lists, sets and bags User-defined functions (λ calculus)

Number of industrial case studies http://www.mcrl2.org/

SEFM 2010, 15/09/2010 1010

mCRL2 specification language

Actions are atomic events (e.g. a firing of a port or a request arrival in a Reo connector)

Processes are the active entities defined as expressions over actions and other processes Multiaction: a|b (synchronized actions) Alternative composition: a + b (nondeterministic choice) Sequence composition: a.b (b started after a) Conditional: exp → a ◊ b (if-then-else) At operator: act (action a happens at time t) Parallel composition: a||b (interleavings a.b + b.a + a|b)

Actions and processes can be parametrized with data Summation: ∑d∈D a(d) (a(d1) + a(d2) + a(d3)…)

SEFM 2010, 15/09/2010 1111

mCRL2 specification language

Renaming: ρR(a) where R is a set of renamings of the form b → c, meaning that every occurrence of b in a is replaced by c

Hiding: τH(a) renames all actions of H in a to τ

Restriction (allow): ∇R(a) where R specifies which actions are allowed to occur in a

Blocking: ∂B(a) where B is a set of actions that is not allowed to occur in a

Communication: ΓC(p), where C is a set of allowed communications of the form a0|...|an→ c, n ≥1 which means that every group of actions a0|...|an within a multiaction is replaced by an action c

SEFM 2010, 15/09/2010 1212

Reo to mCRL2 (Constraint automata semantics)

Data flow observed at a channel end = action Synchronous channel, synchronous drain

Sync = A|B.Sync; Non-deterministic synchronous lossy channel

LossySync = (A|B + A).LossySync; Asynchronous drain

AsyncDrain = (A + B).AsyncDrain; FIFO

Fifo = A.B.Fifo; FullFifo = B.Fifo; Alternative encoding: Fifo(f: Bool) = (¬f → A ◊ B).Fifo(¬f);

Replication node ReplicationNode = X|Y|Z.ReplicationNode;

Merge node MergeNode = (X|Z + Y|Z).MergeNode;

SEFM 2010, 15/09/2010 13

1. P0 = ∂ends of connected channels(Γhandshaking at Node1(Node1 || Sync1 || LossySync1 || LossySync2 || SyncDrain1))

2. P1 = ∂ends of connected channels(Γhandshaking at Node2(Node2 || Sync2 || Sync3 || P0 ))

3. P2 = ∂ends of connected channels (Γhandshaking at Node3(Node3 || Sync4 || P1 ))

4. P3 = ∂ends of connected channels (Γhandshaking at Node4(Node4 || Sync5 || P2 ))

13

Channel composition

Reduce the size of the state space while building the LTS for the mCRL2 specification of a Reo connector by Iterated connector construction

A

A

B

D

A

B

A

B

C

D

A B C D A B|C →E D

Synchronize and hide actions corresponding to the connected channels

SEFM 2010, 15/09/2010 14

Correctness of the mapping

N. Kokash, C. Krause, and E. de Vink, “Verification of context-dependent channel-based service models,” in Proc. FMCO 2009, ser. LNCS. Springer, 2010.

SEFM 2010, 15/09/2010 1515

Reo to mCRL2: Data support

act A, B: Data Sync = ∑d∈Data . A(d)|B(d) . Sync; SyncDrain = ∑d1,d2 ∈Data . A(d1)|B(d2) . SyncDrain; LossySync = ∑d∈Data . (A(d)|B(d) + A(d)) . LossySync; AsyncDrain = ∑d∈Data . (A(d) + B(d)) . AsyncDrain; Filter = sum ∑d∈Data . (exp(d) → A(d)|B(d) ◊ A(d)). Filter, where exp(d)

is a boolean expression Transformer = ∑d∈Data . A(d)|B(exp(d)) . Transformer; ReplicationNode = ∑d∈Data . X(d)|Y(d)|Z(d) . ReplicationNode; MergeNode = ∑d∈Data . (X(d)|Z(d) + Y(d)|Z(d)) . MergeNode;

FIFO DataFIFO = struct empty?isEmpty | full(e:Data)?isFull;

Fifo(f: DataFIFO) = ∑d∈Data isEmpty(f)→A(d).Fifo(full(d)) ◊ B(e(f)).Fifo(empty))

SEFM 2010, 15/09/2010 1616

Reo to mCRL2: Global data types

A connector should deal with any data items consumed by its source nodes

Given a set of elementary data types DT1,…,DTn (e.g., inferred from web service interface specifications), the global data type is described as follows: Data = struct D1(e1: DT1)|…|Dn(e1: DTn)

JoinNode = ∑ d1,d2 ∈Data. (X(d1)|Y(d2)|Z(tuple(d1, d2)).JoinNode;

For m-join node tuple(e1: Data, e2: Data,…, em: Data) is added to the Data description, e.g., Data = struct D1(e1: DT1)|…|Dn(e1: DTn) |tuple(e1: Data, e2: Data)

Note: expressions for filter and transformer channels become dependent on the structure of the Reo connector

SEFM 2010, 15/09/2010 1717

Reo to mCRL2: time support

T-timer with off- and reset- options Reacts differently to different data inputs:

DataTimer = struct reset?isReset | off?isOff | timeout | other(e: Data)?isOther

Has two states State = struct OFF?isOFF | ON?isON

State s (timer ON or OFF), current time x, timer delay t Timer(s: State, x: Real, t: Real ) =

isOFF(s)→∑d∈DataTimer isOther(d)→A(d).Timer(ON, 0, t) + isON (s) → ((x < t) → ∑d∈DataTimer

isReset(d) → A(d).Timer(ON, 0, t) + isOff (d) → A(d).Timer(OFF, x, t) + tickcx.Timer(ON, x + 1, t))

◊ B(timeout).Timer(OFF, x, t)

SEFM 2010, 15/09/2010 18

Abstraction

SEFM 2010, 15/09/2010 19

Case study: auction process with data transformation

SEFM 2010, 15/09/2010 20

Tool support

SEFM 2010, 15/09/2010 21

LTS and examples of control flow and timed properties

SEFM 2010, 15/09/2010 22

LTS and examples of data flow properties

Input constraints:

SEFM 2010, 15/09/2010 2323

Comparison of model checking tools for Reo Vereofy (University of Dresden) http://www.vereofy.de/

Developed specifically for Reo and Constraint Automata Dedicated property specification format Counterexamples No support for abstract data types Global domain for all components Primitive data constraint specification language (for filter channels)

mCRL2 toolset http://www.mcrl2.org/ Powerful support for data Rich property specification format (μ calculus) Hard to extract counterexamples Inability to define some useful data domains Performance depends on the structure of the program

CADP toolset (INRIA) http://www.inrialpes.fr/vasy/cadp/ Compatible with the generated mCRL2 code (.lps →.aut) Efficient model checking + other useful functionality (e.g., model-

based testing, performance evaluation, advanced action sequence search)

License

SEFM 2010, 15/09/2010 2424

Conclusions and future work

Model checking for Reo Control + data flow analysis with abstract data types Automated generation of mCRL2 code from graphical models

Useful toolset for business process and service composition analysis Good alternative to Petri nets Better fits service-oriented computing paradigm Compositional modeling and analysis

Future work Extend the mCRL2 property specification language with some

missing but useful features: The ability to check that some action occurs as part of a multi-action The ability to refer to the system states by combination of data values

stored in FIFO buffers.