Chapter 5 : Programming By Contract

1
Chapter 5 Programming By Contract
2
Objectives

• After studying this chapter you should understand
  the following
• programming by contract, defensive programming,
  and difference between the two
• consequences of a clients lack of adherence to a
  contract
• purpose and use of the assert statement.
• Also, you should be able to
• express the responsibilities of client and server
  as a contract
• use assert statements to verify a clients
  preconditions
• use contract to reason about a programs
  behavior.

3
Method specifications

• Specification of Explorers constructor allows
  for any int value for strength and tolerance

public Explorer (String name, Room location,
int strength, int tolerance)

• Client could give negative values.

4
Documenting requirements

• /
• Create a new Explorer with the specified name,
• initial location, strength, and tolerance.
• _at_require strength gt 0
• tolerance gt 0
• /
• public Explorer (String name, Room location,
  int strength, int tolerance)

5
Programming by contract

• Programming style in which invocation of a method
  is viewed as a contract between client and
  server, with each having explicitly stated
  responsibilities.

6
Programming by contract

• Preconditions requirements on client of a
  method.
• Labeled require
• Postconditions requirements on server of a
  method.
• labeled ensure
• Preconditions and postconditions are part of the
  contract.

7
Programming by contract

• For method invocation to be correct
• client must make sure that preconditions are
  satisfied at time of call.
• If preconditions are satisfied, server guarantees
  that postconditions will be satisfied when method
  completes otherwise server promises nothing at
  all.

8
Programming by contract

• Consequence test for every possible error
  condition only once.
• Program efficiency.
• Reduction of implementation complexity.

9
Programming by contract

• Complete specification of Explorers constructor

/ Create a new Explorer with the specified
name, initial location, strength, and
tolerance. _at_require strength gt 0
tolerance gt 0 _at_ensure this.name().equals
(name) this.location() location
this.strength() strength this.tolerance()
tolerance / public Explorer (String name,
Room location, int strength, int tolerance)
10
Implicit preconditions and postconditions

• Implicit Preconditions
• Object arguments must be not null.
• Type arguments imply a range of legal values.
• Implicit postconditions
• Object result will be not null.
• Type result implies a range of value of possible
  result.

11
Verifying preconditions

• Javas assert statement can be used in
  verifying preconditions.

assert booleanExpression

• The boolean expression is evaluated
• if true, statement has no effect.
• If false, statement raises an error condition
  stopping execution of program displaying cause of
  error.

12
Verifying preconditions

• public Explorer (String name, Room
  location, int strength, int tolerance)
• assert strength gt 0
• assert tolerance gt 0
• this.name name
• this.location location
• this.strength strength
• this.tolerance tolerance

13
Verifying preconditions (v.2)

• public Explorer (String name, Room
  location, int strength, int tolerance)
• assert strength gt 0 "precondition strength
  (" strength ") gt 0"
• assert tolerance gt 0 "precondition tolerance
  (" tolerance ") gt
  0"
• this.name name
• this.location location
• this.strength strength
• this.tolerance tolerance

14
Pile specification

• Pile instance models a pile of sticks from which
  players in turn removed 1, 2, or 3 sticks.
• Command remove

• public void remove (int number)
• Reduce the number of sticks by the specified
  amount.

15
Pile specification

• Questions
• what if number is negative? Is legal? If so, what
  does this mean?
• what if number is greater than the number of
  sticks remaining the pile?
• what if number is not 1, 2, or 3?

16
Pile specification

• Not meaningful for a client to remove a negative
  number of sticks.
• Removing more sticks than there are in pile also
  seems likely to be a client error.
• Number of sticks than can legally be removed by a
  player is determined by rules of the game.
• Not Piles responsibility.

17
Pile complete specifications

• public void remove (int number)
• Reduce the number of sticks by the specified
  amount.
• require number gt 0 number lt this.sticks()
• ensure this.sticks() old.sticks() - number

18
Preconditions summary

• Preconditions must be satisfied by client when
  invoking method.
• Occasionally, preconditions constrain order in
  which methods can be invoked or require that an
  object be in a certain state before invocation.
• It might be necessary that a door be unlocked
  before it can be opened, or that an automobile be
  started before it can be moved.
• Most often preconditions constrain values that
  client can provide as arguments when invoking
  method.
• Remember if an argument is not constrained by a
  precondition, method must be prepared to accept
  any value of the specified type.

19
Query postconditions summary

• Query postconditions say something about value
  returned.

20
Command postconditions summary

• Commands result in a change of state.
• Command postconditions describe new state of the
  object after execution of command.
• New state is often compared to the previous
  state, the state of the object before command was
  invoked.
• We use old to refer to state before call

21
Constructor postconditions summary

• Constructor postconditions describe the initial
  state of the newly created object.

22
Preconditions, postconditions part of the
specification

• They should never mention private implementation
  components.

public void reset () Reset the count to
0. ensure count 0 This is not correct!
count is private.
23
Preconditions, postconditions part of the
specification

• The method currentCount is part of the public
  specification of the class.

public void reset () Reset the count to
0. ensure this.currentCount() 0
24
Summary

• Introduced a programming style called programming
  by contract.
• Basic idea is to make explicit responsibilities
  of client and server in a method invocation.
• Invocation of a server method by client is viewed
  as a contract between the client and the server.
• Server promises to perform action specified by
  method and to ensure that methods postconditions
  are satisfied, but only if
• Client meets the preconditions.

25
Summary

• Preconditions are clients responsibility
• Postconditions are the servers.
• If the client fails to meet the preconditions,
  the contract is void the server is not obligated
  to behave in any specific way.

26
Summary

• Preconditions can be verified using Javas assert
  statement.
• If the boolean expression in the assert statement
  is true, the statement has no effect.
• If it is false, an error exception occurs and the
  program terminates.

27
Summary

• Preconditions constrain values a client can
  provide as argument.
• Postconditions for a query generally say
  something about the value returned.
• Postconditions for a command describe state of
  the object after command is completed in terms of
  state before the command was begun.