Скачать презентацию Translating Reo to m CRL 2 Natallia Kokash Скачать презентацию Translating Reo to m CRL 2 Natallia Kokash

6530ebff6a1f7f33670964f5c0b83eea.ppt

  • Количество слайдов: 34

Translating Reo to m. CRL 2 Natallia Kokash Joint work with Christian Krause and Translating Reo to m. CRL 2 Natallia Kokash Joint work with Christian Krause and Erik de Vink Technical University of Eindhoven, 14/01/2010 1

Introduction § Motivation § Basics of Reo and m. CRL 2 § Translation from Introduction § Motivation § Basics of Reo and m. CRL 2 § Translation from Reo to m. CRL 2 § Constraint automata encoding § Data flow modeling § Timed constraint automata § Context-dependency § Intentional automata encoding – approach and problems § Encoding based on coloring semantics § Testing new semantics of Reo § Reo circuits with data transfer delays § Tool support § Conclusions and future work Technical University of Eindhoven, 14/01/2010 2

Motivation: analysis of business processes BPMN 2 Reo converter UML 2 Reo converter Technical Motivation: analysis of business processes BPMN 2 Reo converter UML 2 Reo converter Technical University of Eindhoven, 14/01/2010 3

Formalization of business processes Reo 2 Extended. Automata converters § Сheck that admissible states Formalization of business processes Reo 2 Extended. Automata converters § Сheck that admissible states reject or send. Form. Out are eventually reached § G(request → F (reject ∪ send. Form. Out)) Technical University of Eindhoven, 14/01/2010 4

Motivation: analysis of business processes § Safety properties § “Something bad will not happen” Motivation: analysis of business processes § 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 § Service compatibility checking § Check whether a message sent by one service will be accepted by another service § Multiple variables and abstract data types § Data transformation Technical University of Eindhoven, 14/01/2010 5

Reo coordination language § Components (services) communicate through channels composed to complex connectors § Reo coordination language § Components (services) communicate through channels composed to complex connectors § Semantics: § Constraint automata § Intentional automata (support for context-dependency) Technical University of Eindhoven, 14/01/2010 6

m. CRL 2 § Behavioral specification language § Associated toolset § Developed at TU m. CRL 2 § Behavioral specification language § Associated toolset § Developed at TU Eindhoven (+ La. Qu. So, 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. mcrl 2. org/ Technical University of Eindhoven, 14/01/2010 7

m. CRL 2 specification language § Actions are atomic events (e. g. a firing m. CRL 2 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(d 1) + a(d 2) + a(d 3)…) Technical University of Eindhoven, 14/01/2010 8

m. CRL 2 specification language § Renaming: ρR(a) where R is a set of m. CRL 2 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 a 0|. . . |an→ c, n ≥ 1 which means that every group of actions a 0|. . . |an within a multiaction is replaced by an action c Technical University of Eindhoven, 14/01/2010 9

Example of m. CRL 2 specification Dining philosophers eqn K = 2; map K: Example of m. CRL 2 specification Dining philosophers eqn K = 2; map K: Pos; act get, put, up, down, lock, free: Pos#Pos; eat: Pos; proc Phil(n: Pos) = get(n, n). get(n, if (n == K, 1, n+1)). eat(n). put(n, if (n == K, 1, n+1)). Phil(n); Fork(n: Pos) = sum m: Pos. up(m, n). down(m, n). Fork(n); init allow( { lock, free, eat }, comm( { get|up->lock, put|down->free }, Phil(1) ||. . . || Phil(K) || Fork(1) ||…|| Fork(K) )); Technical University of Eindhoven, 14/01/2010 10

Example of m. CRL 2 specification Brief overview of the m. CRL 2 toolset: Example of m. CRL 2 specification Brief overview of the m. CRL 2 toolset: § Process linearization § mcrl 22 lps § Linear Transition System (LTS) generation § lps 2 lts § LTS minimization (e. g. , branching bisimilarity) § § ltsconvert LTS visualization § ltsgraph Other tools (simulation, converters, etc. ) m. CRL 2 model checker § Works on LPS specification § lps 2 pbes –formula=[formula]. mcf lps. File pbes. File § pbes 2 bool pbes. File Dining philosophers Technical University of Eindhoven, 14/01/2010 11

Reo to m. CRL 2 (Constraint automata semantics) § Data flow observed at a Reo to m. CRL 2 (Constraint automata semantics) § Data flow observed at a channel end = action § Synchronous channel, synchronous drain § Sync = A|B. Sync; § Non-deterministic synchronous lossy channel § Lossy. Sync = (A|B + A). Lossy. Sync; § Asynchronous drain § Async. Drain = (A + B). Async. Drain; § FIFO 1 = A. B. FIFO 1; § Full. FIFO 1 = B. FIFO 1; § Alternative encoding: FIFO 1(f: Bool) = (¬f → A ◊ B). FIFO 1(¬f); § Replication node § Replicator = X|Y|Z. Replicator; § Merge node § Merger = (X|Z + Y|Z). Merger; Technical University of Eindhoven, 14/01/2010 12

Reo to m. CRL 2: Data support act A, B: Data § Synchronous channel Reo to m. CRL 2: Data support act A, B: Data § Synchronous channel § Sync = ∑d∈Data. A(d)|B(d). Sync; § Synchronous drain § Synchronous lossy channel § Asynchronous drain § Filter § Transformer § Replication node § Merge node § Sync. Drain = ∑d 1, d 2 ∈Data. A(d 1)|B(d 2). Sync. Drain; § Lossy. Sync = ∑d∈Data. (A(d)|B(d) + A(d)). Lossy. Sync; § Async. Drain = ∑d∈Data. (A(d) + B(d)). Async. Drain; § 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(f(d)). Transformer; § Replicator = ∑d∈Data. X(d)|Y(d)|Z(d). Replicator; § Merger = ∑d∈Data. (X(d)|Z(d) + Y(d)|Z(d)). Merger; § FIFO 1 § Data. FIFO 1 = struct empty? is. Empty | full(e: Data)? is. Full; § FIFO 1(f: Data. FIFO 1) = ∑d∈Data is. Empty(f)→A(d). Fifo 1(full(d)) ◊ B(e(f)). FIFO 1(empty)) Technical University of Eindhoven, 14/01/2010 13

Reo to m. CRL 2: Global data types § A connector should deal with Reo to m. CRL 2: Global data types § A connector should deal with any data items consumed by its source nodes § Given a set of elementary data types DT 1, …, DTn (e. g. , inferred from web service interface specifications), the global data type is described as follows: § Data = struct D 1(e 1: DT 1)|…|Dn(e 1: DTn) § Join node § Join = ∑ d 1, d 2 ∈Data. (X(d 1)|Y(d 2)|Z(tuple(d 1, d 2)). Join; § For m-join node tuple(e 1: Data, e 2: Data, …, em: Data) is added to the Data description, e. g. , § Data = struct D 1(e 1: DT 1)|…|Dn(e 1: DTn) |tuple(e 1: Data, e 2: Data) § Note: expressions for filter and transformer channels become dependent on the structure of the Reo connector Technical University of Eindhoven, 14/01/2010 14

Reo to m. CRL 2: Timed constraint automata § T-timer with off- and reset- Reo to m. CRL 2: Timed constraint automata § T-timer with off- and reset- options § Reacts differently to different data inputs: § Data. Timer = struct reset? is. Reset | off? is. Off | timeout | other(e: Data)? is. Other § Has two states § State = struct OFF? is. OFF | ON? is. ON § State s (timer ON or OFF), current time x, timer delay t § Timer(s: State, x: Real, t: Real ) = is. OFF(s)→∑d∈Data. Timer is. Other(d)→A(d). Timer(ON, 0, t) + is. ON (s) → ((x < t) → ∑d∈Data. Timer is. Reset(d) → A(d). Timer(ON, 0, t) + is. Off (d) → A(d). Timer(OFF, x, t) + tickcx. Timer(ON, x + 1, t)) ◊ B(timeout). Timer(OFF, x, t) Technical University of Eindhoven, 14/01/2010 15

Reo to m. CRL 2: Composition Synchronize and hide actions corresponding to the connected Reo to m. CRL 2: Composition Synchronize and hide actions corresponding to the connected channels A B C D A B|C →τ D § Problem § Reduce the size of the state space while building the LTS for the m. CRL 2 specification of a Reo connector § Idea § Iterated connector construction B A A B B A D C 1. P 0 = ∂ends of connected channels(Γhandshaking at Node 1(Node 1 || Sync 1 || Lossy. Sync 2 || Sync. Drain 1)) 2. P 1 = ∂ends of connected channels(Γhandshaking at Node 2(Node 2 || Sync 3 || P 0 )) 3. P 2 = ∂ends of connected channels (Γhandshaking at Node 3(Node 3 || Sync 4 || P 1 )) 4. P 3 = ∂ends of connected channels (Γhandshaking at Node 4(Node 4 || Sync 5 || P 2 )) Technical University of Eindhoven, 14/01/2010 16

Performance evaluation Technical University of Eindhoven, 14/01/2010 17 Performance evaluation Technical University of Eindhoven, 14/01/2010 17

Correctness of the mapping: proof idea Example: synchronous FIFO 1 Axiomatization and SOS semantics Correctness of the mapping: proof idea Example: synchronous FIFO 1 Axiomatization and SOS semantics of m. CRL 2: Groote, J. F. , Mathijssen, A. , Reniers, M. , Usenko, Y. , van Weerdenburg, M. : The formal specification language m. CRL 2. In: Proc. Methods for Modelling Software Systems. Number 06351 in Dagstuhl Seminar Proceedings (2007) Technical University of Eindhoven, 14/01/2010 18

Intentional automata encoding § Two types of actions: § A channel end is ready Intentional automata encoding § Two types of actions: § A channel end is ready to write/read (i. A) § Data flow observed at a channel end (o. A) § Synchronous channel, synchronous drain § Sync(a: Bool, b: Bool) = ¬a → i. A. Sync(¬a, b) + ¬b → i. B. Sync(a, ¬ b) + (a ⋀ b) → o. A|o. B. Sync(¬a, ¬b); § Context independent lossy channel § Lossy. Sync(a: Bool, b: Bool) = ¬a → i. A. Lossy. Sync(¬a, b) + ¬b → i. B. Lossy. Sync(a, ¬ b) + a → (b → o. A|o. B. Lossy. Sync(¬ a, ¬b) + o. A. Lossy. Sync (¬a, b)); § Context dependent lossy channel § Lossy. Sync(a: Bool, b: Bool) = ¬a → i. A. Lossy. Sync(¬a, b) + ¬b → i. B. Lossy. Sync(a, ¬ b) + a → (b → o. A|o. B. Lossy. Sync(¬ a, ¬b) + ¬b → o. A. Lossy. Sync (¬a, b)); Technical University of Eindhoven, 14/01/2010 19

Intentional automata encoding: problems § By default channels do not transmit data and need Intentional automata encoding: problems § By default channels do not transmit data and need explicit commands to do so (request arrival actions) § One request arrival action per time § Many extra states are generated that show the propagation of the information about request arrival § Restriction operator is needed Lossy. Sync can lose data because it does not know that the buffer became empty (i. C|i. B has to happen first) § Solutions: § Encoding of coloring semantics using m. CRL 2 actions with data (Christian) § By default each channel transmits data, an explicit command is needed to block certain ports (generated when some FIFO 1 becomes full), and unblock them later (when some FIFO 1 becomes empty) – similar to the coloring semantics, but several different actions are without data are used. Technical University of Eindhoven, 14/01/2010 20

Encoding based on coloring semantics Sort Colored = struct flow(data : Data) | noflow. Encoding based on coloring semantics Sort Colored = struct flow(data : Data) | noflow. G | noflow. R Act A, B: Colored; § Synchronous channel § Sync = (∑d∈Data. A(flow(d)) | B(flow(d)) +. A(noflow. G) | B(noflow. R) +. A(noflow. R) | B(noflow. G) +. A(noflow. G) | B(noflow. G)). Sync; § Lossy channel § Lossy. Sync = (∑d∈Data. A(flow(d)) | B(flow(d)) +. A(flow(d)) | B(noflow. G) +. A(noflow. G) | B(noflow. R) +. A(noflow. G) | B(noflow. G)). Lossy. Sync; § Merge node Merger = (∑d∈Data. A(flow(d)) | B(noflow. R) | C(flow(d)) + A(noflow. R) | B(flow(d)) | C(flow(d)) + A(noflow. G) |B(noflow. G) | C(noflow. R) + A(noflow. R) | B(noflow. R) | C(noflow. G)). Merger Technical University of Eindhoven, 14/01/2010 21

Coloring semantics Two colors Three colors Technical University of Eindhoven, 14/01/2010 22 Coloring semantics Two colors Three colors Technical University of Eindhoven, 14/01/2010 22

Lossy FIFO 1 Constraint automata Coloring semantics Technical University of Eindhoven, 14/01/2010 23 Lossy FIFO 1 Constraint automata Coloring semantics Technical University of Eindhoven, 14/01/2010 23

Lossy FIFO 1 Technical University of Eindhoven, 14/01/2010 24 Lossy FIFO 1 Technical University of Eindhoven, 14/01/2010 24

Synchronous transactions with explicit data flow modeling t 1 t 2 t 1 t Synchronous transactions with explicit data flow modeling t 1 t 2 t 1 t 3 t 2 t 4 t 3 t 5 § t 2 >> t 1 § Data transfer delay: § This automaton does not allow § max(t 1, t 2)+max(t 3, t 4, t 5) or multiple transitions {A, B} while C is § max(t 1+max(t 3, t 4), t 2+max(t 3, t 5)) reading data. Technical University of Eindhoven, 14/01/2010 25

Synchronous transactions with explicit data flow modeling § Actions observed in a port A: Synchronous transactions with explicit data flow modeling § Actions observed in a port A: § § § block (b. A) start data flow (s. A) finish data flow (f. A) unblock (u. A) Port behavior: b. A. s. A. f. A. u. A Sync Lossy. Sync § Synchronous channel § b. A|b. B. s. A|s. B. f. A|f. B. u. A|u. B § Lossy. Sync § b. A|b. B. s. A|s. B. f. A|f. B. u. A|u. B + b. A. s. B. f. B. u. B FIFO 1 § FIFO 1 (empty) § b. A. s. A. f. A. u. A. b. B. s. B. f. B. u. B § Sync. Drain § b. A|b. B. (s. A. f. A || s. B. f. B). u. A|u. B § Async. Drain § b. A. s. A. f. A. u. A + b. B. s. B. f. B. u. B Sync. Drain Async. Drain Technical University of Eindhoven, 14/01/2010 26

Synchronous transactions with explicit data flow modeling § “Block” and “unblock” actions are synchronized Synchronous transactions with explicit data flow modeling § “Block” and “unblock” actions are synchronized as in constraint automata A § Source/source B § s. A|s. B A B § Sink/Source § f. A|s. B § Sink/sink Merge node § b. X|b. Z. s. X|s. Z. f. X|f. Z. u. X|u. Z + b. Y|b. Z. s. Y|s. Z. f. Y|f. Z. u. Y|u. Z § Performance analysis: § Port A pumps data = state between s. A and f. A § Time delays can be assigned to “finish” actions Technical University of Eindhoven, 14/01/2010 27

Automata with data flow constraints A BX Z C DY t 3 t 2 Automata with data flow constraints A BX Z C DY t 3 t 2 t 1 Technical University of Eindhoven, 14/01/2010 28

Tool support Technical University of Eindhoven, 14/01/2010 29 Tool support Technical University of Eindhoven, 14/01/2010 29

Data-flow analysis with m. CRL 2 § No deadlock: § [true*]<true>true § No livelock: Data-flow analysis with m. CRL 2 § No deadlock: § [true*]true § No livelock: § [true*]mu X. [tau]X § Loan request is always denied or approved: § Data agnostic: § nu X. [true]X && mu Y. ([!(denied || approved)]Y && true) § Data aware: § nu X. [true]X && forall d: Data. mu Y. ([!(denied(d) || approved(d))]Y && true) Technical University of Eindhoven, 14/01/2010 30

Loan request scenario: different instances Salary = 1000 Salary = 2000 Salary = 3000 Loan request scenario: different instances Salary = 1000 Salary = 2000 Salary = 3000 Technical University of Eindhoven, 14/01/2010 31

Comparison of model checking tools for Reo § Vereofy (University of Dresden) § Advantages: Comparison of model checking tools for Reo § Vereofy (University of Dresden) § Advantages: § Developed for Reo and Constraint Automata § Counterexamples § Disadvantages: § No support for abstract data types § Global domain for all components § Primitive data constraint specification language (for filter channels) § m. CRL 2 § Advantages: § Powerful support for data § Rich property specification format § Disadvantages: § Hard to extract counterexamples § For infinite domains model checker often does not terminate if data constraints present in formula being verified (problems with algorithms formulae rewriting? ) Technical University of Eindhoven, 14/01/2010 32

Conclusions § Full featured model checking for Reo § Control + data flow analysis Conclusions § Full featured model checking for Reo § Control + data flow analysis § Abstract data types § Complete tool support § Automated generation of m. CRL 2 code from graphical models § First implemented plug-in that deals with filter and transformer channels § Eclipse Coordination Tools § Interesting toolset for business process and service composition analysis § Good alternative to Petri nets § Better suits service-oriented computing paradigm Technical University of Eindhoven, 14/01/2010 33

Future Work § Work on tools usability § Analysis across several connectors § Obtaining Future Work § Work on tools usability § Analysis across several connectors § Obtaining data types from WSDL specifications § Describe arbitrary components in m. CRL 2 (not only readers/writers) § LTS to LPS conversion? § Integrate other verification tools (e. g. , CADP, simulators) § Timed Reo § Implement the converter § What properties can be checked with m. CRL 2? § Reo with data transfer delays § Implement the converter § How can we support performance analysis? Technical University of Eindhoven, 14/01/2010 34