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. Property System Property Translator System Translator Reasoning Engine TFG Consistent FSA Ada, Java, C++, Jovial Inconsistent + counter example Event alphabet Architecture of FLAVERS

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. 3 4 2 9 T1T2 5 7 8 1 6 1,6 2,6 start... Enumerating the State Space

9. 3 4 2 9 T1T2 5 7 1,6 2,6 5,9 3,6 4 8 1,7 1 6 2,71,8 3,72,8 3,8 e1 e2 e3 e1 e2 e3 Enumerating the event space e1 e2

10. 3 4 2 9 T1T2 5 7 8 1 6 e1 e2 e3 4 9 T1T2 5 8 1 e1 e2 e3 FLAVERS model of the system

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. Property System Property Translator System Translator Reasoning Engine TFG Consistent FSA Ada, Java, C++, Jovial Inconsistent + counter example Event alphabet Architecture of FLAVERS

15. Example Property FSA The elevator always closes its doors before moving close, open,move 0 1 open close 2 move close move open

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(N 2 S) N is the size of the model of the system S is the number of states guaranteed to terminate

17. Elevator Controller void main() { … 1,2,4:if (elevatorStopped) {... 3:openDoors(); }... 5,6,8:if (elevatorStopped) {... 7:closeDoors(); } 9:moveToNextFloor(); } 1: if 3: open 7: close 5: if 9: move

18. 7,9 Elevator Controller Worklist: 3, 5, 1: if 3: open 7: close 5: if 9: move close 0 1 open close 2 move close move open Property open move

19. 7,9 Elevator Controller void main() { … 1,2,4:if (elevatorStopped) {... 3:openDoors(); }... 5,6,8:if (elevatorStopped) {... 7:closeDoors(); } 9:moveToNextFloor(); } Worklist: 3, 5, 1: if 3: open 7: close 5: if 9: move close 0 1 open close 2 move close move open Property open move <0><0> <1><1>

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. Property System Property/Constraint Translator System Translator Reasoning Engine TFG Consistent FSA Ada, Java, C++, Jovial Inconsistent + counter example Event alphabet Revised Architecture of FLAVERS Constraints

22. Elevator Controller void main() { … 1,2,4:if (elevatorStopped) {... 3:openDoors(); }... 5,6,8:if (elevatorStopped) {... 7:closeDoors(); } 9:moveToNextFloor(); } 1: if 3: open 7: close 5: if 9: move 6: S==true 8: S==false 4: S==false2: S==true

23. Example constraint for a boolean variable == is a predicate = is assignment viol S==true S=true S==true S=true S==true S==false S=false S==false S==true S=true S==false S=false S==false S=false S=false S=true truefalse unknown

24. Example constraint for a boolean variable == is a predicate = is assignment viol S==true S=true S==true S=true S==true S==false S=false S==false S==true S=true S==false S=false S==false S=false S=false S=true truefalse unknown

25. Worklist: 2, 4,3,6,8,5, State Propagation 1: if 3: open 7: close 5: if 9: move 6: S==true 8: S==false 4: S==false2: S==true, 0 21 viol S==true S==false S==true S==false S==true Constraint close 0 1 open close 2 move close move open Property open move

26. Worklist: 2, 4,3,6,8,5,7,9 State Propagation 1: if 3: open 7: close 5: if 9: move 6: S==true 8: S==false 4: S==false2: S==true, 0 21 viol S==true S==false S==true S==false S==true Constraint close 0 1 open close 2 move close move open Property open move

27. Worklist: 2, 4, 3, 5, 6, 8, 7Worklist: 2, 4, 3, 5, 6, 8, 7, 9 State Propagation 1: if 3: open 7: close 5: if 9: move 6: S==true 8: S==false 4: S==false2: S==true,, 0 21 viol S==true S==false S==true S==false S==true Constraint close 0 1 open close 2 move close move open Property open 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 ==> properties Design specs ==> properties properties X system representations ==> 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. Action may occur zero times. FSA template: action response action  response DNL template:  response or  (action,response) Multiple occurrences of action eventually result in only one occurrence of response. Response cannot occur before the first action occurs.  (action,response) repetition phrase Action may occur zero times. The Repetition phrase describes whether or not the property is repeatable. This property is repeatable. This property is not repeatable. action repetition phrase  response or  (action,response) This property is repeatable. Response Property

36.  response or  (action,response)  response response Competed FSA template… completed FSA …and a DNL template. …and its DNL representation of your property. action  response This property is repeatable. Multiple occurrences of action eventually result in only one occurrence of response. Response cannot occur before the first action occurs.  (action,response) Action may occur zero times. action 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. Instantiated Response Property

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?