Exam 2 Help Session Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification.

Slides:



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

Functional Verification III Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture Notes 23.
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.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
3.3 Divisibility Definition If n and d are integers, then n is divisible by d if, and only if, n = dk for some integer k. d | n  There exists an integer.
Axiomatic Verification I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 17.
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
Predicate Transformers
Program Proving Notes Ellen L. Walker.
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.
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.
Describing Syntax and Semantics
Methods of Proof & Proof Strategies
CSE 755, part3 Axiomatic Semantics Will consider axiomatic semantics (A.S.) of IMP: ::=skip | | | | ; | | Only integer vars; no procedures/fns; vars declared.
Reading and Writing Mathematical Proofs
1 Program Correctness CIS 375 Bruce R. Maxim UM-Dearborn.
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.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
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.
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
Functional Verification I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture Notes 21.
White-Box Testing Techniques I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 7.
Axiomatic Verification II Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture Notes 18.
Functional Verification III
Functional Verification IV: Revisiting Loop Invariants
Predicate Transforms II
Functional Verification IV: Revisiting Loop Invariants
Functional Verification III
Lecture 5 Floyd-Hoare Style Verification
Functional Verification I
Programming Languages and Compilers (CS 421)
Exercise Solutions: Functional Verification
Programming Languages 2nd edition Tucker and Noonan
Exercise Solutions: Functional Verification
Axiomatic Verification II
Functional Verification I
White-Box Testing Techniques I
Axiomatic Verification II
Axiomatic Verification I
Predicate Transformers
Axiomatic Semantics Will consider axiomatic semantics (A.S.) of IMP:
Proofs of Correctness: An Introduction to Axiomatic Verification
Functional Verification II
Functional Verification IV: Revisiting Loop Invariants
Axiomatic Verification I
Predicate Transforms I
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Functional Verification III
Predicate Transforms II
Functional Verification III
Functional Verification IV: Revisiting Loop Invariants
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

Exam 2 Help Session Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification

A student writes: I would like to request you to provide some tips on hypothesizing functions for given programs. I refer in particular to Example 2 of Lecture Notes #24 and Question 1 of the self check quiz in lesson plan for Lectures Notes #’s 24 and 25. Although I followed the concept of synthesizing limited invariants, I found it difficult to come up with a function to represent the given program when I attempted these on my own.

General Rule of Thumb for hypothesizing functions of compound programs: –Work top-down, and –Use the Axiom of Replacement Good example (nested if_then’s + sequencing): problem 4 of Problem Set 7 For while loops, see examples 1 and 2 from Lecture Notes #21.

Example 2 (from Lecture Notes #24) Consider the assertion: {n≥0} p := 1 k := 0 while k<>n do p := p2 k := k+1 end_while {p=2 n } What function, f, is computed by the while loop?

Example 2 (cont’d) P = while k<>n do p,k := 2p,k+1 –When will P terminate? –What measure would you use to prove this using the method of Well-Founded Sets? –Use the measure in one or more conditional rules describing the function. –For this case, the initial relationship between k and n determine three different loop “behaviors.” (What are they?)

Example 2 (cont’d) P = while k<>n do p,k := 2p,k+1 k<n  p,k := p2 n−k,n k=n  p,k := p,k := p2 n−k,n k>n  undefined Therefore, [P] = (k≤n  p,k := p2 n−k,n)

Problem 1 from Self-Check Quiz Consider the assertion: y := 0 t := x while t<>k do t := t–1 y := y+1 end_while What function, f, is computed by the while loop?

Problem 1 from Self-Check Quiz (cont'd) P = while t<>k do t,y := t–1,y+1 t>k  t,y := k,y+1(t-k) := k,y+t-k t=k  t,y := t,y := k,y+t-k t<k  undefined Therefore, [P] = (t≥k  t,y := k,y+t-k)

Another student writes: I have some questions about exam 2 for fall 07, problem No 6. And I do not know how to make up counterexample.

6. (4 pts.) It was noted in class that wp(while b do s, Q) is the weakest (while) loop invariant which guarantees termination. Is it also the case that the wp(Repeat s until b) is the weakest (Repeat_until) loop invariant which guarantees termination? Carefully justify your answer. (Hint: recall that in Problem Set 6, you were asked to prove “finalization” from the while loop ROI using the weakest pre-condition as an invariant. Does “finalization” from the Repeat_until ROI hold using the weakest pre-condition as an invariant?) Answer: No. In general, the wp(Repeat s until b, Q) cannot be used as an invariant with the Repeat_until ROI. In particular, (wp(Repeat s until b) Л b ≠> Q in general). (Note that the ROI –- i.e., via the “initialization” antecedent {P} s {I} -- does not require “I” to hold until after s executes.

ROI for while loop and repeat_until loop P  I, { I Л b} S { I }, ( I Л  b)  Q {P} while b do S {Q} {P} S { I }, { I Л  b} S { I }, ( I Л b)  Q {P} repeat S until b {Q} Note that for the repeat_until loop, " I " need not hold UNTIL AFTER S executes.

wp(repeat S until b, Q) = H 1 V H 2 V H 3 V... where: H 1 = wp(S, b Л Q) H 2 = wp(S, ~b Л H 1 ) H 3 = wp(S, ~b Л H 2 ) H k = wp(S, ~b Л H k-1 ) Note that b Л (H 1 V H 2 V H 3 V...)  Q in general.

Finding counter-examples Suppose you wish to prove (A => B) is FALSE. This can be done by finding just one case for which A is true and B is false. This case is referred to as a "counter-example". So, to prove that the hypothesized ROI: A, B, C {P} while b do S {Q} is FALSE, find one case for which A, B, and C are each true, but {P} while b do S {Q} is FALSE. ?

Finding counter-examples (cont'd) How do you identify such a case? By exploiting the fallacy in the (FALSE) ROI. For example, what's the fallacy in the following ROI? P  I, ( I Л  b)  Q {P} while b do S {Q} Answer: The two antecedents do not require that " I " holds after S executes! So, choose P, b, S, Q, and I such that the two antecedents hold, but neither I nor Q will hold after S executes when b becomes false. ?

Finding counter-examples (cont'd) P  I, ( I Л  b)  Q {P} while b do S {Q} For example, consider, for I : x=1 {x = 1 Л y =- 17} while y<0 do y := y+1 x := 2 end_while {x = 1} ?

Problem 2, Exam 2, Summer ‘09 2.Suppose {P} while b do S {Q} for some P, Q, b, and S. Suppose, too, that K = wp(while b do S, Q). Circle “necessarily true” or “not necessarily true” for each of the following assertions. b. {K Л b} S {K}true (See Lecture Notes #20.)

Loop Invariants and wp’s In general, will loops terminate when P  wp ? For while loops, does {wp Л b} S {wp} ? Does (wp Л ¬b)  Q ? √ √ √

Problem 2, Exam 2, Summer ‘09 2.Suppose {P} while b do S {Q} for some P, Q, b, and S. Suppose, too, that K = wp(while b do S, Q). Circle “necessarily true” or “not necessarily true” for each of the following assertions. b. {K Л b} S {K}true (See Lecture Notes #20.) e. {K Л b} repeat S until ¬b {Q} true

¬b¬b S F T S = ¬b¬b S T F {K Л b} {Q} ? {K Л b} {Q} (since (K Л ¬b)  Q) K (since {K Л b} S {K})

Problem 3, Exam 2, Summer ‘09 3. Circle either “true” or “false” for each of the following assertions. k. ({P} S {Q})  ({P} if b then S {(Q  b)}) False The assertion may seem plausible, but consider: {z=1} y:=5 {z=1}  {z=1} if x=0 then y:=5 {(z=1  x=0)} ?

Problem 2, Exam 2, Spring ‘10 2. Circle either “true” or “false” for each of the following assertions. h. [{P Л b} S {Q}]  [{P} while b do S {Q}] False Consider the counterexample: {x=0} while x<5 do x:=x+1 {x=1}

A student writes: We've learned two ways of identifying loop invariant " I ": a heuristic approach and a more systematic approach. My question is: since a systematic approach seems to be more effective, can we always use it to find I for all the problems? Unfortunately, no. The concept of an “invariant” as described in the context of axiomatic verification is directly related to a Rule of Inference (ROI), e.g.: P  I, { I Л b} S { I }, ( I Л  b)  Q {P} while b do S {Q}

The antecedents represent the necessary and sufficient requirements for I (in terms of P, b, S, and Q ) in order to use the ROI to deduce {P} while b do S {Q}. The heuristics considered in class are motivated by these necessary and sufficient requirements, and are therefore dependent on the program’s specification (P and Q), as well as the program itself. In contrast, a (full) invariant as defined in Mill’s Invariant Status Theorem is a logical condition with properties : q(X 0 ), ( q(X)Л p(X) )  qog(X), and ( q(X)Л¬p(X) )  ( X=f(X 0 ) ) where q( X )=( f( X )=f(X 0 ) ).

The function f = [while p do g], which is “characterized by q on termination,” need not be consistent with the pre- and post-condition used to specify the program by a user/designer. Thus, an invariant derived using the Invariant Status Theorem may or may not allow one to prove that a user/designer specified post-condition will hold on termination of a loop. In “reasonable” cases, however, q may be useful, at least as a starting point, in a trial-and-error process. Additional research is needed to fully explore this area.

A student writes: I still have trouble in providing counter examples... Consider the following assertion/ROI: “People who wear red shirts do not smoke.” = Wears red shirts(X) => Does not smoke(X) = Wears red shirts(X) Does not smoke(X)

Is the assertion valid (true)? No. Proof by counterexample: This person satisfies the antecedent, but not the consequent!

More examples Does [(P Л ¬b)  Q]  [{P} while b do S {Q}] ? = [(P Л ¬b)  Q] [{P} while b do S {Q}] Counterexample: {x=0} while y<>5 do x := x+1; y := y+1 {x=0 Л y=5} ?

From Exam 2, Spring ‘10, problem 2 True or False? c. {x=5} while k <= 5 do k := k+3 {k-x≥0} strongly e. {wp(S, Q)}  x>0} x := 17; S {Q}

Confusion re “undefined” and “I” (Identity function) “I am confused about ‘undefined’ and ‘ I ’. Suppose we have the program P like this: if (x>0) x := 9 end_if Is [P] = (x>0 -> x := 9|true -> I ) or [P] = (x>0 -> x := 9|true -> undefined)? 

Exam 2 Help Session Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification