Proofs of Program Correctness

Similar documents
Rigorous Software Development CSCI-GA

Loop Invariants and Binary Search

Lecture Notes on Linear Search

Handout #1: Mathematical Reasoning

Chapter 3. Cartesian Products and Relations. 3.1 Cartesian Products

Predicate Logic. Example: All men are mortal. Socrates is a man. Socrates is mortal.

3. Mathematical Induction

Verification of Imperative Programs in Theorema

Logistics. Software Testing. Logistics. Logistics. Plan for this week. Before we begin. Project. Final exam. Questions?

Practice Questions. CS161 Computer Security, Fall 2008

Rigorous Software Engineering Hoare Logic and Design by Contracts

Boolean Expressions, Conditions, Loops, and Enumerations. Precedence Rules (from highest to lowest priority)

How To Write A Program Verification And Programming Book

Constructing Contracts: Making Discrete Mathematics Relevant to Beginning Programmers

Mathematical Induction. Mary Barnes Sue Gordon

Formal Engineering for Industrial Software Development

Lecture 1. Basic Concepts of Set Theory, Functions and Relations

3 Some Integer Functions

INCIDENCE-BETWEENNESS GEOMETRY

Discrete Mathematics and Probability Theory Fall 2009 Satish Rao, David Tse Note 2

Outline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References

Elementary Number Theory and Methods of Proof. CSE 215, Foundations of Computer Science Stony Brook University

A simple algorithm with no simple verication

Software Testing. Quality & Testing. Software Testing

def: An axiom is a statement that is assumed to be true, or in the case of a mathematical system, is used to specify the system.

Chapter 2: Algorithm Discovery and Design. Invitation to Computer Science, C++ Version, Third Edition

Binary Multiplication

Boolean Algebra Part 1

A Static Analyzer for Large Safety-Critical Software. Considered Programs and Semantics. Automatic Program Verification by Abstract Interpretation

Mathematics for Computer Science/Software Engineering. Notes for the course MSM1F3 Dr. R. A. Wilson

Practice Problems on NIPA and Key Prices

Lecture 3: Finding integer solutions to systems of linear equations

Functional Programming. Functional Programming Languages. Chapter 14. Introduction

Automated Theorem Proving - summary of lecture 1

MATHEMATICAL INDUCTION. Mathematical Induction. This is a powerful method to prove properties of positive integers.

9.4. The Scalar Product. Introduction. Prerequisites. Learning Style. Learning Outcomes

InvGen: An Efficient Invariant Generator

CHAPTER 3. Methods of Proofs. 1. Logical Arguments and Formal Proofs

ASSEMBLY PROGRAMMING ON A VIRTUAL COMPUTER

Formal Methods for Software Development

StaRVOOrS: A Tool for Combined Static and Runtime Verification of Java

PROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE

Page 331, 38.4 Suppose a is a positive integer and p is a prime. Prove that p a if and only if the prime factorization of a contains p.

Relational Database Design: FD s & BCNF

Module 10. Coding and Testing. Version 2 CSE IIT, Kharagpur

FOUNDATIONS OF ALGEBRAIC GEOMETRY CLASS 22

Problem Solving Basics and Computer Programming

Mathematical Induction

What is a Loop? Pretest Loops in C++ Types of Loop Testing. Count-controlled loops. Loops can be...

Software Engineering

Computational Models Lecture 8, Spring 2009

WRITING PROOFS. Christopher Heil Georgia Institute of Technology

Unit testing using Python nose

Introduction to Computers and Programming. Testing

Part I. The Picture class

Mathematical Induction. Lecture 10-11

What Is Recursion? Recursion. Binary search example postponed to end of lecture

Lecture 16 : Relations and Functions DRAFT

Chapter 1: Key Concepts of Programming and Software Engineering

CS 103X: Discrete Structures Homework Assignment 3 Solutions

1.2 Solving a System of Linear Equations

Algorithm & Flowchart & Pseudo code. Staff Incharge: S.Sasirekha

Moving from CS 61A Scheme to CS 61B Java

CPSC 121: Models of Computation Assignment #4, due Wednesday, July 22nd, 2009 at 14:00

Chapter 15 Functional Programming Languages

What's Wrong With Formal Programming Methods? Eric C.R. Hehner

COMPUTER SCIENCE. Paper 1 (THEORY)

Automated Program Behavior Analysis

WHAT ARE MATHEMATICAL PROOFS AND WHY THEY ARE IMPORTANT?

This asserts two sets are equal iff they have the same elements, that is, a set is determined by its elements.

Formal Languages and Automata Theory - Regular Expressions and Finite Automata -

KS3 Computing Group 1 Programme of Study hours per week

Regression Verification: Status Report

CMPSCI 250: Introduction to Computation. Lecture #19: Regular Expressions and Their Languages David Mix Barrington 11 April 2013

A Framework for the Semantics of Behavioral Contracts

Formal Verification of Software

CHAPTER 7 GENERAL PROOF SYSTEMS

High-Level Programming Languages. Nell Dale & John Lewis (adaptation by Michael Goldwasser)

Chapter 2. Binary Values and Number Systems

Math Circle Beginners Group October 18, 2015

CS510 Software Engineering

Section 1.1 Real Numbers

8 Divisibility and prime numbers

The Road from Software Testing to Theorem Proving

Quotient Rings and Field Extensions

Runtime Verification of Computer Programs and its Application in Programming Education

Design by Contract beyond class modelling

Chapter 7: Additional Topics

Rigorous Software Development CSCI-GA

CS177 MIDTERM 2 PRACTICE EXAM SOLUTION. Name: Student ID:

Solutions Q1, Q3, Q4.(a), Q5, Q6 to INTLOGS16 Test 1

How to write proofs: a quick guide

CS 141: Introduction to (Java) Programming: Exam 1 Jenny Orr Willamette University Fall 2013

Transcription:

Proofs of Program Correctness CS160 Spring 2012 Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs In particular, we want to prove properties of variables at specific points in a program 1

Isn t testing enough? Assuming the program compiles Testing demonstrates for specific examples that the program seems to be running as intended. Testing can only show existence of some bugs rather than exhaustively identifying all of them. Verification however Program Verification We consider a program to be correctif it produces the expected output for every possible input. This requires a formal specification of program behavior and techniques for inferring correctness. Fortunately, we know about logic. 2

Program Correctness Proofs Two parts: Correct answer when the program terminates (called partial correctness) The program does terminate We will only do part 1 Prove that a method is correct if it terminates Predicate Logic & Programs 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 time 3

Specification of Program Segments Two parts: Initial Assertion:a statement of what must be true about the input values or values of variables at the beginning of the program segment E.g Method that determines the sqrt of a number, requires the input (parameters) to be >= 0 Final Assertion: a statement of what must be true about the output values or values of variables at the end of the program segment E.g. What is the output/final result after a call to the method? Specification of Program Segments Initial Assertion:sometimes called the precondition Final Assertion: sometimes called the postcondition Pre-conditions before code executes z = 3 Note: these assertions can be represented as propositions or predicates. For simplicity, we will write them generally as propositions. { // prgm code Post-conditions after code executes z = 3 4

Hoare Triple A program, or program segment, S, is said to be partially correct with respect to the initial assertion p and the final assertion q if, whenever pis true for the input values of S and Sterminates, then qis true for the output values of S. [Rosen 7 th edition, p. 372] Notation: p{sq Pre-conditions before code executes p { // prgm code: S Post-conditions after code executes q Simple Example Assume that our proof system already includes rules of arithmetic Consider the following code: y = 2; z = x + y; Initial Assertion: p(x), x =1 Final assertion: q(z), z =3 What is true BEFORE code executes What is true AFTER code executes 5

Simple Example, continued Here {S contains two code statements So, p {S q for this example is { y = 2; (p(x), x =1) z = x + y; (q(z), z =3) p Pre-Condition x = 1 S : Program Segment { y = 2; z = x + y; Post-Condition q z = 3 Rule 1: Composition Rule Once we prove correctness of program segments, we can combine the proofs together to prove correctness of an entire program. p{ S 1 q q{ S 2 r p{ S 1 ;S 2 r Pre-conditions before code executes p { { // prgm code: S1 Post-conditions after code executes Is pre-condition for next q // prgm code: S2 Post-conditions after code executes r 6

Rule 2: Conditional Statements Given if (condition) and statement; Initial assertion: p Final assertion: q What does this mean? What must we prove? Pre-conditions before code executes p If ( condition ) { S Post-conditions after code executes q Rule 2: Conditional Statements, Given if (condition) statement; with Initial assertion: p and Final assertion: q Must show that when pis true and conditionis true then qis true when Sterminates: ( p condition){ Sq when pis true and conditionis false, then qis true (S does not execute) p condition ( ) q 7

Conditional Rule Example if (x > y) y = x; Initial assertion: T (true) Final assertion: q(y,x) means y x Consider the two cases Conditional Rule ( p condition) { Sq ( p condition) q p{ if conditionsq 8

Conditional Rule Example if (x > y) y = x; Initial assertion: T (true) Final assertion: q(y,x) means y x (p(x), true) { if (x > y) y = x; (q(y,x), y x) Conditional Rule Example (in code) input x, y;... // Initial: true if (x > y) y = x; // Final: y>=x.... Initial assertion: T (true) Final assertion: q(y,x) means y x 9

Rule 2a: Conditional with Else if (condition) S1; else S2; Rule is: p condition ( ) S 1 ( p condition) S 2 { q { q p{ if condition S 1 else S 2 q Conditional Rule 2a Example if (x < 0) abs = -x; else abs = x; Initial assertion: T (true) Final assertion: q(abs), abs= x if (x < 0) { abs = -x; (p(x), true) (q(abs), else abs = x; abs= x ) 10

Conditional Rule 2a Example if (x < 0) abs = -x; else abs = x; Initial assertion: T (true) Final assertion: q(abs), abs= x Consider the two cases Conditional Rule 2a, Code // true if (x < 0) abs = -x; // x < 0 -> abs = x else abs = x; // x >= 0 -> abs = x // abs = x Initial assertion: T Final assertion: q(abs), abs= x 11

Example Method (factorial) public int factorial(int n) { int target; if (n < 1) target = 1; else target = n; int ctr = 1; int result = 1; while (ctr < target) { ctr++; result *= ctr; return result; Task: prove factorial correct Prove that the value returned by factorial(n) is n! Using: Logic predicate or propositional Arithmetic which we assume to be part of logic Hoare triples Which we briefly introduced earlier But will now expand to cover loops 12

How to Start The Key to Proofs: Decomposition Just like programming! Prove properties of pieces of code Straight-line segments of code Control blocks: If statement, loops, etc. Put them back together Rule 1: Composition Rule Once we prove correctness of program segments, we can combine the proofs together to prove correctness of an entire program. p{ S 1 q q{ S 2 r p{ S 1 ;S 2 r 13

Back to factorial public int factorial(int n) { int target; if (n < 1) target = 1; else target = n; int ctr = 1; int result = 1; while (ctr < target) { ctr++; result *= ctr; return result; Part 1: conditional Part 2: Straight-line code Part 3: Loop Rule 2: Conditional Statements Given if (condition) ( p condition) S statement; p condition and Initial assertion: p p if condition S Final assertion: q Must show that when pis true and conditionis true then qis true when S terminates (case 1) when pis true and conditionis false, then qis true (Sdoes not execute) (case 2) { q ( ) q { q 14

Rule 2a: Conditional with Else if (condition) S1; else S2; Rule is: ( p condition){ S1 q ( p condition){ S 2 q p{ if condition S else S q 1 2 Conditional Rule Example int target; if (n < 1) target = 1; else target = n; Code Fragment Initial assertion: T (i.e. nothing) Condition: less(n, 1) Final assertions: geq(target, 1) Eq(n, target) (less(n,1) eq(target, 1)) Consider the two cases 15

Case 1: condition is true N < 1 (because the condition is true) Target = 1 (because of S1) Postcondition Proof Case 1: condition ( ){ S q p 1 ( T less( n,1) ){ target = 1 ( eq( target, n) ( less( n,1) eq( target,1) )) eq(target, 1) Assignment geq(target, 1) Arithmetic (#1) less(n,1) Condition (assumed true) less(n,1) eq(1, target) Addition (#1,#3) eq(n, target) (less(n,1) eq(target, 1)) Implication (#4) Proposition Key geq(x,y) x >= y less(x,y) x < y eq(x,y) x = y 16

Proof Case 2: condition ( ){ S q p 2 ( T geq( n,1) ){ target = n ( geq( target,1) ( less( n,1) eq( target,1) )) geq(n, 1) Condition Negation eq(n,target) Assignment geq(target,1) Transitivity (#2,#3) eq(n, target) (less(n,1) eq(target, 1)) Implication (#6) Now back to Rule 2 (if/else) ( p condition){ S1 q ( p condition){ S 2 q p{ if condition S else S q P: T Condition: geq(n,1) S1: target = 1; S2: target = n; Q: geq(target, 1), eq(n, target) (less(n,1) eq(target, 1)) 1 2 17

Back to factorial, part 2 int ctr = 1; int result = 1; Code Fragment How do we pick the preconditions? We don t need any to prove post-conditions But we will need some for the chain rule later Adopt the post-conditions from part 1 as preconditions How do we pick the postconditions? Inspiration (more later ) Preconditions: geq(target, 1) Part 2 Formalized eq(n, target) (less(n,1) eq(target, 1)) Postconditions: geq(target, 1) eq(n, target) (less(n,1) eq(target, 1)) eq(result, ctr!) 18

Definition of factorial To prove this last postcondition formally, we need to define factorial: n! n fac 1, n 1 ( n ) 1, n > 1 geq(target, 1) Part 2 Proof Precondition eq(n, target) (less(n,1) eq(target, 1)) Precondition eq(ctr, 1) eq(result, 1) eq(ctr, result!) Assignment Assignment Def. of factorial 19

Why do I need the extra preconditions? Remember the composition rule { S1 { q S2 r p{ S1; S2r In traditional logic, once a statement is true it is always true. In code proofs, it could change (e.g. by assignment) You can only assert preconditions as true if not contradicted by the code fragment Therefore you must show that the preconditions are still true after the code p q How to we prove loops correct? General idea: loop invariant Find a property that is true before the loop Show that it must still be true after every iteration Therefore it is true after the loop 20

Rule 3: Loop Invariant while (condition) S; Rule: ( p condition) { Sp p while condition S Note these are both p! { ( condition p) Note both conclusions Back to factorial, part 2 int ctr = 1; int result = 1; while (ctr < target) { ctr++; result *= ctr; return result; What is true (a) before the loop and (b) after each iteration of the loop? Hint: this function is computing factorial 21

Loop Invariants Initial assertions P: eq(ctr!, result) Before the start of the loop, result= ctr! Because 1 = 1! geq(target, 1) Before the start of the loop, target >= 1 eq(n, target) (less(n,1) eq(target, 1)) Target is either n or 1 (if n < 1) Condition: less(ctr, target) Final assertions: eq(ctr, target) eq(ctr!, result) Part 3 Proof ( p condition) { Sp p while condition S { ( condition p) less(ctr, target) Condition (assume true) eq(ctr_1!, result_1) Precondition eq(ctr_2, ctr_1+1) Assignment eq(result_2, ctr_2*result_1!) Assignment eq(result_2, (ctr_1+1)*result_1!) Arithmetic eq(result_2, ctr_2!) Def. of factorial Note #1: I use ctr_1 to denote the initial value of ctr, and ctr_2 to denote the value of ctr at end of loop 22

Now put it all together The preconditions of this proof match the post-conditions of the previous step, so. We can assert P: eq(result, ctr!) eq(n, target) (less(n,1) eq(target, 1)) We can assert the negation of the condition eq(ctr, target) Slight fudge here So by the associative laws eq(result, ctr!) eq(ctr, target) eq(n, target) or eq(result, ctr!) eq(ctr, target) eq(target,1) less(n,1) By our definition of factorial, both cases imply eq(result, n!) QED What to take away Correctness proofs Yes, they are long But do-able if you know logic & arithmetic Necessary for safety-critical systems Termination is still unproved Loop Invariants Common program analysis technique Used for documentation, debugging 23