© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice Hall). Included here by permission of ISE, for the benefit of IDC students. Other uses, duplication or distribution require permission from ISE. For more material see

© Bertrand Meyer and Yishai Feldman Correctness Formulas The meaning of the correctness formula {P} A {Q} is that any execution of the program A, starting in a state where P holds, will terminate in a state where Q holds. Example: {x  9} x := x + 5 {x  13}

© Bertrand Meyer and Yishai Feldman The Perfect Jobs u { False } A { … } u { … } A { True } Definition: A predicate P is stronger than a predicate Q if whenever P is true, Q is also true. That is, if P  Q holds.

© Bertrand Meyer and Yishai Feldman Stack with Assertions (1) class STACK1 [G] feature -- Access count: INTEGER -- Number of stack elements item: G is -- Top element require not empty do  end

© Bertrand Meyer and Yishai Feldman Stack with Assertions (2) feature -- Status report empty: BOOLEAN is -- Is stack empty? do  end full: BOOLEAN is -- Is stack representation full? do  end

© Bertrand Meyer and Yishai Feldman Stack with Assertions (3) feature -- Element change put (x: G) is -- Add x on top. require not full do  ensure not empty item = x count = old count + 1 end

© Bertrand Meyer and Yishai Feldman Stack with Assertions (4) remove is -- Remove top element. require not empty do  ensure not full count = old count – 1 end

© Bertrand Meyer and Yishai Feldman The Contract The clauses "require pre" and "ensure post" in a routine r imply the following contract: ¬ The caller may only call r when pre is satisfied. ­ If r is called with pre satisfied, it must return in a state that satisfies post.

© Bertrand Meyer and Yishai Feldman Benefits and Obligations

© Bertrand Meyer and Yishai Feldman Non-Redundancy Principle Under no circumstances shall the body of a routine ever test for the routine's precondition.

© Bertrand Meyer and Yishai Feldman Input Validation require input > 0 External ObjectsInput and validation modulesProcessing modules

© Bertrand Meyer and Yishai Feldman Assertion Violation Rule  A run-time assertion violation is the manifestation of a bug in the software.  A precondition violation is the manifestation of a bug in the client.  A postcondition violation is the manifestation of a bug in the supplier.

© Bertrand Meyer and Yishai Feldman Stack Implemented by Array

© Bertrand Meyer and Yishai Feldman Stack Implementation (1) indexing description: "Stacks: Dispenser structures with a Last-In, First-Out access policy, and a fixed maximum capacity" class STACK2 [G] creation make feature -- Initialization

© Bertrand Meyer and Yishai Feldman Stack Implementation (2) make (n: INTEGER) is -- Allocate stack for a maximum of n elements require positive_capacity: n >= 0 do capacity := n !! representation. make (1, capacity) ensure capacity_set: capacity = n array_allocated: representation /= Void stack_empty: empty end

© Bertrand Meyer and Yishai Feldman Stack Implementation (3) feature -- Access capacity: INTEGER -- Maximum number of stack elements count: INTEGER -- Number of stack elements item: G is -- Top element require not_empty: not empty -- i.e. count > 0 do Result := count end

© Bertrand Meyer and Yishai Feldman Stack Implementation (4) feature -- Status report empty: BOOLEAN is -- Is stack empty? do Result := (count = 0) ensure empty_definition: Result = (count = 0) end

© Bertrand Meyer and Yishai Feldman Stack Implementation (5) full: BOOLEAN is -- Is stack full? do Result := (count = capacity) ensure full_definition: Result = (count = capacity) end

© Bertrand Meyer and Yishai Feldman Stack Implementation (6) feature -- Element change put (x: G) is -- Add x on top require not_full: not full -- i.e. count < capacity in this representation do count := count + 1 representation. put (count, x) ensure not_empty: not empty added_to_top: item = x one_more_item: count = old count + 1 in_top_array_entry: count = x end

© Bertrand Meyer and Yishai Feldman Stack Implementation (7) remove is -- Remove top element require not_empty: not empty -- i.e. count > 0 do count := count – 1 ensure not_full: not full one_fewer: count = old count – 1 end

© Bertrand Meyer and Yishai Feldman Stack Implementation (8) feature {NONE} -- Implementation representation: ARRAY [G] -- The array used to hold the stack elements invariant count_non_negative: 0 <= count count_bounded: count <= capacity consistent_with_array_size: capacity = representation. capacity empty_if_no_elements: empty = (count = 0) item_at_top: (count > 0) implies (representation. item (count) = item) end -- class STACK2

© Bertrand Meyer and Yishai Feldman Tolerant Routines remove is -- Remove top element do if empty then print ("Error: attempt to pop an empty stack") else count := count – 1 end

© Bertrand Meyer and Yishai Feldman Reasonable Precondition Principle Every routine precondition must satisfy the following requirements: The precondition appears in the official documentation distributed to authors of client modules. It is possible to justify the need for the precondition in terms of the specification only.

© Bertrand Meyer and Yishai Feldman Precondition Availability Rule Every feature appearing in the precondition of a routine must be available to every client to which the routine is available. class SNEAKY feature tricky is require accredited do  end feature {NONE} accredited: BOOLEAN is do  end end

© Bertrand Meyer and Yishai Feldman Invariant Rule An assertion I is a correct class invariant for a class C if and only if it meets the following two conditions: E1 Every creation procedure of C, when applied to arguments satisfying its precondition in a state where the attributes have their default values, yields a state satisfying I. E2 Every exported routine of the class, when applied to arguments and a state satisfying both I and the routine’s precondition, yields a state satisfying I.

© Bertrand Meyer and Yishai Feldman Class Correctness A class C is correct with respect to its assertions if and only if: C1 For any valid set of arguments x p to a creation procedure p: {Default C and pre p (x p )} Body p {post p (x p ) and INV} C2 For every exported routine r and any set of valid arguments x r : {pre r (x r ) and INV} Body r {post r (x r ) and INV}

© Bertrand Meyer and Yishai Feldman Reminder: ADT Specification of Stacks TYPES STACK [G] FUNCTIONS put: STACK [G]  G  STACK [G] remove: STACK [G]  STACK [G] item: STACK [G]  G empty: STACK [G]  BOOLEAN new: STACK [G] AXIOMS For any x: G, s: STACK [G] A1 item (put (s, x)) = x A2 remove (put (s, x)) = s A3 empty (new) A4 not empty (put (s, x)) PRECONDITIONS remove (s: STACK [G]) require not empty (s) item (s: STACK [G]) require not empty (s)

© Bertrand Meyer and Yishai Feldman The Abstraction Function

© Bertrand Meyer and Yishai Feldman Correctness of the Implementation CONC_2 ABST_1ABST_2 CONC_1 cf af aa Concrete objects (instances of the class C) Abstract objects (instances of the ADT A) af a = a cf

© Bertrand Meyer and Yishai Feldman Assertion Instructions x := a ^2 + b^2  Other instructions  check x >= 0 -- Because x was computed above as a sum of squares. end y := sqrt (x)

© Bertrand Meyer and Yishai Feldman Buggy Binary Search (1) from i := 1; j := n until i = j loop m := (i + j) // 2 if m <= x then i := m else j := m end Result := (x = j)

© Bertrand Meyer and Yishai Feldman Buggy Binary Search (2) from i := 1; j := n; found := false until i = j or found loop m := (i + j) // 2 if m < x then i := m + 1 elseif m = x then found := true else j := m – 1 end Result := found

© Bertrand Meyer and Yishai Feldman Buggy Binary Search (3) from i := 0; j := n until i = j loop m := (i + j + 1) // 2 if m <= x then i := m + 1 else j := m end if i >= 1 and i <= n then Result := (x = i) else Result := false end

© Bertrand Meyer and Yishai Feldman Correct Binary Search from i := 1; j := n invariant -- x in t [1..n] implies i <= x <= j 1 <= i <= j <= n variant j – i until i = j loop m := (i + j) // 2 check i <= m < j end if m < x then i := m + 1 else j := m end Result := (x = i)

© Bertrand Meyer and Yishai Feldman Breaking the Loop: Generating the Verification Conditions Start Init Exit? Body End YES NO “Precondition” Invariant “Postcondition” (1) (2) (3)

© Bertrand Meyer and Yishai Feldman Proving Loop Correctness Step 1: The invariant follows from the loop precondition and the initialization. {Loop-precond} Init {Invariant} Step 2: The invariant is maintained by one pass through the loop. {Invariant   Exit} Body {Invariant} Step 3: The loop postcondition follows from the invariant. Invariant  Exit  Loop-postcond

© Bertrand Meyer and Yishai Feldman Proving Loop Termination Step 4: The variant is always non-negative (should follow from the invariant). Invariant  Variant  0 Step 5: The variant decreases by at least 1 in every pass through the loop. Invariant  Variant < Previous-Variant

© Bertrand Meyer and Yishai Feldman Proving Loop Correctness with Verification Conditions u Verification conditions refer to loop- free code. u The proofs of Steps 1–5 are not inductive! u If you feel the need to refer to what goes on throughout the loop computation, you are missing an invariant!

© Bertrand Meyer and Yishai Feldman Loop Computations