13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.

Slides:



Advertisements
Similar presentations
Chapter 4: Control Structures I (Selection)
Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Program verification: flowchart programs Book: chapter 7.
Program verification: flowchart programs Book: chapter 7.
PZ03D Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, PZ03D - Program verification Programming Language Design.
Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.
Reasoning About Code; Hoare Logic, continued
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
11111 Functional Program Verification CS 4311 A. M. Stavely, Toward Zero Defect Programming, Addison-Wesley, Y. Cheon and M. Vela, A Tutorial on.
Axiomatic Verification I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 17.
Axiomatic Semantics The meaning of a program is defined by a formal system that allows one to deduce true properties of that program. No specific meaning.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Predicate Transformers
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
CS 355 – Programming Languages
CSE115/ENGR160 Discrete Mathematics 04/12/11 Ming-Hsuan Yang UC Merced 1.
Axiomatic Semantics Dr. M Al-Mulhem ICS
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
4/17/2017 Section 3.6 Program Correctness ch3.6.
Describing Syntax and Semantics
Floyd Hoare Logic. Semantics A programming language specification consists of a syntactic description and a semantic description. Syntactic description:symbols.
Proving Program Correctness The Axiomatic Approach.
Proving Program Correctness The Axiomatic Approach.
Predicates and Quantifiers
Reading and Writing Mathematical Proofs
Chapter 3 (Part 3): Mathematical Reasoning, Induction & Recursion  Recursive Algorithms (3.5)  Program Correctness (3.6)
© by Kenneth H. Rosen, Discrete Mathematics & its Applications, Sixth Edition, Mc Graw-Hill, 2007 Chapter 4 (Part 3): Mathematical Reasoning, Induction.
1 Inference Rules and Proofs (Z); Program Specification and Verification Inference Rules and Proofs (Z); Program Specification and Verification.
Proofs of Correctness: An Introduction to Axiomatic Verification Prepared by Stephen M. Thebaut, Ph.D. University of Florida CEN 5035 Software Engineering.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
Chapter 25 Formal Methods Formal methods Specify program using math Develop program using math Prove program matches specification using.
Program Correctness. 2 Program Verification An object is a finite state machine: –Its attribute values are its state. –Its methods optionally: Transition.
Recursive Algorithms &
Reasoning about programs March CSE 403, Winter 2011, Brun.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Semantics In Text: Chapter 3.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Cs7100(Prasad)L18-9WP1 Axiomatic Semantics Predicate Transformers.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
Chapter 4 (Part 3): Mathematical Reasoning, Induction & Recursion
CSE15 Discrete Mathematics 04/12/17
Math/CSE 1019C: Discrete Mathematics for Computer Science Fall 2012
Formal Methods in Software Engineering 1
Mathematical Structures for Computer Science Chapter 1
Lecture 5 Floyd-Hoare Style Verification
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Logic for Computer Security Protocols
Semantics In Text: Chapter 3.
Axiomatic Verification I
Predicate Transformers
Formal Methods in software development
Proofs of Correctness: An Introduction to Axiomatic Verification
Axiomatic Verification I
PZ03D - Program verification
PZ03D - Program verification
The Zoo of Software Security Techniques
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Program Correctness an introduction.
Presentation transcript:

13 Aug 2013 Program Verification

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

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

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

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 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 Pre-conditions before code executes x = 1

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 p is true for the input values of S and S terminates, then q is true for the output values of S.” [Rosen 7 th edition, p. 372] Notation: p{S}q { // prgm code: S } Post-conditions after code executes q Pre-conditions before code executes p

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

Simple Example, continued Here {S} contains two code statements So, p {S} q for this example is (p(x), x =1)   (q(z), z =3) y = 2; z = x + y; y = 2; z = x + y; p Pre-Condition x = 1 Post-Condition q z = 3 S : Program Segment  

Rule 1: Composition Rule Once we prove correctness of program segments, we can combine the proofs together to prove correctness of an entire program. { // prgm code: S1 } Post-conditions after code executes Is pre-condition for next q Pre-conditions before code executes p { // prgm code: S2 } Post-conditions after code executes r

Rule 2: Conditional Statements Given if (condition) statement; and Initial assertion: p Final assertion: q What does this mean? What must we prove? If ( condition ) { S } Post-conditions after code executes q Pre-conditions before code executes p

Rule 2: Conditional Statements, … Given if (condition) statement; with Initial assertion: p and Final assertion: q Must show that when p is true and condition is true then q is true when S terminates: when p is true and condition is false, then q is true ( S does not execute)

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

Conditional Rule Example if (x > y) y = x; Initial assertion: T (true) Final assertion: q(y,x) means y  x (p(x), true)   (q(y,x), y  x) if (x > y) 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

Conditional Rule 2 Example Verify the the program segment if (x % 2 == 1) x = x + 1 Is correct with respect to the initial assertion T and the final assertion x is even

Rule 2a: Conditional with Else if (condition) S1; else S2; Rule is:

Conditional Rule 2a Example if (x < 0) abs = -x; else abs = x; Initial assertion: T (true) Final assertion: q(abs), abs=|x| (p(x), true)   (q(abs), abs=|x|) if (x < 0) abs = -x; else abs = x;

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 abs = |x| else abs = x; // x >= 0 -> abs = x // abs = |x| Initial assertion: T Final assertion: q(abs), abs=|x|

Conditional Rule 2a Example Verify the the program segment if (balance > 100) newBalance = balance * 1.02 else newBalance = balance * Is correct with respect to the initial assertion balance > 0 and the final assertion (balance > 100 ^ newBalance = balance * 1.02) v (balance <= 100 ^ newBalance = balance * 1.005)

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

Rule 3: Loop Invariant while (condition) S; Rule: Note these are both p! Note both conclusions

Loop Invariant Example k = 1; i = 0; while (i < n) { k = k * 10; i = i + 1; } Initial assertion: n > = 0 Final assertion q(k, n) means k = 10 ^ n

Loop Invariant Example (Cont.) What is the loop invariant? k = 10 ^ i i <= n Evaluate program segment Before entering loop If loop terminates, p true and i < n false After loop, k = 10 ^i and i = n, so i = n and k = 10^i = 10^n

Loop Invariant Example i = 1; factorial = 1; while (i < n) { i = i + 1; factorial = factorial * i; } Initial assertion: n >= 1 Final assertion q(factorial, n) is factorial = n!

Loop Invariant Example (Cont.) What is the loop invariant? factorial = i! i <= n Evaluate program segment Before entering loop If loop terminates, p true and i < n false After loop, factorial = i! and i = n, so i = n and factorial = i! = n!