Assumption Generation for Software Component Verification

1
Assumption Generation for Software Component
Verification

• Dimitra Giannakopoulou, Corina S.Pasareanu, and
  Howard Barringer
• in Proc. Of the 17th IEEE International
  Conference on Automated Software Engineering (ASE
  2002)
• 2003. 07.08
• Presented Kim, Soon Deok

2
Contents

• Introduction
• Background
• LTSA Tool Program Model
• Parallel composition
• Assume-guarantee reasoning
• Assumption generation
• Step 1 Composition and minimization
• Step 2 Backward error propagation
• Step 3 Property extraction
• Conclusion

3
Introduction(1/2)

• Model checking
• Automated verification technique
• Whether a concurrent system satisfies certain
  properties by exhaustively exploring all its
  possible executions
• Software model checking
• Typically applied to components of a larger
  system
• State explosion
• Divide and conquer

4
Introduction(2/2)

• model checking of components in isolation
• Incorporate a model of the environment
  interacting with the component
• Typically use Most general environment
• In any order, any action, refuse any service
• ? Overly pessimistic
• In this paper propose
• Framework for model checking of components
• Generates the weakest environment assumption that
  enables the property to hold

5
Background(1/3)LTSA Tool Program Model

• Labeled Transition System Analysis Tool
• Automated tool that supports CRA of a software
  system
• LTSA uses LTS to model the behavior of components
  in system
• LTS M is four tuple ltS, aT, R, s0gt
• S is set of states
• aT ? Act is a set of actions
• R ?S x aT ?t x S is a transition relation
• s0 ? S is the initial state

6
Background(2/3) Parallel composition

• Combines the behavior of two components
• by synchronization of the actions common
• Interleaving of the remaining actions
• T1 ltS1, aT1, R1, s01gt
• T2 ltS2, aT2, R2, s02 gt
• T1 T2 is an ltS, aT, R, s0gt
• S S1 x S2
• aT aT1 ? aT2
• R is
• S0 (s01 , s02 )

7
Background(3/3) Assume-guarantee reasoning

• ltAgt M ltPgt
• M component
• P property
• A assumption about Ms environment
• Assumption and properties are defined as LTSs
• Compute A M
• Checks if state p is reachable in the composition
  
• Yes ltAgt M ltPgt is violated by component M
• No it is satisfied
• Perr error LTSs of property, p error state
  in Perr

8
Model checking with Assumption generation(1/2)

• Traditional approach
• True Property holds for all the possible
  environments
• False There exists some environment that can
  lead the component to falsify the property
• In this paper approach
• True Property holds for all environments
• False Only if the property is falsified in all
  environments
• Not False Satisfy a some environments

9
Model checking with Assumption generation(2/2)
10
Assumption generation Step 1 Composition and
minimization

• Building the composition of the system with the
  error LTS of the property
• Compute all the violating traces of the system
  for any environments
• Turn into t all actions which the environment has
  no control
• Hiding the Internal actions of the system
• If error state is not reachable in this
  composition
• Property is True in any environment
• Else next step
• Backward error propagation

11
Property
System
12
Result of step 1
13
Assumption generation Step 2 Backward error
propagation

• Backward propagation of the error state over t
  transition
• Pruning the states where the environment cannot
  prevent the error state from being entered via
  one or more t steps
• Eliminate the states that are not backward
  reachable from the error state
• If the initial state becomes an error state
• No environment can prevent the system from
  possibly reaching the error state
• Property is False for all environment

14

• ss

15
Assumption generation Step 3 Property
extraction

• Builds the error LTS (Deterministic and Complete)
• Deterministic
• by applying to it t elimination and subset
  construction
• Completion
• by adding a new sink state to the LTS
• adding a transition to this state for each
  missing transition in the incomplete LTS
• The assumption by deleting the error state and
  the transitions that lead to it

16

• test

Assumption
17
Conclusion

• Typical approach to verifying properties
• To check them for all possible environments
• ?A component is only required to satisfy
  properties in specific environments
• Approach to model checking components as open
• Whether there is something inherently wrong with
  the component behavior
• Whether satisfying a requirements is a matter of
  proving the right environment
• Characterizes exactly all helpful environments
• Implement in the LTSA Tool