FMCO’06 Amsterdam 7-10 November 2006

1. Abstraction and Compositional Verification Techniques for AsynchronouslyCommunicating ComponentsMarjan SirjaniTehran University, IPM FMCO’06 Amsterdam 7-10 November 2006

2. A joint work with • Ali Movaghar • Frank de Boer • Acknowledgements to • Michael Huth • Mohammad Reza Mousavi • Rebeca Group at Tehran and Sharif Universities M. Sirjani, FMCO'06

3. Outline • Motivation • Actor-based Language Rebeca • Compositional Verification of Rebeca • Introducing Components • Supporting Tools • Conclusion • Future Work M. Sirjani, FMCO'06

4. Motivation Establishing a • formal verification method, • easy to use for practitioners, for developing reliable systems in concurrent and distributed applications. Formal verification method: Modeling language + Verification mechanism M. Sirjani, FMCO'06

5. The Idea • Actor-based modeling language, • plus component notion, • and formal verification support. Asynchronous message passing in actor-based modeling  makes the verification problem difficult Inherent modularity and encapsulation  provide some solutions: abstraction and modular verification M. Sirjani, FMCO'06

6. Outline • Motivation • Actor-based Language Rebeca • Compositional Verification of Rebeca • Introducing Components • Supporting Tools • Conclusion • Future Work M. Sirjani, FMCO'06

7. Actor • A reference model for concurrent computation • Consisting of concurrent, distributed active objects Proposed by Hewitt as an agent-based language (MIT, 1971) Developed by Agha as a concurrent object-based language (Illinois, since 1984) M. Sirjani, FMCO'06

8. Rebeca • Reactive object language • An operational interpretation of actor language • Formal semantics • Abstraction and Compositional verification approach • Model checking tool Introduced by Sirjani and Movaghar, 2001 M. Sirjani, FMCO'06

9. Key Features of Rebeca • Actor-based computational model • Units of concurrency and distribution: Reactive objects • Simple and natural • Objects are threads. • Formal semantics • Labeled transition system • A solid basis for verification M. Sirjani, FMCO'06

10. Key Features … • Asynchronous communication • Increases the decoupling • Buffers lead to state space explosion in model checking • Abstraction and compositional verification approaches • Reduce the state space • Exploite the actor-based semantics to abstract the model • Preserving a set of behavioral specifications in temporal logic M. Sirjani, FMCO'06

11. Other Features • Object-based language, Java like syntax • Encapsulation of data and process, no shared variable • Easy to use by software engineers • Tool supported • Model checking Rebeca code using back-end model checkers • Automated abstraction and compositional verification • Symmetry and static Partial order reduction M. Sirjani, FMCO'06

12. Added Feature • Grouping a set of reactive objects as an open component • Allow a set of more tightly coupled objects to be grouped as a component • A higher level of abstraction in software design • Considering a strategy to keep the verification theory sound M. Sirjani, FMCO'06

13. Compositional Verification Decomposing the model into components Composing the model from re-usable components Abstraction Rebeca Language Actor-based Rebeca Verifier Tools Properties Closed model Components Modere Rebeca Direct Model Checker Partial order reduction - Symmetry SMV Promela (NuSMV) (Spin) Back-End Model Checkers

14. Rebeca Model • Communication: • Asynchronous message passing • Unbounded message queue for each rebec • No explicit receive • Computation: • Take a message from top of the queue and execute it • Event-driven M. Sirjani, FMCO'06

15. In the execution of a message server, a rebec may • Execute an assignment • Evaluate a condition • Send a message • The messages are asynchronous • No-way blocking (sender, receiver) • No explicit receive, arrives in the message queue of the receiver M. Sirjani, FMCO'06

16. Dynamic Behavior • Dynamic topology • Dynamic rebec creation (runtime) (not considered in compositional verification) M. Sirjani, FMCO'06

17. Operational Semantics • The state of a rebec, is the valuation of • state variables, and • the unbounded buffer (queue) for incoming messages. • The state of the system, is the product of • local object states • A state transition: • an atomic execution of a method off the top of the rebec’s queue. M. Sirjani, FMCO'06

18. An Example: Bridge Controller • There is a two-way bridge. • Trains may arrive at each side. • At the same time two trains should not be on the bridge. • There are green/red lights on each side. • A train goes on the bridge if the light is green. M. Sirjani, FMCO'06

19. passed passed Train1 Train2 Arrive Arrive Leave Leave Bridge Controller YouMayPass YouMayPass

20. Example: Rebeca code reactiveclass Train { knownobjects {BridgeController controller;} statevars{ … } msgsrv … … } reactiveclass BridgeController { knownobjects{Train t1; Train t2;} statevars{ … } msgsrv … … } main { BridgeController theController (t1, t2); Train t1 (theController); Train t2 (theController); }

21. Trains

22. Bridge Controller

23. Outline • Motivation • Actor-based Language Rebeca • Compositional Verification of Rebeca • Introducing Components • Supporting Tools • Conclusion • Future Work M. Sirjani, FMCO'06

24. Formal Verification • Two general approaches • Model checking: Algorithmic verification • Theorem proving: Deductive verification M. Sirjani, FMCO'06

25. Model Checking of Real Systems • State explosion problem • Solution: • Modularity • Abstraction M. Sirjani, FMCO'06

26. Compositional Verification • proving properties of components (as open systems in an arbitrary environment) by model checking, and • deducing the whole system’s property from the properties of its components. C |= P C’ |= Q P  Q R ----------- C || C’ |= R M. Sirjani, FMCO'06

27. Useful if the model is inherently modular. • Environment Problem. Note: We need assume-guarantee reasoning. We only consider LTL and ACTL properties. M. Sirjani, FMCO'06

28. Inherent Modularity in Rebeca • Rebecs are inherently • Independent, decoupled, encapsulated • Because of • Asynchronous message passing • no explicit receive statement • no shared variables => Leads to natural modularity and abstraction techniques M. Sirjani, FMCO'06

29. Rebeca verification approach • Exploit the inherent modularity and encapsulation of the model to apply • Compositional verification • Property preserving abstraction Can be used for any system based on asynchronous message passing and actor-based computation. M. Sirjani, FMCO'06

30. Compositional verification details … • Decompose a model into components, • verify some specific properties for these components, and • then deduce the system’s property from the properties of its components. This deduction is sound, due to the weak simulation relation. (betweena component in a model and its parallel composition with another arbitrary component in the same model.) M. Sirjani, FMCO'06

31. Decompose a model into components: • Model the environment as incoming messages (external messages): M={C,Ec} • Abstracting the environment from its concrete behavior (state variables). • Abstract the queue from external messages: Ca M. Sirjani, FMCO'06

32. Decomposing a system into components: Internal messages: coming from internal rebecs External messages: coming from external rebecs.

33. Semantics of a Component • Values for all variables of all internal rebecs. • A multi-queue: one message-queue for each internal rebec. • A set of external messages always present. Properties: based on rebecs’ state variables. M. Sirjani, FMCO'06

34. The Environment: Automatic Generation • The Environment of a component C: EC • sending all the possible messages to C • Nondeterministically • Unboundedly • EC can be automatically derived from the system. • No state variable • Servicing no messages • Just sending messages to C • The composition of C and EC makes a closed model M=(C, EC). M. Sirjani, FMCO'06

35. Bridge Controller Example passed • Receiving ‘Arrive’ or ‘Leave’ from the environment, arbitrarily (not blocking the component). Train1 Arrive Arrive Leave Leave Bridge Controller YouMayPass YouMayPass

36. Bridge Controller Example

37. Abstracting the Message Queue • No external messages (messages coming from EC) in the Queue • External messages are assumed to be always present and are modeled by transitions of Ca. M. Sirjani, FMCO'06

38. Bridge Controller Example Train as a component M. Sirjani, FMCO'06

39. States and Transition s1 External messages e1 Constant set … e1 e2 e3 s2 e2 s0 e3 s3 i1 ... i2 i2 i1 Internal messages sl sk Multi-queue

40. Formally speaking: • Let • ∑(M) be the transition system of M={C,Ec} • ∑(Ca) be the transition system generated by the transition relation considering queue abstraction • ∑(M’) be the transition system of any model M’ containing C • We have the following weak simulation relations: • ∑(Ca) weakly simulates ∑(M) (Queue Abstraction) • ∑(M) weakly simulates ∑(M’) (Component Composition)

41. We have the following weak simulation relations: • ∑(Ca) ≤ ∑(M) (Queue Abstraction) • ∑(M) ≤ ∑(M’) (Component Composition) • And the property preservation theorem • Safety properties (LTL-X, ACTL-X) are preserved due to weak simulation. • Hence • ∑(Ca) |= φ→∑(M) |= φ, for M={C,Ec} • ∑(M) |= φ→∑(M’) |= φ, for an arbitrary model M’ containing C.

42. Summary Having a model M, and a component C (a sub-model of M), we can derive the environment ECfor C. For every safety property, specified by LTL-X or ACTL-X formula, with atomic propositions on variables in C, Ca |= P implies C||C’||EC||C’ |= P M. Sirjani, FMCO'06

43. Abstraction Techniques:Summary • Abstracting environment as external messages • Bounded queues • Abstracting external messages • Queue length in model checking • Check overflow, supported by tool • Course grained interleaving • Method execution as a transition (Atomic method execution) • Conventional data abstractions M. Sirjani, FMCO'06

44. One more point:Symmetry Reduction Techniques • We may use symmetry for state space reduction • Like in dining philosophers (Ring-like topologies) • The permutation relation shall preserve both rebec types and known-rebec relation. M. Sirjani, FMCO'06

45. Dining Philosophers Component C1 Component C5 Component C2 Component C4 Component C3  (i=0,n ¬(phili.fr  phili+1.fl))

46. Component C1 External message from the right fork of philosopher 0 External message from theleft fork of philosopher 1 Component C1: phil0 || fork0 || phil1 Property:  (¬(phil0.fr  phil1.fl))

47. Outline • Motivation • Actor-based Language Rebeca • Compositional Verification of Rebeca • Introducing Components • Supporting Tools • Conclusion • Future Work M. Sirjani, FMCO'06

48. What we had: • decomposing a model for verification purposes • in a top-down manner. • What we added: • notion of components • re-usable parts • fixed proven specifications • build a system in bottom-up fashion. M. Sirjani, FMCO'06

49. Introducing Components • Introducing components for modeling purposes, • As an additional higher level of abstraction in modeling • Enriching the model of computation M. Sirjani, FMCO'06

50. Components • Components are sets of reactive objects • Components interact • via broadcasting • asynchronous • anonymous messages => No need to put a name for a component. No need to know the names of the rebecs inside a component (for communication). Just know the service you want. M. Sirjani, FMCO'06