1 / 24

Timed Data-Centric Analysis of Graphical Business Process Models in Reo

This paper discusses the use of Reo, a channel-based coordination language, for formalizing and analyzing business process models. It explores the formalization of models with Reo, translation to mCRL2, and various analysis techniques. The paper also presents a case study on an auction process and discusses related work and future directions.

mmunoz
Download Presentation

Timed Data-Centric Analysis of Graphical Business Process Models in Reo

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Timed data-centric analysis of graphical business process models in Reo Natallia Kokash and Christian Krause Centrum Wiskunde & Informatica (CWI) Erik de Vink, TU Eindhoven The Netherlands SEFM 2010, 15/09/2010 1

  2. 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 timesupport • Abstraction • Tool support • Example – Auction process • Related work • Conclusions and future work SEFM 2010, 15/09/2010 2

  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 SEFM 2010, 15/09/2010 3

  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

  5. 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 usingthe 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 5

  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

  9. 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 9

  10. 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 (actiona happens at time t) • Parallel composition:a||b (interleavingsa.b + b.a + a|b) • Actions and processes can be parametrized with data • Summation:∑d∈Da(d) (a(d1) + a(d2) + a(d3)…) SEFM 2010, 15/09/2010 10

  11. mCRL2 specification language • Renaming:ρR(a) where Ris 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 11

  12. 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 12

  13. Channel composition A B C D A B|C →E D B A D C B B A D A A Synchronize and hide actions corresponding to the connected channels Reduce the size of the state space while building the LTS for the mCRL2 specification of a Reo connector byIterated connector construction • P0 = ∂ends of connected channels(Γhandshaking at Node1(Node1 || Sync1|| LossySync1|| LossySync2|| SyncDrain1)) • P1 = ∂ends of connected channels(Γhandshaking at Node2(Node2 || Sync2|| Sync3|| P0 )) • P2 = ∂ends of connected channels (Γhandshaking at Node3(Node3 || Sync4||P1)) • P3 = ∂ends of connected channels (Γhandshaking at Node4(Node4 || Sync5||P2 )) SEFM 2010, 15/09/2010 13

  14. Correctness of the mapping • N. Kokash, C. Krause, and E. de Vink, “Verification ofcontext-dependent channel-based service models,” in Proc.FMCO 2009, ser. LNCS. Springer, 2010. SEFM 2010, 15/09/2010

  15. 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 15

  16. 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 16

  17. 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 17

  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

  23. 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 23

  24. 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. SEFM 2010, 15/09/2010 24

More Related