1 / 46

This research has been funded in part by grants from the

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.

ora
Télécharger la présentation

This research has been funded in part by grants from the

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. 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

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

  32. 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.

  33. Preceding Remaining S1 = ( < > , < > ) , S2 = ( < > , < > ) View of lists with abstraction

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

  35. 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;

  36. 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;

  37. 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;

  38. 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|);

  39. 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);

  40. 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;

  41. 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;

  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. 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;

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

  45. 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.

More Related