Proofs about Programs

Similar documents
Program Verification (Rosen, Sections 5.5)

Func%ons (Math) Func%on Defini%ons. Func%ons (Computer Sciences) Func%on = mappings or transforma%ons Math examples:

CISC327 - So*ware Quality Assurance

CSc 120. Introduc/on to Computer Programming II. 02: Problem Decomposi1on and Program Development. Adapted from slides by Dr.

CISC327 - So*ware Quality Assurance

Automa'c Test Genera'on

CISC327 - So*ware Quality Assurance. Lecture 13 Black Box Unit

Warm-Up Problem. 1. What is the definition of a Hoare triple satisfying partial correctness? 2. Recall the rule for assignment: x (assignment)

Design and Debug: Essen.al Concepts Numerical Conversions CS 16: Solving Problems with Computers Lecture #7

2/18/14. Uses for Discrete Math in Computer Science. What is discrete? Why Study Discrete Math? Sets and Functions (Rosen, Sections 2.1,2.2, 2.

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

Writing a Fraction Class

Functions and Sequences Rosen, Secs. 2.3, 2.4

Main Memory Organization

Func%onal Programming in Scheme and Lisp

BBM 101 Introduc/on to Programming I Fall 2014, Lecture 5. Aykut Erdem, Erkut Erdem, Fuat Akal

Review. Asser%ons. Some Per%nent Ques%ons. Asser%ons. Page 1. Automated Tes%ng. Path- Based Tes%ng. But s%ll need to look at execu%on results

Func%onal Programming in Scheme and Lisp

Vulnerability Analysis (III): Sta8c Analysis

LISP: LISt Processing

BBM 101 Introduc/on to Programming I Fall 2014, Lecture 3. Aykut Erdem, Erkut Erdem, Fuat Akal

UNIT 4B Itera,on: Sor,ng. Sor,ng

Floa=ng- Point Numbers

BBM 101 Introduc/on to Programming I Fall 2014, Lecture 7. Aykut Erdem, Erkut Erdem, Fuat Akal

Model-Based Testing. (DIT848 / DAT261) Spring Lecture 3 White Box Testing - Coverage

Lecture 2. White- box Tes2ng and Structural Coverage (see Amman and Offut, Chapter 2)

Design and Debug: Essen.al Concepts CS 16: Solving Problems with Computers I Lecture #8

Lecture 2. White- box Tes2ng and Structural Coverage (see Amman and Offut, Chapter 2)

CS177 Python Programming. Recita4on 2 - Compu4ng with Numbers

Formal Methods. CITS5501 Software Testing and Quality Assurance

CS101: Fundamentals of Computer Programming. Dr. Tejada www-bcf.usc.edu/~stejada Week 1 Basic Elements of C++

Lectures 20, 21: Axiomatic Semantics

STA 4273H: Sta-s-cal Machine Learning

SQLite with a Fine-Toothed Comb. John Regehr Trust-in-So1 / University of Utah

An Annotated Language

BBM 101 Introduc/on to Programming I Fall 2013, Lecture 6-7

CISC327 - So*ware Quality Assurance

The design recipe. Readings: HtDP, sections 1-5. (ordering of topics is different in lectures, different examples will be used)

Topics. Data Types, Control Flow, Func9ons & Programming. Data Types. Vectoriza9on 8/22/10

CITS5501 Software Testing and Quality Assurance Formal methods

How invariants help writing loops Author: Sander Kooijmans Document version: 1.0

JUnit tes)ng. Elisa Turrini

1KOd17RMoURxjn2 CSE 20 DISCRETE MATH Fall

Algorithms Lecture 11. UC Davis, ECS20, Winter Discrete Mathematics for Computer Science

Introduc)on to C++ CS 16: Solving Problems with Computers I Lecture #2

Overview. A mathema5cal proof technique Proves statements about natural numbers 0,1,2,... (or more generally, induc+vely defined objects) Merge Sort

Founda'ons of So,ware Engineering. Lecture 11 Intro to QA, Tes2ng Claire Le Goues

Hoare Logic: Proving Programs Correct

ques4ons? Midterm Projects, etc. Path- Based Sta4c Analysis Sta4c analysis we know Example 11/20/12

Chapter Summary. Mathematical Induction Recursive Definitions Structural Induction Recursive Algorithms

Program Verification. Program Verification 307/434

Roadmap. The Interface CSE351 Winter Frac3onal Binary Numbers. Today s Topics. Floa3ng- Point Numbers. What is ?

Overview. Verification with Functions and Pointers. IMP with assertions and assumptions. Proof rules for Assert and Assume. IMP+: IMP with functions

Abstract Interpretation

Lecture 3. Black- box Tes3ng

Program Static Analysis. Overview

Lecture 10 Design by Contract

n Specifying what each method does q Specify it in a comment before method's header n Precondition q Caller obligation n Postcondition

Arguing for program correctness and writing correct programs

CS251 Programming Languages Spring 2016, Lyn Turbak Department of Computer Science Wellesley College

SPERNER S LEMMA MOOR XU

LING 581: Advanced Computa7onal Linguis7cs. Lecture Notes April 16th

Warm-Up Problem. Let be a set of well-formed Predicate logic formulas. Let be well-formed Predicate logic formulas. Prove or disprove the following.

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

History of Java. Java was originally developed by Sun Microsystems star:ng in This language was ini:ally called Oak Renamed Java in 1995

Using Classical Planners for Tasks with Con5nuous Ac5ons in Robo5cs

Last Time. integer/float/string. import math math.sqrt() math.pi. Python Programming, 2/e 2

UNIT-II NUMBER THEORY

Instructor: Randy H. Katz hap://inst.eecs.berkeley.edu/~cs61c/fa13. Fall Lecture #7. Warehouse Scale Computer

So#ware Tes+ng. See also Sommerville, Chapter 8 Amman and Offut, Introduc)on to So,ware Tes)ng, Cambridge University Press, 2008.

Lecture 5 - Axiomatic semantics

Classes & Objects CMSC 202

Softwaretechnik. Program verification. Albert-Ludwigs-Universität Freiburg. June 28, Softwaretechnik June 28, / 24

15110 Principles of Computing, Carnegie Mellon University - CORTINA. Digital Data

Lecture 7. Advanced Topics in Tes3ng

Project: Embedded SMC

How a computer runs a program. Binary Representa8on and Opera8ons on Binary Data. Opera8ng System 9/17/13. You can view binary file contents

Testing. Prof. Clarkson Fall Today s music: Wrecking Ball by Miley Cyrus

Rasteriza2on and Clipping

COP 4516: Math for Programming Contest Notes

UNIT V: CENTRAL PROCESSING UNIT

Verification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80

CS11001/CS11002 Programming and Data Structures (PDS) (Theory: 3-0-0)

GENG2140 Lecture 4: Introduc4on to Excel spreadsheets. A/Prof Bruce Gardiner School of Computer Science and SoDware Engineering 2012

Course Wrap-Up. Software Testing and Verification. Stephen M. Thebaut, Ph.D. Prepared by. University of Florida

Backward Reasoning: Rule for Assignment. Backward Reasoning: Rule for Sequence. Simple Example. Hoare Logic, continued Reasoning About Loops

Verifica(on of Concurrent Programs

Inference rule for Induction

(Func&onal (Programming (in (Scheme)))) Jianguo Lu

Hardware versus software

No Source Code. EEC 521: Software Engineering. Specification-Based Testing. Advantages

Lecture Notes: Hoare Logic

9/19/12. Why Study Discrete Math? What is discrete? Sets (Rosen, Chapter 2) can be described by discrete math TOPICS

Introduc4on to Algorithms

Introduction to Axiomatic Semantics

1.3. Conditional expressions To express case distinctions like

Infinity and Uncountability. Countable Countably infinite. Enumeration

D0010E Object- oriented programming and design. Today. Today An introduc<on to the basic syntax and seman<cs of Java

Conditionals !

More Course Overview: Models, Tests, Bugs, and Symbols

Transcription:

Proofs about Programs Program Verification (Rosen, Sections 5.5) TOPICS Program Correctness Preconditions & Postconditions Program Verification Assignment Statements Conditional Statements Loops Composition Rule Why make you study logic? Why make you do proofs? Because we want to prove proper<es of programs: In par<cular, we want to prove proper<es of variables at specific points in a program. For example, we may want prove that a program segment or method gets the right answer. Isn t tes<ng enough? Assuming the program compiles, we can go ahead and perform some amount of tes<ng. Tes<ng shows that for specific examples (test cases) the program is doing what was intended. Tes<ng can only show existence of some bugs but cannot exhaus<vely iden<fy all of them. Program verifica<on can be used to prove the correctness of the program with any input. SoIware Tes<ng Methods Black- box, white- box Levels Unit (Method), Module (Class), Integra<on, System Types Func<onality, Configura<on, Usability, Reliability, Performance, Compa<bility, Error, Localiza<on, Processes Regression, Automa<on, Test- Driven Development, Code Coverage, 1

Program Correctness Proofs We consider a program to be correct if it produces the expected output for all possible inputs. Domain of input values can be very large, how many possible values of an integer? 2 32 int divide (int operand1, int operand2) return operand1 / operand2; 2 32 * 2 32 = 2 64, a large number, so we clearly cannot test exhaus<vely! Instead we formally specify program behavior, then use logic techniques to infer (prove) program correctness. Part 1 - Prove program produces correct answer when (if) it terminates. Part 2 - Prove that the program does indeed terminate at some point. We can only Part 1, because Part 2 is problema<c: Thus we can prove that a method is correct, assuming that it terminates (par<al correctness). Predicate Logic and Programs Asser<ons Variables in programs are like variables in predicate logic: They have a domain of discourse (data type) They have values (drawn from the data type) Variables in programs are different from variables in predicate logic: Their values change over <me (i.e., loca<ons in the program) Associate the predicate with specific program points Immediately before or aier a statement Two parts: Ini$al Asser$on: a statement of what must be true about the input values or values of variables at the beginning of the program segment For Example: Method that determines the square root of a number, requires the input (parameters) to be >= 0 Final Asser$on: a statement of what must be true about the output values or values of variables at the end of the program segment For Example: Can we specify that the output or result is exactly correct aier a call to the method? 2

Pre and Post Condi<ons Hoare Triple Ini$al Asser$on: some<mes called the pre- condi2on Final Asser$on: some<mes called the post- condi2on Note: these asser<ons can be represented as proposi<ons or predicates. For simplicity, we will write them generally as proposi<ons. Pre-condition before code executes x = 1 // Program segment Post-condition z = 3 A program, or program segment, S, is said to be par<ally correct with respect to the ini<al asser<on (pre- condi<on) p and the final asser<on (post- condi<on) q, if, whenever p is true for the input values of S, and if S terminates, then q is true for the output values of S. [Rosen 7th edi<on, p. 372] Nota<on: p S q Pre-condition (p) before code executes // Program segment: (S) Post-condition (q) Example #1: Assignment Statements Assume that our proof system already includes rules of arithme<c, and theorems about divisibility Consider the following code: y = 2; z = x + y; Pre- condi<on: p(x), x =1 Post- condi<on: q(z), z =3 What is true BEFORE code executes What is true AFTER code executes Example #1: Assignment Statements Prove that the program segment: y = 2; z = x + y; Is correct with respect to: pre- condi<on: x = 1 post- condi<on: z = 3 Suppose x = 1 is true as program begins: Then y is assigned the value of 2 Then z is assigned the value of x + y = 1 + 2 = 3 Thus, the program segment is correct with regards to the pre- condi<on that x = 1 and post- condi<on z = 3. 3

Example #2: Assignment Statements Prove that the program segment: y = 2; z = x * y; Is correct with respect to: pre- condi<on: y >= 1 post- condi<on: z >= 2 Suppose y >= 1 is true as program begins: Then x is assigned the value of 2 Then z is assigned the value of x * y = 2 * (y >= 1), which makes z >= 2 Thus, the program segment is correct for pre- condi<on y >= 1 and post- condi<on z >= 2. Example #3: Assignment Statements Prove that the program segment, given integer variables: y = x * x + 2 * x 5; Is correct with respect to: pre- condi<on: - 4<= x <= 1, and post- condi<on: - 6 <= y <= 3 Suppose - 4 <= x and x <=3 as the program begins If x = - 4 then y is assigned (- 4)*(- 4) + 2*(- 4) - 5 = 3 If x = - 3 then y is assigned (- 3)*(- 3) + 2*(- 3) 5 = - 2 If x = - 2 then y is assigned (- 2)*(- 2) + 2*(- 2) 5 = - 5 If x = - 1 then y is assigned (- 1)*(- 1) + 2*(- 1) - 5 = - 6 If x = 0 then y is assigned (0)*(0) + 2*(0) - 5 = - 5 If x = 1 then y is assigned (1)*(1) + 2*(1) 5 = - 2 Thus, program segment is correct post- condi<on - 6 <= y <= 3, or more precisely y belongs to the set - 6, - 5, - 2, 3 Example #4: Assignment Statements Given the following segment, x and y are integer variables: // pre-condition: -3 < x <= 3 y = x * x - 3 * x + 4; // post-condition:?? <= y <=?? Suppose - 3 < x and x <= 3 as the program begins If x = - 2 then y is assigned (- 2)*(- 2) - 3*(- 2) + 4 = 14 If x = - 1 then y is assigned (- 1)*(- 1) - 3*(- 1) + 4 = 8 If x = 0 then y is assigned (0)*(0) - 3*(0) + 4 = 4 If x = 1 then y is assigned (1)*(1) - 3*(1) + 4 = 2 If x = 2 then y is assigned (2)*(2) - 3*(2) + 4 = 2 If x = 3 then y is assigned (3)*(3) - 3*(3) + 4 = 4 Thus, the post- condi<on for y is 2 <= y <= 14. So far only proposi<ons, what about predicates? What if the data type was float or double, or the interval was unbounded? Now we need to use predicates universally quan<fied over a range of values. Actually this is what we did, but simply enumerated all the values in the range since they were integers. Revisit Example #3: with floa<ng point values: Need to use more math Is the func<on increasing? In what intervals? float x, y; // code to initialize x y = x * x 2 * x - 5; 4

Redo with floa<ng point Example #3: Assignment Statements Given that the polynomial below is an increasing func<on in the interval [- 1, 4], prove condi<ons of the program segment: float x, y; f (x) = x 2 // code to initialize x + 2x 5 y = x * x 2 * x - 5; Pre- condi<on: - 1 <= x <= 4 Post- condi<on:?? <= y <=?? Without execu<ng the assignment we know domain of x, so we can prove (using math) the range of y values. Q: What is the range of values of f(x)= x * x 2 * x 5 that sa<sfy f(- 1) f(x) f(4) for values of x in the interval [- 1, 4]? A: We can prove that, - 2 y 3 because f(- 1)=- 2 and f(4)=3 General Rule for Assignments To prove the Hoare triple: p v = expression q note that p and q are predicates involving program variables (usually q involves v) We first replace occurrences of v in q by the right hand side expression (expression) Then we derive this modified q from p using our rules of inference Some<mes we use common sense, e.g., derive first subs<tute later, as in previous. Pre-condition (p) before code executes v = expression; Post-condition (q) Rule 1: Composi<on Rule Once we prove correctness of program segments, we can combine the proofs together to prove correctness of an en<re program. p S1 q S2 r - > p S1,S2 r This is similar to the hypothe<cal syllogism inference rule. Pre-condition (p) before code executes // Program segment S1 Post-condition (q) // Program segment S2 Post-condition (r) Example #1: Composi<on Rule Prove that the program segment (swap): t = x; x = y; y = t; Is correct with respect to pre- condi<on: x = 7, y = 5 post- condi<on: x = 5, y = 7 5

Example #1 (cont.): Composi<on Rule Program segment: t = x; x = y; y = t; Suppose x = 7 and y = 5 is true as program begins: // Pre- condi<on: x = 7, y = 5 t = x; // Post- condi<on: t = 7, x = 7, y = 5 // Pre- condi<on: t = 7, x = 7, y = 5 x = y; // Post- condi<on: t = 7, x = 5, y = 5 // Pre- condi<on: t = 7, x = 5, y = 5 y = t; // Post- condi<on: t = 7, x = 5, y = 7 The program segment is correct with regards to the pre- condi<on x = 7 and y =5 and post- condi<on x = 5 and y = 7. Rule 2: Condi<onal Statements Given if (c) statement; With pre- condi<on: p and post- condi<on: q Must show that Case 1: p && c S q: when p is true and c, the condi<on is true then q (post- condi<on) can be derived, when S (statement) terminates, AND ALSO THAT Case 2: p &&!c à q: when p is true and condi$on is false, then q is true (S does not execute, so we must show that q follows directly from p and!c) Condi<onal Rule: Example #1 Verify that the program segment: if (x > y) y = x; Is correct with respect to pre- condi<on T (program state is correct when entering segment) and the post- condi<on that y >= x. Consider the two cases 1. Condi<on (x > y) is true, then y = x 2. Condi<on (x > y) is false, then that means y >= x Thus, if pre- condi<on is true, then y = x or y >= x which means that the post- condi<on that y >=x is true. Condi<onal Rule: Example #2 Verify that the program segment if (x % 2 == 1) x = x + 1; Is correct with respect to pre- condi<on T and the post- condi<on that x is even. Consider the two cases 1. Condi<on (x % 2 equals 1) is true, then x is odd. If x is odd, then adding 1 makes x even. 2. Condi<on (x % 2 equals 1) is false, then x is already even, and remains even. Thus, if pre- condi<on is true, then either x is even or x is even, so the post- condi<on that x is even is true. 6

Rule 2a: Condi<onal with Else if (condition) S1; else S2; Must show that Case 1: when p (precondi$on) is true and condi$on is true then q (postcondi$on) is true, when S1 (statement) terminates OR Case 2: when p is true and condi$on is false, then q is true, when S2 (statement) terminates Condi<onal Rule: Example #3 Verify that the program segment: if (x < 0) abs = -x; else abs = x; Is correct with respect to pre- condi<on T and post- condi<on that abs is the absolute value of x. Consider the two cases 1. Condi<on (x < 0) is true, x is nega<ve. Assigning abs the nega<ve of a nega<ve means abs is the absolute value of x. 2. Condi<on (x < 0) is false, x is posi<ve. Assigning abs a posi<ve number means abs is the absolute value of x. Thus, if pre- condi<on is true, then the post- condi<on that abs is the absolute value of x is true. Verify that the program segment: Condi<onal Rule: Example #4 if (balance > 100) nbalance = balance *1.02 else nbalance = balance * 1.005; Is correct with respect to pre- condi<on balance > = 0 and post- condi<on: ((balance > 100) && (nbalance = balance * 1.02)) ((balance <= 100) && (nbalance= balance * 1.005)) Consider the two cases 1. Condi<on (balance > 100) is true, assign nbalance to balance*1.02 2. Condi<on (balance > 100) is false, assign nbalance to balance* 1.005 Thus, if precondi<on of balance > = 0 is true, (balance > 100 and nbalance = balance * 1.02) or (balance <= 100 and nbalance = balance * 1.005). Thus the post- condi<on is proven. How to we prove loops correct? General idea: loop invariant Find a property that is true before the loop Show that it must s<ll be true aier every itera<on of the loop Therefore it is true aier the loop 7

Rule 3: Loop Invariant while (condition) S; Rule: ( p condition) Sp p while condition S condition ( p) Note these are both p! Note both conclusions Loop Invariant: Example #1: Simple Assignments Given following program segment, what is loop invariant for z? int x = 2, y = 3, z = v1; while (x <= 4) z += y; x++; - Before loop: z = v1 - During loop: z = v1 + y*(x- 1) Itera<on 1: x = 2, z = v1 + 3 Itera<on 2: x = 3, z = v1 + 6 Itera<on 3: x = 4, z = v1 + 9 - AIer loop: z = v1 + 9 Thus, loop invariant is: y=3; z = v1 + y * (x- 1) Loop Invariant: Example #2: More Assignments int x = 1, y = 2, z = -5; while (x <= 5) z += y; x++; - Before loop: x = 1, y = 2, z = - 5 - During loop: 1 <= x <= 6; y = 2; z = - 5 + 2*x Itera<on 1: x = 1, z = - 3 Itera<on 2: x = 2, z = - 1 Itera<on 3: x = 3, z = 1 Itera<on 4: x = 4, z = 3 Itera<on 5: x = 5, z = 5 - AIer loop: x = 6, y = 2, z = 5 Thus, loop invariant is: 1 <= x <= 6; y = 2; - 5 <=z <= 5 Loop Invariant: Example #3: Factorial Computa<on Given following program segment, what is loop invariant for factorial and i? i = 1; factorial = 1; while (i < n) i++; factorial *= i; - Before loop: i = 1 and because n >= 1, then i <= n, factorial = 1 = 1! = i! - During loop: i < n, and factorial = i! - AIer loop: i = n and because i = n, we know i <= n, so factorial = i! and because i = n, factorial = i! = n! Thus, loop invariant is: i <= n; factorial = i! So we have proven that the program segment terminates with factorial = n!, i.e. it correctly computes the factorial. 8

Loop Invariant Example #4: Euclid s Algorithm What should be the Pre- condi<on (just before loop, P) gcd(in1,in2) = gcd(a,b); && r = b%a Loop Post- condi<on (Q) gcd(in1,in2) = b Loop Invariant (I) gcd(in1,in2) = gcd(a,b); && r = b%a Two steps of the proof: int in1 = scan.nextint(); int in2 = scan.nextint(); int a = in1; int b = in2; int r = b % a; while (r!= 0) b = a; a = r; r = b % a; If I holds before a loop itera<on and the condi<on is true, then aier one execu<on of the loop body, I con<nues to hold with the new values gcd(in1,in2) = gcd(a,b); && r = b%a!=0 à gcd(in1,in2) = gcd(b,b%a); && r = b%a If I holds before a loop itera<on and the condi<on is false, then Q holds gcd(in1,in2) = gcd(a,b); && r = b%a = 0 à gcd(in1,in2) = b; 9