1. © Paul Ammann, 2008 Design by Contract Paul Ammann CS/SWE 332

2. © Paul Ammann, 2008 2 Abstraction by Specification Abstraction Implementation 1 Implementation N …

3. © Paul Ammann, 2008 3 Specifications n Way to Define Abstractions n Formality –As much as is useful –More than just English –Typically less than a language with a formal semantics –We will use industry standard (ie Javadoc) –Not intended to be a programming language!

4. © Paul Ammann, 2008 4 Parts of a Procedural Specification /** * Returns index of element in sorted list * * @param a[] array to search; must be sorted ascending * @param x int to search for in a * @return if x in a, index of x in a else -1 * @throws NullPointerException if a is null */ public static int sortedSearch (int[]a, int x) Header Precondition Postconditions

5. © Paul Ammann, 2008 5 Another Example /** * Searches for index of x in a. * * @param a[] array to be searched * @param x element to search for * @return index of x if x in a * else -1 if x not in a * @throws NullPointerException if a is null public static int search (int[]a, int x) No Precondition! (Precondition equals “true”) Underdetermined – what happens if x is in a more than once?

6. © Paul Ammann, 2008 6 Yet Another Example /** * sorts list into ascending order. * @param list list to sort * @throws NullPointerException if list is null * or list contains null elements * @throws ClassCastException if elements in list are not mutually comparable public static void sort (List list) // E.g. if list = [3,1,6,1] before the call, then // list = [1,1,3,6] after the call Notice implicit treatment of duplicates Alternate notation: // E.g. if list = [3,1,6,1], then list_post = [1,1,3,6]

7. © Paul Ammann, 2008 7 What does a Contract Look Like? n Consider the triple: {P} S {Q} –P is the precondition (Requires clause) –Q is the postcondition (Effects clause) –S is the program text n The Customer (client) is obligated to establish P. n The Implementor (service) may assume P n The Customer is entitled to Q n The Implementor is obligated to provide Q n That’s it!

8. © Paul Ammann, 2008 8 What happens when a Contract Breaks? n If everyone does their job, there is no problem! n If the precondition is not satisfied, the Customer is wrong! (The client has a bug). n If the precondition is satisfied, but the postcondition is not, then the Service is wrong (The server has a bug). n The Client can’t do the Server’s job! n The Server can’t do the Client’s job!

9. © Paul Ammann, 2008 9 n Suppose you are fixing a fault in a program. –What justification is there for a proposed change? n Example Context: code considered correct..... code identifed as wrong vs. proposed correct code..... more code considered correct Application of Contract Model to Debugging {P} {Q}

10. © Paul Ammann, 2008 10 /** * returns number of zeroes in arr. * @param arr[] array to count zeroes in * @throws NullPointerException if arr is null */ public static int numZero (int[] arr) { int count = 0; for (int i=1; i < arr.length; i++) { if (arr[i] == 0) {count++} }return count;} Example {inv: count has # zeros in arr[0..-1]} {inv: count has # zeros in arr[0..i-1]}

11. © Paul Ammann, 2008 11 What does the Client like? n Since preconditions are Client obligations, the Client would prefer not to have any! n From the Client’s perspective, “true” is the best precondition. In general, weaker preconditions are better. n The Client is happy to have any postcondition that is strong enough to meet the Client’s needs.

12. © Paul Ammann, 2008 12 What does the Server like? n Since preconditions are Server benefits, the Server would prefer to have lots of them! n From the Server’s perspective, “false” is the best precondition. In general, stronger preconditions mean an easier job with the implementation. n The Server prefers weak postconditions. Each additional constraint in a postcondition is an additional obligation on the Server.

13. © Paul Ammann, 2008 13 Problems with Eliminating Preconditions n Forcing the Server to handle “weird” cases can lead to inefficient, bulky (read “error prone”) code. n For “local” use, therefore, preconditions can be extremely powerful (and appropriate). n Example: Consider the “partition” method in a quicksort routine. It would be weird to handle the case where the array indices were out of bounds.

14. © Paul Ammann, 2008 14 More Problems with Eliminating Preconditions n What if the Implementer can’t provide a good “default” (ie Defensive Programming)? n Consider this (undocumented!) code: public static double sqrt (double x) { if (x < 0) { handle problem somehow return some value (what?) } else { proceed with normal square root computation return y such that y*y is approximately x }

15. © Paul Ammann, 2008 15 Dissecting the Square Root Example n What could possibly be a correct “default”? –Printing an error message? Not a comforting thought to certain end users (ie pilots). n What could possibly be a reasonable return value? n The Lesson: The Server is not in a position to define behavior. That’s the Client’s job. (through the contract mechanism).