1. This research has been funded in part by grants from the U. S. National Science Foundation for the past 20 years. Towards Verified Software: Research and Education Murali Sitaraman School of Computing Clemson University E-mail: murali@cs.clemson.edu http://www.cs.clemson.edu/~resolve

2. About Clemson Clemson University is the land-grant institution of the state of South Carolina Ranked #22 among the public institutions in the US 17,000 students: About 13,000 undergraduate and 4000 graduate students The university is in the scenic town of Clemson (population 11,000) Capacity of the Clemson Tiger football stadium: 85,000 School of Computing has 30 faculty members and about 120 graduate students

3. Current Students at Clemson Ph. D. students David Frazier (security) Svetlana Drachova (educational environment) Heather Harton (verification condition generation) Hampton Smith (automated proving) Nighat Yasmin (performance specification/analysis) Other students Chuck Cook Emily Forney Grant Giles

4. Collaborating professors elsewhere Jeremy Avigad (Philosophy, CMU) Harvey Friedman (Mathematics, Ohio State) Joe Hollingsworth (CS, Indiana University Southeast) Joan Krone (Mathematics and CS, Denison) Greg Kulczycki (CS, Virginia Tech) Bill Ogden (CS, Ohio State) Bruce Weide (CS, Ohio State) More collaborators… Steve Edwards (Virginia Tech) Gary Leavens (Central Florida) …

5. The RESOLVE vision The RESOLVE vision is that of a future in which no production software is considered properly engineered unless it has been fully specified and fully verified as satisfying these specifications.

6. A different vision (Once upon a time…) No production software will be considered properly developed, unless it is written in a high-level programming language, and translated into machine language entirely automatically.

7. Status of the high-level language translation vision today Vision accomplished (compilers)! Vision exceeded: Compilers can themselves be developed in high-level languages!! Vision exceeded even further: Operating systems, and even more complex systems can be developed in high-level languages!!!

8. What is a specification? Specification of a Boolean function to determine if a number is prime simply states under what conditions the function will return true or false. Specification of a Queue Sort operation would say that the resulting queue is in order and …

9. What is a specification? Specification of a Boolean function to determine if a number is prime simply states under what conditions the function will return true or false. Specification of a Queue Sort operation would say that the resulting queue is in order and the resulting queue is a permutation of the input queue. Unlike typical programming languages, in RESOLVE, you can write formal specifications and code.

10. The vision The RESOLVE vision is that of a future in which no production software is considered properly engineered unless it has been fully specified and fully verified as satisfying these specifications.

11. The vision The RESOLVE vision is that of a future in which no production software is considered properly engineered unless it has been fully specified and fully verified as satisfying these specifications. Also see Tony Hoare’s verification grand challenge for the computing community

12. What if the specifications are wrong? What if the real-world modeling, on which the specifications are based, is wrong? What if the specifications are simply not formulated right, i.e., do not capture the intent? These are important questions, but if the vision is realized, we’d at least know that the software is correct! Thus the vision isolates the verification problem.

13. Will testing still be needed? Absolutely. Verification only checks if code meets specified behavior. To validate software, i.e., code satisfies customer requirements, you still need testing.

14. Isn’t the verification problem undecidable? Yes. But correctness of programs we will ever write in practice has nothing to do with undecidability! Intuition: competent programmers can usually tell whether their code is right; they don’t solve deep mathematical theorems to reach conclusions.

15. What does this code do? I and J are Integers. I = I + J; J = I – J; I = I – J;

16. Does this code leave S unchanged? S is a Stack of entries. S.Push( S.Pop() );

17. Back to competent programmers Intuition: competent programmers can usually tell whether their code is right (modulo careless errors); they don’t solve deep mathematical theorems to reach conclusions.

18. Back to competent programmers Intuition: competent programmers can usually tell whether their code is right (modulo careless errors); they don’t solve deep mathematical theorems to reach conclusions. Jason Kirschenbaum, Bruce Adcock, Derek Bronish, Hampton Smith, Heather Harton, Murali Sitaraman and Bruce W. Weide, Verifying Component-Based Software: Deep Mathematics or Simple Bookkeeping?, Procs. 11th Int. Conf. Software Reuse, Springer, September 2009.

19. Automated verification made easy… Given proper justifications from programmers (e.g., invariants for loops) and adequate mathematical developments (e.g., theorems), verification is easy; actually so easy that a minimalist prover can do most of it!

20. RESOLVE Compiler/Verifier information flow Proof Units Math Units Proof Checker Result Reports Specifications Realizations Verifier Result Reports Compiler Compiled Code Verification System

21. Relevant Publication Murali Sitaraman, Bruce Adcock, Jeremy Avigad, Derek Bronish, Paolo Bucci, David Frazier, Harvey M. Friedman, Heather Harton, Wayne Heym, Jason Kirschenbaum, Joan Krone, Hampton Smith, and Bruce W. Weide, Building a Push-Button RESOLVE Verifier: Progress and Challenges, Formal Aspects of Computing, Springer, accepted to appear; available as a tech. report.

22. Main points for the verification vision Integrated specification and implementation language with clean semantics. Modular verification. Soundness. Adequate mathematical development. Programmers should supply adequate justifications, but should not be involved in proofs. Educational challenges in producing competent programmers.

23. Some Recent Publications Greg Kulczycki, Murali Sitaraman, Nighat Yasmin, and Kim Roche, Formal Specification, Encyclopedia of Computer Science and Engineering, Wiley, 2008. Heather Harton, Joan Krone, and Murali Sitaraman, Formal Program Verification, Encyclopedia of Computer Science and Engineering, Wiley, 2008. Hampton Smith, Heather Harton, David Frazier, Raghuveer Mohan, and Murali Sitaraman, Generating Verified Java Components through RESOLVE, Procs. 11th Int. Conf. Software Reuse, Springer, September 2009.

24. Education Murali Sitaraman, Jason Hallstrom, Jared White, Svetlana Drachova-Strang, Heather Harton, Dana Leonard, Joan Krone, and Rich Pak, Engaging Students in Specification and Reasoning: Hands-on Experimentation and Evaluation, Procs. ACM-SIGCSE 14 th Annual Conference on Innovation and Technology in Computer Science Education (ITiCSE), 2009. Also SIGCSE 2009 paper on teaching specifications.

25. Courses at Clemson CPSC 215: Introduction to Software Foundations. Formal specification and reasoning principles are introduced in a Java context, along with OO concepts. CPSC 372: Introduction to Software Engineering. Team development with formal contracts verification are reinforced. Principles taught in incremental, adpatable modules.

26. Principles for Teaching How can specifications scale? Abstraction in specification How can implementations scale? Component-based software development How can verification scale? Modularity in verification, i.e., ability to verify one component at a time How can automation scale? Adequate justifications from programmers Adequate mathematical developments

27. Sample Educational Activity Graduate and undergraduate SE classes Specifications are given Also internal assertions (e.g., representation invariants and abstraction functions) for some implementations are given. Mixed and used pieces of code from 6 different students The resulting software – composed in class in front of students - worked the first time after integration!

28. Main points for the verification vision Integrated specification and implementation language with clean semantics. Modular verification. Soundness. Adequate mathematical development. Programmers should supply adequate justifications, but should not be involved in proofs. Educational challenges in producing competent programmers.

29. Towards Verified Software: Research and Education Murali Sitaraman School of Computing Clemson University E-mail: murali@cs.clemson.edu http://www.cs.clemson.edu/~resolve

30. Verified Software Part II: Technical Details Murali Sitaraman School of CTecomputing Clemson University E-mail: murali@cs.clemson.edu http://www.cs.clemson.edu/~resolve

32. What is modular verification? uses implements uses implements uses

33. Abstraction in specification Think of a List as a pair of mathematical strings: A string of entries that precede the current position and A string of remaining entries Initially, both strings are empty.

34. View of lists with abstraction S1 = ( <, >, <> ) S2 = ( <>, <> ) PrecedingRemaining

35. Views of List S1 before and after: Insert (T, S1) S1 = ( <, >, <> ) T = S1 = ( <, >, <> ),

36. Mathematical Modeling Concept List_Template (type Entry); uses String_Theory, …; Type List is modeled by ( Prec: String(Entry); Rem: String(Entry) ); exemplar S; initialization ensures S.Prec = empty_string and S.Rem = empty_string;... end List_Template;

37. List Operations Concept List_Template (type Entry); uses … Type List is modeled by … Oper Insert(E: Entry; S: List); Oper Remove(E: Entry; S: List); Oper Advance(S: List); Oper Reset(S: List); Oper Advance_To_End(S: List); Oper Prec_Length(S: List): Integer; Oper Rem_Length(S: List): Integer; Oper Swap_Rems(S1, S2: List); end List_Template;

38. Design & Specification of Operations Operation Insert(clears E: Entry; updates S: List); Ensures S.Prec = #S.Prec and S.Rem = °  #S.Rem; Operation Remove(replaces E: Entry; updates S: List); Requires |S.Rem| > 0; Ensures S.Prec = #S.Prec and #S.Rem = °  S.Rem;

39. Design & Specification of Operations Operation Advance(updates S: List); Requires |S.Rem| > 0; Ensures S.Prec ° S.Rem = #S.Prec ° #S.Rem and |S.Prec| = |S.Rem| + 1; Operation Reset(updates S: List); Ensures S.Prec = empty_string and S.Rem = #S.Prec ° #S.Rem; Operation Rem_Length(restores S: List); Ensures Rem_Length = (|S.Rem|);

40. Specification of a List Sort Operation Definition Is_Ascending_Order = … Operation Sort_List( updates P: List ); ensures P.Prec =  and In_Ascending_Order( P.Rem ) and Is_Permutation (P.Rem, #P.Prec o #P.Rem);

41. Skeleton of insertion sorting Procedure Sort_List( updates P: List ); Var P_Entry, S_Entry: Entry; Var Sorted: List; Reset ( P ); While ( Length_of_Rem (P) > 0 ) maintaining Sorted.Prec = empty_string and In_Ascending_Order( Sorted.Rem ) and … Remove (P_Entry, P); Repeat … iterate; end; P :=: Sorted; end Sort_List;

42. While Length_of_Rem( P )  0 do Remove( P_Entry, P ); Iterate When Length_of_Rem( Sorted ) = 0 do exit; Remove( S_Entry, Sorted ); When Lss_or_Comp( P_Entry, S_Entry ) do Insert( S_Entry, Sorted ) exit; Insert( S_Entry, Sorted ); Advance( Sorted ); repeat; Insert( P_Entry, Sorted ); Reset( Sorted ); end; P :  : Sorted; end Sort_List;

43. While Length_of_Rem( P )  0 do Remove( P_Entry, P ); Iterate When Length_of_Rem( Sorted ) = 0 do exit; Remove( S_Entry, Sorted ); When Lss_or_Comp( P_Entry, S_Entry ) do Insert( S_Entry, Sorted ) exit; Insert( S_Entry, Sorted ); Advance( Sorted ); repeat; Insert( P_Entry, Sorted ); Reset( Sorted ); end; P :  : Sorted; end Sort_List;

44. Performance Analysis Procedure Sort_List( updates P: List ); duration … manip_displacement … Var P_Entry, S_Entry: Entry; Var Sorted: List; Reset ( P ); While ( Length_of_Rem (P) > 0 ) maintaining … decreasing … elapsed time … manip_disp … … end; end Sort_List;

45. Performance Analysis Procedure Sort_List( updates P: List ); duration O( Max( |#P.Prec ◦ #P.Rem|, P_Rank( #P.Prec◦#P.Rem ) ); …

46. Main points Integrated specification and implementation language with clean semantics. Modular verification. Soundness. Adequate mathematical development. Programmers should supply adequate justifications, but should not be involved in proofs. Educational challenges in producing competent programmers. Visit www.cs.clemson.edu/~resolve for details.