Finite State Verification for Software Systems

1
Finite State Verification for Software Systems

• Lori A. Clarke
• University of Massachusetts
• Laboratory for Advanced Software Engineering
  Research
• http//laser.cs.umass.edu/
• Other contributors G. Avrunin, J. Cobleigh, M.
  Dwyer, G. Naumovich, and L. Osterweil

2
Testing

• can
• Uncover failures
• Show specifications are not met for specific test
  cases
• Be an indication of overall reliability
• cannot
• Prove that a program will/will not behave in a
  particular way

3
Distributed Systems

• Better performance, better flexibilty,
  but there is a cost
• distributed systems are more difficult to
  test than sequential systems
• number of execution paths can grow exponentially
  with the number of tasks
• Testing can not even demonstrate that a system
  works on the selected/executed test data

4
Formal Verification An Alternative to Testing

• Theorem Proving
• Prove properties about all possible executions
• Use mathematical reasoning
• Difficult and error prone
• Finite State Verification
• Prove properties about all possible executions
• Reason about a finite abstract, model of the
  system
• not as powerful as theorem proving
• Almost a totally automated process

5
Finite State Verification State of the Art

• Reachability Based Approaches
• Symbolic Model Checking -- SPIN or SMV
• Exponential worst-case bound
• Integer Linear Constraints
• INCA
• Exponential worst-case bound
• Data Flow Analysis
• FLAVERS
• Polynomial worst-case bound

6
Architecture of FLAVERS
Property
Property Translator
Event alphabet
FSA
Consistent
TFG
System Translator
ReasoningEngine
System
Inconsistent counter example
7
FLAVERS Where is the magic?

• System Model
• Primarily event-based, not state-based
• Reason about sequences of events
• Does not enumerate all reachable states
• Includes all relevant executions
• Usually over-approximates relevant executable
  behaviors
• Model is conservative wrt a property
• Incrementally refine model as needed
• add state information that is demonstrated to be
  needed

8
Enumerating the State Space
T1
T2
6
1
8
3
4
9
9
Enumerating the event space
1,6
e1
T1
T2
6
1
2,6
1,7
e1
e2
e1
3,6
2,7
1,8
e2
e1
8
e2
3
3,7
2,8
4
e2
3,8
e3
9
4
e3
5,9
10
FLAVERS model of the system
T1
T2
e1
1
e2
8
4
9
e3
11
Modeling the System FLAVERS

• Automatically creates the program model from the
  source code
• Instead of the state space, explicitly represents
  interleaved execution via edges
• Compute MHP
• Optimize the representation
• Model only events of interest
• Conservative with respect to a property

12
Some comments on the model

• Works well if the events of interest are
  relatively sparse in the overall system
• E.g., method invocations, task interaction
• Inter-procedural analysis done via in-lining
• An imprecise, but conservative, representation
• Too imprecise for deadlock
• Seems to greatly reduce the analysis cost...

13
Disclaimer
14
Architecture of FLAVERS
Property
Property Translator
Event alphabet
FSA
Consistent
TFG
System Translator
ReasoningEngine
System
Inconsistent counter example
15
Example Property FSA

• The elevator always closes its doors before moving

16
Reasoning engine State Propagation

• States of the property are propagated through the
  TFG
• The property is proved if only accepting
  (non-accepting) states are contained in the final
  node of the TFG
• overall complexity is O(N2S)
• N is the size of the model of the system
• S is the number of states
• guaranteed to terminate

17
Elevator Controller
1 if
void main() 1,2,4 if (elevatorStopped) .
.. 3 openDoors() ... 5,6,8 if
(elevatorStopped) ... 7 closeDoors() 9 mo
veToNextFloor()
3 open
5 if
7 close
9 move
18
Elevator Controller
lt0gt
7,9
Worklist 3, 5,
lt1gt
lt0,1gt
lt0gt
lt0,2gt
19
Elevator Controller
lt0gt
7,9
Worklist 3, 5,
1 if
void main() 1,2,4 if (elevatorStopped) .
.. 3 openDoors() ... 5,6,8 if
(elevatorStopped) ... 7 closeDoors() 9 mo
veToNextFloor()
3 open
lt1gt
5 if
lt0,1gt
7 close
lt0gt
9 move
lt0,2gt
20
Conservative Analysis

• if a property is found to be valid, it is
  definitely true
• if a property is found to be invalid
• An invalid trace may correspond to an error
• The invalid traces do not correspond to
  executable behavior

21
Revised Architecture of FLAVERS
Property
Property/Constraint Translator
Event alphabet
FSA
Consistent
TFG
System Translator
ReasoningEngine
System
Inconsistent counter example
22
Elevator Controller
1 if
void main() 1,2,4 if (elevatorStopped) .
.. 3 openDoors() ... 5,6,8 if
(elevatorStopped) ... 7 closeDoors() 9 mo
veToNextFloor()
4 Sfalse
2 Strue
3 open
5 if
6 Strue
8 Sfalse
7 close
9 move
23
Example constraint for a boolean variable
unknown
SfalseSfalse
StrueStrue
Sfalse
Strue Strue
SfalseSfalse
true
false
Strue
Strue
Sfalse
viol
is a predicate is assignment
StrueStrueSfalseSfalse
24
Example constraint for a boolean variable
unknown
SfalseSfalse
StrueStrue
Sfalse
Strue Strue
SfalseSfalse
true
false
Strue
Strue
Sfalse
viol
is a predicate is assignment
StrueStrueSfalseSfalse
25
State Propagation
Worklist 2, 4,
3,
6 ,8,
5,
1 if
lt0,0gt
4 Sfalse
2 Strue
lt0,2gt
lt0,1gt
3 open
lt1,1gt
5 if
lt1,1gt,lt0,2gt
6 Strue
8 Sfalse
lt1,1gt,lt0,vgt
7 close
9 move
26
State Propagation
Worklist 2, 4,
3,
6 ,8,
5,
7,9
1 if
lt0,0gt
4 Sfalse
2 Strue
lt0,2gt
lt0,1gt
3 open
lt1,1gt
5 if
lt1,1gt,lt0,2gt
6 Strue
8 Sfalse
lt1,1gt,lt0,vgt
7 close
9 move
27
State Propagation
1 if
lt0,0gt
4 Sfalse
2 Strue
lt0,2gt
lt0,1gt
3 open
lt1,1gt
5 if
lt1,1gt,lt0,2gt
6 Strue
8 Sfalse
lt1,1gt,lt0,vgt
7 close
9 move
28
Constraints

• Used to add semantic information
• Can model many different kinds of information
• Variables or flow of control
• Missing components
• Environment
• Users
• Can provide automated assistance

29
Evaluating FLAVERS

• Experimental Evaluation
• Case studies
• Communication Protocols 3-way handshake and
  alternating bit
• demonstrated the importance of modeling the
  environment
• Architectural Design written in Wright
• demonstrated importance of doing analysis early
  
• Industrial demonstrations
• SAIC ADS Command Instruction Sets, HLA
• Northrop B2 Jovial systems
• MCC Quest project, C systems

30
Need a paradigm shift!

• Software systems are increasingly used in
  critical applications
• Medicine
• Transportation
• Communication
• Finance
• Cannot continue to do business as usual
• Testing as the prime validation technique is
  costly and ineffective

31
New life to an old vision

• Significant validation throughout the software
  lifecycle
• architectural design
• low level design
• coding
• debugging
• Maintenance
• Finite state verification is an extremely general
  approach

32
Early fault detection

• Requirement specs gt properties
• Design specs gt properties
• properties X system representations gt
  early feedback

33
Future Plans

• Difficult to predict performance
• For any FSV technique
• For FLAVERS Adding constraints increases the
  worst-case bound, but may (or may not) improve
  performance
• Need more automated support
• Analysis to help select additional information to
  be modeled
• Abstraction techniques for modeling

34
Future Work

• Explore alternative state propagation algorithms
• E.g., Initial verification vs re-verification
• Improve counter-example generation
• Short paths
• User guidance
• Better support for specifying properties
• Build on property pattern specifications
• FSA templates combined with Disciplined Natural
  Language

35
Response Property
FSA template
action
action
response
?response or ?(action,response)
?response
?(action,response)
DNL template
Multiple occurrences of action eventually result
in only one occurrence of response.
Action may occur zero times.
Action may occur zero times.
The Repetition phrase describes whether or not
the property is repeatable.
This property is repeatable.
Response cannot occur before the first action
occurs.
repetition phrase
36
Instantiated Response Property
completed FSA
Competed FSA template
action
response
action
?response or ?(action,response)
?response
?response
?(action,response)
and its DNL representation of your property.
and a DNL template.
Multiple occurrences of action eventually result
in only one occurrence of response. Action may
occur zero times. Response cannot occur before
the first action occurs. This property is
repeatable.
Multiple occurrences of action eventually result
in only one occurrence of response.
Action may occur zero times.
Response cannot occur before the first action
occurs.
This property is repeatable.
This property is repeatable.
37
Future Work

• Software composition techniques
• Contractual composition
• Integration with testing
• Better approaches for dealing with dynamism
• Full lifecycle support
• Support for Java
• Experimental Evaluation

38
Conclusions

• FLAVERS is effective at verifying a wide range of
  interesting properties
• Very general approach that can be applied to any
  event flow model
• Much easier to use than theorem proving based
  techniques
• Can be mostly automated
• Hides the formal in formal methods
• Is it easy enough?