Finite State Verification for Software Systems - PowerPoint PPT Presentation

Loading...

PPT – Finite State Verification for Software Systems PowerPoint presentation | free to download - id: 5b845e-M2JiO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Finite State Verification for Software Systems

Description:

Finite State Verification for Software Systems Lori A. Clarke University of Massachusetts Laboratory for Advanced Software Engineering Research http://laser.cs.umass.edu/ – PowerPoint PPT presentation

Number of Views:70
Avg rating:3.0/5.0
Slides: 39
Provided by: Jamie143
Learn more at: http://isr.uci.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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?
About PowerShow.com