1 / 46

: A Finite State Verification Approach for Software Systems

FLAVERS. : A Finite State Verification Approach for Software Systems. Lori A. Clarke , George S. Avrunin, Jamieson M. Cobleigh, Heather M. Conboy,Matthew B. Dwyer, Gleb Naumovich, and Leon J. Osterweil

vance
Download Presentation

: A Finite State Verification Approach for Software Systems

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. FLAVERS : A Finite State Verification Approach for Software Systems Lori A. Clarke, George S. Avrunin, Jamieson M. Cobleigh, Heather M. Conboy,Matthew B. Dwyer,Gleb Naumovich, and Leon J. Osterweil Laboratory for Advanced Software Engineering ResearchUniversity of Massachusetts, Amhersthttp://laser.cs.umass.edu/

  2. Finite State Verification (FSV) • Verifies properties about system behavior • Seeks a middle ground between testing and theorem proving • Testing cannot provide definitive results • Theorem proving requires mathematical sophistication and considerable human insight • Works on a finite model of the system • Has been successfully used to prove a variety of properties of systems

  3. State Explosion Problem • FSV techniques can quickly become intractable due to the state explosion problem • The cost can be exponential in the size of the system being analyzed • Analysts typically have to figure out how to create a small, abstract model of the system

  4. Our Approach • Automatically create an abstract model • Imprecise, but conservative • Helps control state explosion • If needed, add precision incrementallyuntil model is precise enough to • provethe property of interest or • reveal a fault (in the system or property)

  5. Outline • Introduction • FLAVERS Model • Checking Properties • Improving Precision • Experimental Results • Conclusion

  6. FLAVERS • FLow Analysis for VERification of Systems • Verifies properties about concurrent and sequential systems • Automatically creates an abstract, event-based graph model of the system • Imprecise, but conservative • Represents properties as Finite-State Automata • Sequences of syntactically recognizable events • Uses an efficient data-flow analysis algorithm • Precision can be improved incrementally • Can be used for both safety and liveness properties

  7. Modeling Concurrent Systems • Common model for a concurrent system is a reachability graph • Represents all the states a concurrent system may reach • <l1,l2, …ln>, where each element of the tuple is a location in one of the tasks • Often includes the full state of execution • location and values of all variables for each task • Interleaved model of execution

  8. task body t1 is begin u; t2.synch; v; w; end t1; task t2 body is begin x; accept synch; y; z; end t2; b,b u,b b,x u,x s,s v,s s,y w,s v,y s,z w,y v,z w,z e,e Reachability Graph

  9. task body t1 is begin u; t2.synch; v; w; end t1; task t2 body is begin x; accept synch; y; z; end t2; <0,0> <0,0> <0,0> <0,1> <0,1> <0,1> <1,0> <1,0> <1,0> b,b <1,1> <1,1> <1,1> u,b <0,0> b,x <1,0> u,x s,s v,s s,y w,s v,y s,z w,y v,z w,z e,e Reachability Graph

  10. Trace Flow Graph (TFG) • A TFG represents how events flow through a system • Built from Control Flow Graphs for the tasks in the system • For a concurrent systems, nodes and edges may be added to represent concurrency

  11. task body t1 is begin u; t2.synch; v; w; end t1; task t2 body is begin x; accept synch; y; z; end t2; t2.synch accept synch TFG Construction ` ` u x synch v y w z

  12. b,b u,b u x u,x synch s,s v,s v y w,s w z w,y w,z e,e Feasible Paths b,b u,b b,x u x u,x synch s,s v,s s,y v y w,s v,y s,z w z w,y v,z w,z e,e

  13. b,b u,b u synch Infeasible Paths b,b u,b b,x u x u,x synch s,s v,s s,y v y w,s v,y s,z w z w,y v,z w,z e,e

  14. Outline • Introduction • FLAVERS Model • Checking Properties • Improving Precision • Experimental Results • Conclusions

  15. The elevator does not move while its doors are open. L(P) is the set of all strings accepted by property P 1 closemove open close 2 open move closemoveopen 3 Elevator Property

  16. Annotated TFG • A TFG G is <N, ninitial, nfinal, E> • Associate events with nodes • G is the alphabet of G • Events must be indivisible wrt other events in the property • L(G) is the language of G • The set of all strings in (G) that occur on paths from the initial node to the final node • CFG is alphabet refined • Remove nodes that do not affect the property being verified

  17. 1 closemove open close 2 open move closemoveopen 3 Alphabet Refinement • p is the alphabet of the property P • E.g., p = {open, close, move} • For alphabet refinement, remove all nodes in the TFG that do not have events in p OR do not control the flow of execution for nodes with such events

  18. Simple Sequential Example 1: if … 1: if (stopped) then 2: open; end if; … 3: if (stopped) then 4: close; end if; … 5: move; … 2: open 3: if 4: close 5: move

  19. Proving Properties • Given a CFG G and a property P • Alphabet refine G with respect to P • Need to show L(G)  L(P) • Use data-flow analysis to propagate states of P to the nodes of G • In(n) = Upred(n)Out(n) • Out(n) = UtIn(n)(t) where  is the transition function • Worst-case cost is O((NG)2  SP)

  20. 1: if 1 closemove open close 2 open 3: if move closemove open 3 State Propagation Worklist: 2, 3 , 4, 5 {1} {1} {1} 2: open {2} {1,2} {1,2} {1,2} 4: close {1} {1,2} 5: move {1,3}

  21. 1: if 3: if State Propagation Worklist: 2, 3 , 4, 5 {1} {1} 1 closemove {1} 2: open open {2} close {1,2} 2 open {1,2} {1,2} move 4: close {1} closemove open 3 {1,2} 5: move {1,3}

  22. 1: if 1 closemove 2: open open close 2 3: if open move 4: close closemove open 3 5: move State Propagation {1} {2} {1,2} {1} {1,3}

  23. 1: if 2: open 3: if 4: close 5: move State Propagation … 1: if (stopped) then 2: open; end if; … 3: if (stopped) then 4: close; end if; … 5: move; …

  24. Boolean Variable Constraint u S==tS=t S==fS=f S=f S==t S=t S==fS=f t f S=t S==f S==t v S==t S=tS==f S=f == is a predicate= is assignment

  25. Boolean Variable Constraint u S==tS=t S==fS=f S=f S==t S=t S==fS=f t f S=t S==f S==t v S==t S=tS==f S=f == is a predicate= is assignment

  26. Improving Precision • Use constraints to improve precision • Represented as FSAs • Given a CFG G, a property P, and constraints C1,…,Cn • Alphabet refine G with respect to (P C1 … Cn) • Want (L(G) L(C1) …L(Cn))  L(P) • Worst-case cost is O(NG2  SP  SC1 … SCn)

  27. 1: if 2: S==t 4: S==f 3: open 5: if 6: S==t 8: S==f 7: close 9: move Elevator Revisited … 1,2,4: if (stopped) then 3: open; end if; … 5,6,8: if (stopped) then 7: close; end if; … 9: move; …

  28. closemove 1 open close <1,u> 1: if 2 <1,u> <1,u> open <1,u> <1,u> move <1,t> <1,f> closemove open 3 <1,t> <2,t> u <2,t>,<1,f> 5: if S==t S==f <2,t>,<1,f> <2,t>,<1,f> S==t S==f t f <2,t>,<1,v> S==f S==t v S==f S==t State Propagation Worklist: 2, 4 , 3 , 5 , 6, 8 2: S==t 4: S==f 3: open 6: S==t 8: S==f 7: close 9: move

  29. closemove 1 open close 2 open move closemove open 3 u S==t S==f S==t S==f t f S==f S==t v S==f S==t State Propagation Worklist: 2, 4 , 3 , 5 , 6, 8 <1,u> 1: if <1,u> <1,u> <1,u> 2: S==t 4: S==f <1,t> <1,f> <1,t> 3: open <2,t> <2,t>,<1,f> 5: if <2,t>,<1,f> <2,t>,<1,f> 6: S==t 8: S==f <2,t>,<1,v> 7: close 9: move

  30. closemove 1 , 7, 9 open close 2 open move closemove open 3 u S==t S==f S==t S==f t f <2,v>,<1,f> <2,t>,<1,f> S==f S==t <1,t> v <1,t>,<1,f> S==f S==t <1,t>,<1,f> State Propagation Worklist: 2, 4 , 3 , 5 , 6, 8 <1,u> 1: if <1,u> <1,u> <1,u> 2: S==t 4: S==f <1,t> <1,f> <1,t> 3: open <2,t> <2,t>,<1,f> 5: if <2,t>,<1,f> <2,t>,<1,f> <2,t>,<1,f> 6: S==t 8: S==f <2,t>,<1,v> 7: close 9: move

  31. closemove 1 open close , 7, 9 2 open move closemove open 3 u S==t S==f S==t S==f t f <2,v>,<1,f> <2,t>,<1,f> S==f S==t <1,t> v <1,t>,<1,f> S==f S==t <1,t>,<1,f> State Propagation Worklist: 2, 4 , 3 , 5 , 6, 8 <1,u> 1: if <1,u> <1,u> <1,u> 2: S==t 4: S==f <1,t> <1,f> <1,t> 3: open <2,t> <2,t>,<1,f> 5: if <2,t>,<1,f> <2,t>,<1,f> <2,t>,<1,f> 6: S==t 8: S==f <2,t>,<1,v> 7: close 9: move

  32. Outline • Introduction • FLAVERS Model • Checking Properties • Improving Precision • Experimental Results • Conclusion

  33. Experimental Goals • Evaluate how FLAVERS performance scales as program size increases • Time • Memory • Number of constraints

  34. Chiron • User interface system • Developed at UC Irvine • Uses event-based notification • Similar to Listeners in Java • Proved several properties about Chiron • Avrunin, Corbett, Dwyer, Pasareanu, Siegel

  35. Example Properties • p07 - If listener1 registers for event1 before listener2, then listener1 will be notified of event1 before listener2 • p09 - The program never terminates while a listener is listening for an event

  36. Chiron • The Chiron system was scaled by increasing the number of events that can be listened for • Lines of code • 2 events 259 • 53 events 3,557 • Constraints Needed • For every property, the constraints needed to verify a property in the 2 event system are sufficient to verify the property for any system with more events • Never needed more than 4 constraints

  37. Comparison to Other Approaches • SMV [McMillan, 1993] • Symbolic model checking • SPIN [Holzmann, 1991] • Optimized reachability analysis • INCA [Corbett and Avrunin, 1995] • Integer linear programming

  38. Experimental Results • FLAVERS usually demonstrated subcubic performance in the size of the system • The few examples that were not subcubic could be solved by restating the properties • Only took a few iterations to determine the constraints that should be selected • Once a set of constraints was found for a small system configuration, the same set of constraints was sufficient for larger configurations • Often did not have the *best* performance compared to other approaches, but consistently performed well

  39. Related Work • Data-flow analysis • DAVE [Osterweil and Fosdick, 1976] • CESAR/CECIL [Olender and Osterweil, 1990 & 1992] • FLAVERS [Dwyer and Clarke, 1994] • Other FSV Tools • SMV, NuSMV • SPIN • Java PathFinder • SLAM • INCA • …

  40. Recent and Future Work • Support for Java • Specifying properties (Propel) (ICSE2002) • Heuristics for constraint selection (FSE2003) • Heuristics for counterexample selection (FSE2004) • Compositional techniques • Design-time verification applied to architectural description languages • Verification of process descriptions • Scientific processes • Medical processes • To improve safety and efficiency • ecommerce and egovernment processes • To assure security and privacy

  41. Conclusions • Finite state verification approaches are improving • Being used in industry for hardware systems • With the increasing interest in software security and quality, may become widely used for software systems • FLAVERS provides a demonstration of its potential effectiveness

More Related