1 / 81

FMCO’06 Amsterdam 7-10 November 2006

Abstraction and Compositional Verification Techniques for Asynchronously Communicating Components Marjan Sirjani Tehran University, IPM. FMCO’06 Amsterdam 7-10 November 2006. A joint work with Ali Movaghar Frank de Boer Acknowledgements to Michael Huth Mohammad Reza Mousavi

etoile
Download Presentation

FMCO’06 Amsterdam 7-10 November 2006

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

More Related