1 / 22

Procedural Abstraction and Design by Contract

Procedural Abstraction and Design by Contract. Paul Ammann Information & Software Engineering SWE 619 Software Construction cs.gmu.edu/~pammann/. Benefits of Abstraction. Locality

vea
Download Presentation

Procedural Abstraction and Design by Contract

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Procedural Abstraction and Design by Contract Paul Ammann Information & Software Engineering SWE 619 Software Construction cs.gmu.edu/~pammann/

  2. Benefits of Abstraction • Locality • The implementation of an abstraction can be read or written without needing to examine the implementations of any other abstractions • Modifiability • An abstraction can be reimplemented without requiring changes to any abstractions that use it

  3. Abstraction by Specification Abstraction … Implementation N Implementation 1

  4. Specifications • Way to Define Abstractions • Formality • As much as is useful • More than just English • Typically less than a language with a formal semantics • We will be close to industry standard (ie Javadoc) • Not intended to be a programming language!

  5. Parts of a Procedural Specification Precondition: Anything missing? What happens in other languages? (eg C++) Header public static int sortedSearch (int[]a, int x) // Requires: a is sorted in ascending order // Effects: if x is in a returns an index where // x is stored; otherwise, returns -1 Postcondition (examples?)

  6. Another Example No Precondition! (Precondition equals “true”) public static int search (int[]a, int x) // Effects: if x is in a returns an index where // x is stored; otherwise, returns -1 Underdetermined – what happens if x is in a more than once?

  7. Yet Another Example Still no precondition (what if a is null?) Notice the “Modifies” clause Notice implicit treatment of duplicates public static void sort (int[] a) // Modifies: a // Effects: rearranges the elements of a into // ascending order // E.g. if a = [3,1,6,1] before the call, then // a = [1,1,3,6] after the call Alternate notation: // E.g. if a = [3,1,6,1], then a_post = [1,1,3,6]

  8. Yet Another Example Procedures may modify variables that are not explicit arguments public static void copyLine() // Requires: System.in contains a line of text // Modifies: System.in and System.out // Effects: Reads a line of text from System.in, // advances the cursor in System.in to the end of // the line, and writes the line on System.out

  9. Specifications and Implementations • Minimality • minimal means fewer constraints on behavior (what does this say about the postcondition?) • Underdetermined behavior • More than one possible result per input allowed • Deterministic implementation • Only one result per input produced • Generality • More general if specification can handle a large class of inputs. (What does this say about the precondition?)

  10. Total vs. Partial Procedures • A procedure is total if its behavior is specified for all possible inputs. • A partial procedure always has a precondition. • Partial procedures are less safe than total procedures. • Exception handling can be used to eliminate preconditions (more in next lecture…).

  11. Bertrand Meyer’s View: Design by Contract • A programmer’s job is to produce solutions, not programs. • Software should be reliable. • Type safety, garbage collection, etc… • These are good • But they are not enough • Correctness is a relative notion • A program is correct relative to a specification

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

  13. What happens when a Contract Breaks? • If everyone does their job, there is no problem! • If the precondition is not satisfied, the Customer is wrong! (The client has a bug). • If the precondition is satisfied, but the postcondition is not, then the Service is wrong (The service has a bug). • The Client can’t do the Service’s job! • The Service can’t do the Client’s job!

  14. Application of Contract Model to Debugging • Suppose you are fixing a fault in a program. • What justification is there for a proposed change? • Example Context: code considered correct ..... code identifed as wrong vs. proposed correct code ..... more code considered correct {P} {Q}

  15. Example //Effects: if arr is null throw NPE else return the number of occurrences of 0 in arr public static in numZero (int[] arr) { int count = 0; for (int i=1; i < arr.length; i++) { if (arr[i] == 0) {count++} } return count; } {inv: count has # zeros in arr[0..-1]} Note the bug! {inv: count has # zeros in arr[0..i-1]}

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

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

  18. Who should get preference? • In Business, the Customer is thought to be “always right” This is a good model for software as well: • Tradeoffs should generally be made in favor of the client. That is • minimize preconditions • provide usefully strong postconditions • But there are limits…

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

  20. More Problems with Eliminating Preconditions • What if the Implementer can’t provide a good “default” (ie Defensive Programming)? • Consider the following (horrible) code: public 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 } }

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

  22. Meyer’s Perspective on Defensive Programming • Defensive programming: • leads to duplicate checks on preconditions and therefore code bloat. • leads to implementers checking preconditions when they have no idea what to do if the precondition is false. • leads to confusion over responsibility for ensuring certain constraints. • So, Meyer’s advice is, “Don’t do it!” • Your mileage may vary • Think about this in the context of preconditions and exception handling. • What are the implications for security?

More Related