Abstraction and Compositional Verification Techniques for Asynchronously Communicating Components Marjan Sirjani Tehran University, IPM

1
Abstraction and Compositional Verification
Techniques for AsynchronouslyCommunicating
ComponentsMarjan SirjaniTehran University, IPM

• FMCO06
• 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

3
Outline

• Motivation
• Actor-based Language Rebeca
• Compositional Verification of Rebeca
• Introducing Components
• Supporting Tools
• Conclusion
• Future Work

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

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

6
Outline

• Motivation
• Actor-based Language Rebeca
• Compositional Verification of Rebeca
• Introducing Components
• Supporting Tools
• Conclusion
• Future Work

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)

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

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

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

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

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

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

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

16
Dynamic Behavior

• Dynamic topology
• Dynamic rebec creation (runtime)
• (not considered in compositional verification)

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

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.

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
• knownobjectsTrain t1 Train t2
• statevars
• msgsrv
• main
• BridgeController theController (t1, t2)
• Train t1 (theController)
• Train t2 (theController)

21
Trains
reactiveclass Train(3) knownobjects statevars boolean onTheBridge msgsrv initial() onTheBridge false self. ReachBridge() msgsrv YouMayPass() onTheBridge true self.Passed() msgsrv Passed() onTheBridge false controller.Leave() self.ReachBridge() msgsrv ReachBridge() controller.Arrive()
22
Bridge Controller
reactiveclass BridgeController(3) knownobjects statevars boolean isWaiting1 boolean isWaiting2 boolean signal1 boolean signal2 msgsrv initial() signal1 false / red / signal2 false / red / isWaiting1 false isWaiting2 false msgsrv Arrive() msgsrv Leave()
23
Outline

• Motivation
• Actor-based Language Rebeca
• Compositional Verification of Rebeca
• Introducing Components
• Supporting Tools
• Conclusion
• Future Work

24
Formal Verification

• Two general approaches
• Model checking Algorithmic verification
• Theorem proving Deductive verification

25
Model Checking of Real Systems

• State explosion problem
• Solution
• Modularity
• Abstraction

26
Compositional Verification

• proving properties of components (as open
  systems in an arbitrary environment) by model
  checking, and
• deducing the whole systems property from the
  properties of its components.
• C P
• C Q
• P ? Q ? R
• -----------
• C C R

27

• Useful if the model is inherently modular.
• Environment Problem.
• Note
• We need assume-guarantee reasoning.
• We only consider LTL and ACTL properties.

28
Inherent Modularity in Rebeca

• Rebecs are inherently
• Independent, decoupled, encapsulated
• Because of
• Asynchronous message passing
• no explicit receive statement
• no shared variables
• gt Leads to natural modularity and abstraction
  techniques

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.

30
Compositional verification details

• Decompose a model into components,
• verify some specific properties for these
  components, and
• then deduce the systems property from the
  properties of its components.
• This deduction is sound, due to the weak
  simulation relation.
• (between a component in a model and its
  parallel composition with another arbitrary
  component in the same model.)

31

• Decompose a model into components
• Model the environment as incoming messages
  (external messages) MC,Ec
• Abstracting the environment from its concrete
  behavior (state variables).
• Abstract the queue from external messages Ca

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.

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

35
Bridge Controller Example
passed
Train1
Arrive
Arrive
Leave
Leave
Bridge Controller
YouMayPass
YouMayPass

• Receiving Arrive or Leave from the
  environment, arbitrarily (not blocking the
  component).

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.

38
Bridge Controller Example
Train as a component
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 MC,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) f ? ?(M) f, for MC,Ec
• ?(M) f ? ?(M) f, 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 EC for C.
• For every safety property,
• specified by LTL-X or ACTL-X formula,
• with atomic propositions on variables in C,
• Ca P implies CCECC P

43
Abstraction TechniquesSummary

• 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

44
One more pointSymmetry 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.

45
Dining Philosophers
Component C1
Component C5
Component C2
Component C4
Component C3