1 / 12

Programming by Contract

Programming by Contract. Preconditions Postconditions (See Bertrand Meyer's classic book: "Object-oriented Software Construction", Prentice-Hall 1988/1997). [original slides by M.Utting]. Motivation. Want precise specifications of classes. Class will be clearly documented.

leiko
Download Presentation

Programming 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. Programming by Contract Preconditions Postconditions (See Bertrand Meyer's classic book: "Object-oriented Software Construction", Prentice-Hall 1988/1997). [original slides by M.Utting]

  2. Motivation • Want precise specifications of classes. • Class will be clearly documented. • Makes implementers job easier. • Callers (clients) know precisely how/when to call each method and what it will do. • Computer can check correctness of class and its clients. Automatic bug catching!

  3. Contracts • An agreement between two parties: • The provider provides a service/product. • The client uses that service/product. • (and usually pays for it!). • Each side has obligations (and benefits): • Precondition = client's obligations. • Postcondition = provider's obligations.

  4. Alternative definitions • A precondition describes the properties that must hold whenever a procedure is called. • A postcondition describes the properties that the procedure guarantees when it returns. Contract: If you promise to call me with Pre satisfied, then I promise to return with Post satisfied.

  5. Sort example • static void Arrays.sort(int[] intArray) • Precondition: intArray is a properly initialized array of ints • Postcondition: the array will be sorted in ascending order in-place (i.e. the array will be modified!)

  6. More Example Contracts (?) • Frame: void paint(Graphics g); • Stack: public Object pop(); • Stack: public Object push(Object val);

  7. Obligations and Benefits Client: Obligations Only call Pop on non-empty stack. Benefits Value returned was on top of the stack. (will be removed) Stack: No need to handle cases where stack is empty. Must return top of stack and shrink stack

  8. What if precondition is false? • In a correct system, procedures are only called when their preconditions are true. • If a procedure is called when its precondition is false, it may do anything! (The contract is broken!) • While debugging, we can use assertions to check some preconditions.

  9. Checking Preconditions public Object pop() { // check precondition. assert(size() > 0); // pop top of stack . . . } • This catches client errors.

  10. Checking Postconditions public Object pop() { // pop top of stack int oldSize = size(); . . . // check postconditions (at end) assert( size() == oldSize-1 ); } • This catches errors within Pop.

  11. Making Contracts Better • To improve (refine) a contract, we can: • Weaken the precondition (require less from the client), or • Strengthen the postcondition (do more for the client). • Note: we take the clients viewpoint! • If contract A is refined by contract B, clients of A will be happy to use implementations of B.

  12. Summary • Use English pre/postconditions to document your procedures. • Precondition = client's responsibility • Postcondition = procedure's responsibility • Some pre/postconditions can easily be written as Java predicates: • (in Java 1.4 and later) use assert( ) to check them. • Especially useful for preconditions (to catch errors in client code).

More Related