Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 1 COSC3311 – Software Design Loop invariant/variant

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 2 Review: Concept of State Each state is a combination of run-time instance values for all the class attributes Expressed as a tuple of size corresponding to the number of class attributes a, b: BOOLEAN ,,,

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 3 Review: Correctness in software Basic notation: (P, Q: assertions, i.e. properties of the state of the computation. A: instructions). {P} A {Q}  “Hoare triple”  What this means (total correctness): oAny execution of A started in a state satisfying P will terminate in a state satisfying Q.

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 4 Review: The correctness of a class  For every creation procedure cp: {pre cp } do cp {post cp and INV}  For every exported routine r: {INV and pre r } do r {post r and INV}  The worst possible erroneous run-time situation in object-oriented software development: oProducing an object that does not satisfy the invariant of its own class. a.f (…) a.g (…) a.f (…) create a.make (…) S1 S2 S3 S4

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 5 Loop trouble  Loops are needed, powerful  But very hard to get right: o“off-by-one” oInfinite loops oImproper handling of borderline cases  For example: binary search feature

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 6 OOSC2 page 381

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 7 The answer: controlled loops/assertions  Use of loop variants and invariants.  A loop is a way to compute a certain result by successive approximations.  (e.g. computing the maximum value of an array of integers)

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 8 Computing the max of an array  Approach by successive slices: max_of_array (t: ARRAY [INTEGER]): INTEGER -- Maximum value of array t local i: INTEGER do from i := t.lower Result := lower until i = t.upper loop i := i + 1 Result := Result.max i) end

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 9 Loop variants and invariants  Syntax: from init invariant inv-- Correctness property until exit loop body variant var-- Ensure loop termination. end

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 10 Maximum of an array (cont’d) max_of_array (t: ARRAY [INTEGER]): INTEGER -- Maximum value of array t local i: INTEGER do from i := t.lower Result := t.lower invariant -- Result is the max of the elements of t at indices -- t.lower to i until i = t.upper loop i := i + 1 Result := Result.max i) variant t.upper – i end

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 11 Maximum of an array (cont’d) max_of_array (t: ARRAY [INTEGER]): INTEGER -- Maximum value of array t local i: INTEGER do from i := t.lower Result := t.lower invariant until i = t.upper loop i := i + 1 Result := Result.max i) variant t.upper – i end

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 12 Loop Invariant Invariant: t.lower <= i and i <= t.upper and t.subarray (t.lower, i).for_all (agent max(Result, ?)) max (r, g: INTEGER) : BOOLEAN do Result := r >= g end

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 13 Contract View class interface ARRAY_MAX feature max (r, g: INTEGER): BOOLEAN max_of_array (t: ARRAY [INTEGER]): INTEGER -- maxium value of array `t' require P: t /= Void ensure Q: t.for_all (agent max (Result, ?)) end

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 14 Terminology routine require P do from initial invariant I until B do loop-body variant V end ensure Q end

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 15 Successive approximations

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 16 Verifying a routine with a loop  Partial correctness oShow that invariant I is true before execution of the loop begins, i.e. show: {P} initial {I} oShow that: {I and not B} loop-body {I} oShow that: (I and B) implies (Q and V = 0)  Termination oShow that: (I and not B) implies V > 0 oShow that: {I and not B} loop-body {V < old V}

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 17 Infinite Loop

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 18 What’s wrong with `break’ | | Subject: AT& T Bug | | Date: Fri Jan 19 12: 18: | | | This is the bug that caused the AT& T breakdown the other day: | | In the switching software (written in C), | | there was a long do... while construct, | | which contained a switch statement, | | which contained an if clause, | | which contained a break, | | which was intended for the if clause, | | but instead broke from the switch.  A missing “break” statement brought down the entire long- distance telephone network in the North Eastern US, resulting in millions of dollars of damage!

Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 19 Why not use Breaks and Go-Tos  Thirty five years ago, Edsger Dijkstra, followed by others, made a powerful case against using control structures other than the one-entry, one-exit blocks that came to be known as "the control structures of structured programming". They are, with a few complements, the control structures of Eiffel: sequence (implicit most of the time since you may omit the semicolon), if-then-else, inspect, loop, routine.  They are all one-entry, one-exit, meaning you can read the code sequentially and don't have to turn yourself into a computer and apply operational reasoning of the style "if when executing this instruction I'm coming from here it will satisfy this property, but if I am coming from there it will satisfy that other property, so in both cases... it will be true that... maybe... wait a minute... etc.  Some people view "break" and "continue" as milder forms of the goto that do not raise the same problems. But in fact these forms are just as bad. Note in particular that what makes it possible really to understand a loop is the notion of loop *invariant*: a property that is ensured by the initialization, and maintained by every iteration. The invariant is like an approximation of the loop's goal (e.g. if we want to compute the maximum of a structure -- the final goal -- the invariant states that Result is the maximum *of the elements seen so far*). Combined with the loop exit condition (in the example, "we've now seen all elements") it allows the program reader to check, through a simple inspection of the loop text, that the loop is doing its job. The loop *variant* plays a complementary role by telling us which decreasing quantity guarantees that the loop will terminate.  These notions are simple to understand and use thanks to the one-entry, one-exit form of loops and other control structures. Introduce `break', `continue' and other goto instructions (in sheep's clothing or not) and they disappear, or at least are replaced with much more complicated rules.  The key point is to be able to reason about a program statically, i.e. by associating properties with its text as given, rather than operationally, i.e. by trying to mimic its execution within your head. Computers are there to execute programs; humans can't really do it effectively for any non-trivial examples. The one-entry, one-exit structure helps us do something at which we are much better: static reasoning based on the simple rules of logic.  In practice it is not surprising that if you have been used to goto-prone languages you will find it a bit hard at first to stick to the one-entry, one-exit discipline. I am sure that if you try earnestly to overcome what initially seems like a hurdle you will very quickly find that your programming style improves, that the control structure of your program becomes simpler, and that your programs become more readable and maintainable. See