Producing Better Output from Finite State Verification Systems

1. Producing Better Output from Finite StateVerification Systems By Steve Kassof Advisor: Aaron Cass

2. Elevator • Ways to get it wrong • Between Floors • Doors open while moving • People left stranded • Problems with testing • Time • Thoroughness

3. Elevator Open Doors First Floor Doors Open First Floor Doors Closed Close Doors Open Doors Close Doors Up One Floor Down One Floor Second Floor Doors Open Close Doors Second Floor Doors Closed Close Doors Move Car Open Doors

4. How Do FSVs Work? • Creating execution paths • Model how a program runs • Faster and less expensive than test running

5. Elevator First Floor Doors Open First Floor Doors Closed Open Doors Close Doors Open Doors Close Doors Up One Floor Down One Floor Second Floor Doors Open Second Floor Doors Closed Close Doors Close Doors Move Car Open Doors

6. How Do FSVs Work? • Give user violating paths • State with incorrect system properties • Something went wrong

7. Elevator First Floor Doors Open First Floor Doors Closed Open Doors Close Doors Open Doors Close Doors Down One Floor Up One Floor Up One Floor Down One Floor Second Floor Doors Open Second Floor Doors Closed Close Doors Close Doors Move Car Open Doors

8. Current Output • No standard output designed to be user-friendly • Different output for different FSVs • As many as it can find • Makes it harder for the user • First path found • May not have enough information • FSVs don’t know which path to show • Could be too long, too complicated, or too short

9. Proposed Solution • FSV finds many violating paths • Must have passed through some error • Small and representative subset of violating paths • Small • Easy to comprehend • Representative • Shows various ways a problem occurs • Given paths from an FSV, take 5 paths least alike • Reducing commonality makes the subset more representative

10. Ideal Solution Open Doors Close Doors Close Doors Move Car

11. Creating the Subset • Take the 1000 shortest paths from the FSV • Find number of common nodes between two paths • Store number to avoid multiple calculations • Find the five paths with lowest commonality • Worst case: Θ(n5)

12. Implementation • Built simple elevator program • Two floors • People pushed call button at random times • Known error • Elevator will instantly respond to call buttons • Not fully implemented yet • Features missing • Wrote to see if we could get violating paths to use

13. Future Work • Commonality • Change how difference between paths is calculated • Every node is involved in each trace • Evaluate Efficiency • Full Elevator Controller • User Study • Requires test subjects to languages not taught at Union

14. Questions?