This research has been funded in part by grants from the

1. 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 This research has been funded in part by grants from the U. S. National Science Foundation for the past 20 years.

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 Specifications Realizations Proof Checker Compiler Verifier Result Reports Result Reports 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 14th 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 uses implements 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. Preceding Remaining S1 = ( < > , < > ) , S2 = ( < > , < > ) View of lists with abstraction

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

36. Mathematical Modeling ConceptList_Template (type Entry); uses String_Theory, …; TypeListis modeled by ( Prec: String(Entry); Rem: String(Entry) ); exemplar S; initializationensures S.Prec = empty_stringand S.Rem = empty_string; ... end List_Template;

37. List Operations ConceptList_Template (type Entry); uses… TypeListis modeled by … OperInsert(E: Entry; S: List); OperRemove(E: Entry; S: List); OperAdvance(S: List); OperReset(S: List); OperAdvance_To_End(S: List); OperPrec_Length(S: List): Integer; OperRem_Length(S: List): Integer; OperSwap_Rems(S1, S2: List); end List_Template;

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

39. Design & Specification of Operations OperationAdvance(updates S: List); Requires |S.Rem| > 0; Ensures S.Prec° S.Rem = #S.Prec° #S.Rem and |S.Prec| = |S.Rem| + 1; OperationReset(updates S: List); Ensures S.Prec = empty_stringand S.Rem = #S.Prec ° #S.Rem; OperationRem_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_stringand 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 doexit; 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 doexit; 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.