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.

Slides:



Advertisements
Similar presentations
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Advertisements

Writing specifications for object-oriented programs K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 21 Jan 2005 Invited talk, AIOOL 2005 Paris,
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Challenges in increasing tool support for programming K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 23 Sep 2004 ICTAC Guiyang, Guizhou, PRC joint.
This research is funded in part the U. S. National Science Foundation grant CCR DEET for Component-Based Software Murali Sitaraman, Durga P. Gandi.
Computer Science School of Computing Clemson University Introduction to Mathematical Reasoning Jason Hallstrom and Murali Sitaraman Clemson University.
Addressing the Challenges of Current Software. Questions to Address Why? What? Where? How?
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Modeling the Process and Life Cycle CSCI 411 Advanced Database and Project Management Monday, February 2, 2015.
VIDE als voortzetting van Cocktail SET Seminar 11 september 2008 Dr. ir. Michael Franssen.
Software Engineering and Design Principles Chapter 1.
General Announcements Project Due Friday, 1/30 Labs start Wednesday & Thursday – Java review – Weiss 1.19, 1.20 – You may show up & hand in Workshops.
Software Testing and Quality Assurance
CS5371 Theory of Computation Lecture 8: Automata Theory VI (PDA, PDA = CFG)
Chapter 1 Program Design
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
Mathematics throughout the CS Curriculum Support by NSF #
Jason Hallstrom (Clemson), Joan Krone (Denison), Joseph E. Hollingsworth (IU Southeast), and Murali Sitaraman(Clemson) This workshop is funded in part.
Ranga Rodrigo. Class is central to object oriented programming.
Computer Science School of Computing Clemson University Discrete Math and Reasoning about Software Correctness Murali Sitaraman
Introduction to Programming (in C++) Conclusions Jordi Cortadella, Ricard Gavaldà, Fernando Orejas Dept. of Computer Science, UPC.
Computer Science School of Computing Clemson University Specification and Reasoning in SE Projects Using a Web IDE Charles T. Cook (Clemson) Svetlana V.
Chapter 2 The process Process, Methods, and Tools
Computer Science School of Computing Clemson University Mathematical Reasoning across the Curriculum Software Development Foundations and Software Engineering.
Lecture 16 March 22, 2011 Formal Methods CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)
Cs3102: Theory of Computation Class 18: Proving Undecidability Spring 2010 University of Virginia David Evans.
Computer Science School of Computing Clemson University Introduction to Formal Specification Murali Sitaraman Clemson University.
Mathematical Modeling and Formal Specification Languages CIS 376 Bruce R. Maxim UM-Dearborn.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
1 Program Correctness CIS 375 Bruce R. Maxim UM-Dearborn.
Lecture 17 March 24, 2011 Formal Methods 2 CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
1 CSC 222: Computer Programming II Spring 2004 See online syllabus at: Course goals:
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
Computer Science School of Computing Clemson University Discrete Math and Reasoning about Software Correctness Joseph E. Hollingsworth
Checking Reachability using Matching Logic Grigore Rosu and Andrei Stefanescu University of Illinois, USA.
3/8/2007 Copyright (c) 2007 by Adcock, Bucci, Heym, Hollingsworth, Long, & Weide 1 Which Pointer Errors Do Students Make? Bruce Adcock 1 Paolo Bucci 1.
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
Software Testing and Quality Assurance Software Quality Assurance 1.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
This research is funded in part by grant CCR from the U. S. National Science Foundation. Profiles: A Compositional Mechanism for Performance Specification.
1 Performance Specifications Based upon Complete Profiles Joan Krone William F. Ogden Murali Sitaraman.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Scientific Debugging. Errors in Software Errors are unexpected behaviors or outputs in programs As long as software is developed by humans, it will contain.
RESOLVE VERIFICATION: A New Perspective Joan Krone William F. Ogden.
1 KEEPING POINTERS OR REFERENCES UNDER CONTROL A COMPONENT BASED APPROACH TO LIST BASED DATA STRUCTURES.
Computer Science School of Computing Clemson University Mathematical Reasoning with Objects.
Integrating Math Units and Proof Checking for Specification and Verification SAVCBS Workshop 2008 SIGSOFT 2008 / FSE 16 November 9th, 2008 Hampton Smith.
CSE 501N Fall ‘09 03: Class Members 03 September 2009 Nick Leidenfrost.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
Lecture 18 March 29, 2011 Formal Methods 3 CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)
MANAGEMENT INFORMATION SYSTEM
Computer Science School of Computing Clemson University Reasoning with Queues and Web Interface Demo.
Modular Alternatives to Testing
Types for Programs and Proofs
Object-Oriented Software Engineering Using UML, Patterns, and Java,
CS 326 Programming Languages, Concepts and Implementation
Formal Specification of Java Interfaces
Introduction to Components and Specifications Using RESOLVE
Performance Specifications Based upon Complete Profiles
Programming Languages 2nd edition Tucker and Noonan
Hoare-style program verification
Formal Specification of Interfaces
Introduction to Components and Specifications Using RESOLVE
Mathematical Reasoning
Mathematical Reasoning with Data Abstractions
Programming Languages 2nd edition Tucker and Noonan
Formal Methods Lecture 16 March 22, 2011 CS 315 Spring 2011
Presentation transcript:

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

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

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

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) …

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.

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.

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

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 …

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.

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.

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

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.

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.

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.

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

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

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.

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.

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!

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

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.

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.

Some Recent Publications Greg Kulczycki, Murali Sitaraman, Nighat Yasmin, and Kim Roche, Formal Specification, Encyclopedia of Computer Science and Engineering, Wiley, Heather Harton, Joan Krone, and Murali Sitaraman, Formal Program Verification, Encyclopedia of Computer Science and Engineering, Wiley, 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.

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), Also SIGCSE 2009 paper on teaching specifications.

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.

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

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!

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.

Towards Verified Software: Research and Education Murali Sitaraman School of Computing Clemson University

Verified Software Part II: Technical Details Murali Sitaraman School of CTecomputing Clemson University

What is modular verification? uses implements uses implements uses

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.

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

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

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;

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;

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;

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

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

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;

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;

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;

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;

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

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