1 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Lecture 10: Formal Verification Formal Methods Basics of Logic first order.

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

ICE1341 Programming Languages Spring 2005 Lecture #6 Lecture #6 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.
Reasoning About Code; Hoare Logic, continued
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
David Evans CS655: Programming Languages University of Virginia Computer Science Lecture 19: Minding Ps & Qs: Axiomatic.
Partial correctness © Marcelo d’Amorim 2010.
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.
Copyright © 2006 Addison-Wesley. All rights reserved. 3.5 Dynamic Semantics Meanings of expressions, statements, and program units Static semantics – type.
1 Discrete Structures Lecture 29 Predicates and Programming Read Ch
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Formal Specification and Verification. Specifications Imprecise specifications can cause serious problems downstream Lots of interpretations even with.
Program Proving Notes Ellen L. Walker.
CSE 331 Software Design & Implementation Dan Grossman Winter 2014 Lecture 2 – Reasoning About Code With Logic 1CSE 331 Winter 2014.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
Weakest pre-conditions and towards machine consistency Saima Zareen.
CS 355 – Programming Languages
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Axiomatic Semantics Dr. M Al-Mulhem ICS
CS 330 Programming Languages 09 / 18 / 2007 Instructor: Michael Eckmann.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Describing Syntax and Semantics
MCA –Software Engineering Kantipur City College. Topics include  Formal Methods Concept  Formal Specification Language Test plan creation Test-case.
Reading and Writing Mathematical Proofs
University of Toronto Department of Computer Science CSC444 Lec08 1 Lecture 8: Testing Verification and Validation testing vs. static analysis Testing.
1 Program Correctness CIS 375 Bruce R. Maxim UM-Dearborn.
1 Inference Rules and Proofs (Z); Program Specification and Verification Inference Rules and Proofs (Z); Program Specification and Verification.
Chapter 25 Formal Methods Formal methods Specify program using math Develop program using math Prove program matches specification using.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
Chapter 5: Sequences, Mathematical Induction, and Recursion 5.5 Application: Correctness of Algorithms 1 [P]rogramming reliability – must be an activity.
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.
Chapter 3 Part II Describing Syntax and Semantics.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
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.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Dr. Naveed Riaz Design and Analysis of Algorithms 1 1 Formal Methods in Software Engineering Lecture # 26.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
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.
Zach Tatlock / Winter 2016 CSE 331 Software Design and Implementation Lecture 2 Formal Reasoning.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini IX. System Models (III)
CENG 424-Logic for CS Introduction Based on the Lecture Notes of Konstantin Korovin, Valentin Goranko, Russel and Norvig, and Michael Genesereth.
Reasoning About Code.
Reasoning about code CSE 331 University of Washington.
Formal Methods in Software Engineering 1
Mathematical Structures for Computer Science Chapter 1
Formal Program Specification
Reasoning About Code; Hoare Logic
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
Semantics In Text: Chapter 3.
Predicate Transformers
Formal Methods in software development
The Zoo of Software Security Techniques
Program Verification with Hoare Logic
Programming Languages and Compilers (CS 421)
Formal Program Specification
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

1 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Lecture 10: Formal Verification Formal Methods Basics of Logic first order predicate logic Program proofs: input/output assertions intermediate assertions proof rules Practical formal methods

2 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Motivation Here is a specification …and here is a program does the program meet the specification? void merge(int a[ ], a_len, b[ ], b_len, *c) /*requires a and b are sorted arrays of integers of length a_len and b_len respectively; c is an array that is at least as long as a_len+b_len. effects: c is a sorted array containing all the elements of a and b. */ void merge(int a[ ], a_len, b[ ], b_len, *c) /*requires a and b are sorted arrays of integers of length a_len and b_len respectively; c is an array that is at least as long as a_len+b_len. effects: c is a sorted array containing all the elements of a and b. */ int i = 0, j = 0, k = 0; while (k < a_len+b_len) { if (a[i] < b[j]) { c[k] = a[i]; i++; } else { c[k] = b[j]; j++; }; k++; } int i = 0, j = 0, k = 0; while (k < a_len+b_len) { if (a[i] < b[j]) { c[k] = a[i]; i++; } else { c[k] = b[j]; j++; }; k++; }

3 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Notes on Logic We will need a suitable logic First Order Propositional Logic provides: a set of primitives for building expressions: variables, numeric constants, brackets a set of logical connectives: and (  ), or (  ), not (  ), implies (  ), logical equality (  ) the quantifiers:  - “for all”  - “there exists” a set of deduction rules Expressions in FOPL expressions can be true or false (x>y  y>z)  x>z x=y  y=x  x,y,z ((x>y  y>z))  x>z)  x+1 < x-1   x (  y (y=x+z))  x>3  x<-6

4 University of Toronto Department of Computer Science © 2001, Steve Easterbrook More notes on Logic Free vs. bound variables a variable that is not quantified is free a variable that is quantified is bound E.g.  x (  y (y=x+z)) x and y are bound z is free Closed formulae if all the variables in a formula are bound, the formula is closed a closed formula is either true or false the truth of a formula that is not closed cannot be determined (it depends on the environment) we can close any formula by quantifying all free variables with  if a formula is true for all values of its free variables then its closure is true.

5 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Input/Output Assertions Pre-conditions and Post-conditions we could formalize: a requires clause as a pre-condition an effects clause as a post-condition e.g. for a program with inputs i 1, i 2, i 3 and return value r, we could specify the program by: where Pre(i 1, i 2, i 3 ) is a logic statement that refers to i 1, i 2, i 3 The specification then says: “if Pre(i 1, i 2, i 3 ) is true before executing the program then Post(r, i 1, i 2, i 3 ) should be true after it terminates” E.g. { Pre( i 1, i 2, i 3 ) } Program { Post( r, i 1, i 2, i 3 ) } { Pre( i 1, i 2, i 3 ) } Program { Post( r, i 1, i 2, i 3 ) } { true } Program { (r= i 1  r= i 2 )  r >= i 1  r >= i 2 } { true } Program { (r= i 1  r= i 2 )  r >= i 1  r >= i 2 }

6 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Strength of Preconditions Strong preconditions a precondition limits the range of inputs for which the program must work a strong precondition places fewer constraints the strongest possible precondition is {true} (same as an empty “requires” clause) it is harder for a program to meet a spec that has a stronger precondition a weak precondition places more constraints the weakest possible precondition is {false} …which means that there are no conditions under which the program has to work every program meets this spec!!! precondition A is stronger than B if: B implies A read implies as “is not as true as” or “is true in fewer cases than” {  z (a=z*b and z>0) } x := divide(a, b); { x*b=a } {  z (a=z*b and z>0) } x := divide(a, b); { x*b=a } { a>=b } x := divide(a, b); {  c (x*b+c=a and c>=0 and c<b) } { a>=b } x := divide(a, b); {  c (x*b+c=a and c>=0 and c<b) } this precondition is stronger it doesn’t require a to be a multiple of b (  z (a=z*b and z>0)) implies (a>=b)

7 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Correctness Proofs Program correctness if we write formal specifications we can prove that a program meets its specification “program correctness” only makes sense in relation to a specification To prove a program is correct: We need to prove the post-condition is true after executing the program (assuming the pre-condition was true beforehand) E.g. Step 1: for z>0 to be true after the assignment, x*y>0 must have been true before it Step 2: for x*y>0 to be true before the assignment, the precondition must imply it. Step 3: show that (x>0 and y>0) implies x*y>0 (after closure) { x>0 and y>0 } z := x*y; { z>0 } { x>0 and y>0 } z := x*y; { z>0 }

8 University of Toronto Department of Computer Science © 2001, Steve Easterbrook The general strategy is: 1) start with the post-condition 2) work backwards through the program line-by-line 3) find the weakest pre-condition (WP) that guarantees the post-condition 4) prove that the actual pre-condition implies WP i.e. the actual pre-condition is weaker than the “weakest pre-condition”, WP For example 1) for Post to be true after S 2, then x<1 must be true before S 2 2) for x<1 to be true after S 1, then 0<1 must be true before S 1 3) (0<1) is the weakest precondition for this program 4) So is (true implies 0<1) true? Weakest Pre-conditions Pre S 1 S 2 Post Pre S 1 S 2 Post { true } x := 0; y := 1 { x<y } { true } x := 0; y := 1 { x<y }

9 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Proof rules tell us how to find weakest preconditions for different programs we need a proof rule for each programming language construct Proof rule for assignment e.g. for the weakest precondition is Post with all free occurrences of x replaced by e Proof rule for sequence e.g. for if WP 2 is the weakest precondition for S 2, then the weakest precondition for the whole program is the same as the weakest precondition for { Pre } S 1 { WP 2 } { Pre } x := e; { Post } { Pre } x := e; { Post } { Pre } S 1 ; S 2 { Post } { Pre } S 1 ; S 2 { Post }

10 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Hoare Notation We can express proof rules more concisely e.g. using Hoare notation: this means “if claim 1 and claim 2 have both been proved, then conclusion must be true” E.g. for sequence: E.g. for if statements: find the weakest precondition for S 1 and the weakest precondition for S 2. Then show ((Pre and c) implies WP S 1 ) and ((Pre and not(c)) implies WP S 2 ) claim 1, claim 2,... conclusion {Pre}S 1 {Q}, {Q}S 2 {Post} {Pre}S 1 ; S 2 {Post} {Pre and c}S 1 {Post}, {Pre and not(c)}S 2 {Post} {Pre}if (c) then S 1 else S 2 {Post}

11 University of Toronto Department of Computer Science © 2001, Steve Easterbrook E.g. 1) the first branch: to find the weakest precondition, substitute x for max: WP 1 = {(x=x or x=y) and (x>=x) and (x>=y)} = {(true or x=y) and true and (x>=y)} = {(true) and (x>=y)} = {x>=y} which is okay because (Pre and c) implies WP 1, {true and x>y} implies {x>=y} { true } if (x>y) then max := x; else max := y; { (max=x or max=y) and max>=x and max>=y) } { true } if (x>y) then max := x; else max := y; { (max=x or max=y) and max>=x and max>=y) } 2) the second branch: to find the weakest precondition, substitute y for max: WP2= {(y=x or y=y) and (y>=x) and (y>=y)} = {(y=x or true) and (y>=x) and true} = {(true) and (y>=x)} = {y>=x} which is okay because (Pre and not(c)) implies WP2, {true and not(x>y)} implies {y>=x} { true and x>y } max := x; { Post } { true and x>y } max := x; { Post } { true and not(x>y) } max := y; { Post } { true and not(x>y) } max := y; { Post } Proving an IF statement

12 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Program proofs are not (currently) widely used: they can be tedious to construct they tend to be longer than the programs they refer to they could contain mistakes too! they require mathematical expertise they do not ensure against hardware errors, compiler errors, etc. they only prove functional correctness (i.e. not termination, efficiency,…) Practical formal methods: Just use for small parts of the program e.g. isolate the safety-critical parts Use to reason about changes to a program e.g. prove that changing a statement preserves correctness Automate some of the proof use proof checkers and theorem provers Use formal reasoning for other things test properties of the specification to see if we got the spec right ie. use for validation, rather than verification Practicalities

13 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Other approaches Model-checking A model checker takes a state-machine model and a temporal logic property and tells you whether the property holds in the model temporal logic adds modal operators to propositional logic: e.g.  x - x is true now and always (in the future) e.g.  x - x is true eventually (in the future) The model may be: of the program itself (each statement is a ‘state’) an abstraction of the program a model of the specification a model of the domain Model checking works by searching all the paths through the state space …with lots of techniques for reducing the size of the search Model checking does not guarantee correctness… it only tells you about the properties you ask about it may not be able to search the entire state space (too big!) …but is (generally) more practical than proofs of correctness.

14 University of Toronto Department of Computer Science © 2001, Steve Easterbrook References van Vliet, H. “Software Engineering: Principles and Practice (2nd Edition)” Wiley, Section 15.4 gives a very brief introduction to program proofs, and includes some pointers to more readings. The rest of chapter 15 covers some other uses of formal analysis for specifications. In particular, section 15.5 is a nice summary of the arguments in favour of formal methods. Easterbrook, S. M., Lutz, R., Covington, R., Kelly, J., Ampo, Y. & Hamilton, D. “Experiences Using Lightweight Formal Methods for Requirements Modeling”. IEEE Transactions on Software Engineering, vol 24, no 1, pp1-11, 1998 Provides an overview of experience with practical formal methods for requirements validation. Is available from my web page ( F. Schneider, S. M. Easterbrook, J. R. Callahan and G. J. Holzmann, "Validating Requirements for Fault Tolerant Systems using Model Checking" Third IEEE Conference on Requirements Engineering, Colorado Springs, CO, April 6-10, Presents a case study of the use of model checking for validating requirements. Is available from my web page (