DBC Lecture

Design by Contract lecture notes

These notes assume the students have read Fun with DBC.

Key Points

Design By Contract (DBC) is a technique for designing the classes of a system so that they communicate with one another on the basis of precisely defined benefits and obligations.
DBC means a method trusts its specified interface and doesn't check its preconditions.
DBC means the client code trusts the postcondition is met and doesn't check the postcondition.
DBC replaces the inferior practice of "bulletproofing" to achieve reliable code.
With DBC, run-time (e.g. insufficient memory, non-existent file) errors are outside the contract and must be checked and handled normally.

Diagram of scope of contracts.

Design By Contract implies:

Developers clearly document the contracts in their public interfaces (e.g., with javadocs).
Developers trust that other team members will adhere to the contract and don't write error checking code. (This idea can be quite difficult to sell; many developers have a mistaken, paranoid, "bullet-proofing" mentality.)
The team must decide how to handle broken contracts both during development and during deployment.

The key benefits

DBC is cost-effective because less money goes toward error checking, and better performance due to faster code.
If assertion checking is used, developers find out immediately when they've violated a contract, instead of getting some strange bug symptoms far removed from the cause of the problem.
DBC improves quality by forcing the developer to think very concretely about what the module should do making it more likely that our implementation will be correct.

Comparison: DBC versus Error-checking

	Error Checking	Design By Contract
During Development	The method checks (used) data members and its parameters. In case of an error, the method triggers an exception or returns an error.	The designer writes strong preconditions against data members and input parameters. Code to check the preconditions may be: Omitted entirely; the team believes good programmers and code inspections are sufficient. Written as asserts (e.g. Java 1.4 Assert) Included by the language compiler (e.g. Eiffel) Included by an assertion-checking compiler (e.g., JML) But the programmer never, under any circumstance, writes code to check data members and parameters. NEVER!
During Deployment	The method code runs as written by the programmer. Product quality code must handle any "conceivable" error.	If there is no run-time error checking code, the method runs with defects in its input; results are indeterminate. The method may work correctly or produce a defect or crash the program or ?? If there is run-time error checking code, that code does something appropriate. It must be possible to disable the run-time code; this may be done at build-time or by the user depending on circumstances. The code might: Inform the user. (what should the user be told?) Gracefully crash the program (Blue screen, flashing light, ???) Attempt a fix.
Notes	In both styles, error-checking code must be written for errors caused by the operating environment. A long discussion on "conceivable" is required for all software projects. Meyer defines 3 possible outcomes in an Eiffel rescue clause. Retry Organized panic (cleanup and throw exception) False alarm

Example: Square Root

double sqrt (double x) (design by contract spec)

Description:
Compute the square root of x
Parameters
x is the operand
Preconditions:
x > 0 and !Double.isNaN(x)

double sqrt (double x) (unix error checking spec)

Description:
Compute the square root of x
Parameters
x is the operand
Postconditions:
If x is NaN, NaN is returned.
If x is negative, NaN is returned and errno is set to EDOM.
Errors
EDOM: x is negative
Notes:
An application wishing to check for error situations should set errno to 0 before calling sqrt().

There is a third alternative often practice by inexperienced teams. They don't do error checking, but they don't document their preconditions (usually because they haven't thought about them). Obviously this is the worst of both worlds. In Mr. Dalbey's course your team must decide which strategy to adopt and document method headers accordingly.

Here are some poor Precondition examples, given the method signature:

addClavitz (Clavitz c)

Precondition:  c != null         (not necessary: not worth the trouble)
Precondition:  c is a Clavitz    (redundant, given in method signature)
Precondition:  c is valid        (unclear: doesn't mean anything)
Precondition:  c is initialized  (too vague)
Precondition:  user entered c    (user's can't be part of a contract)
Precondition:  there is sufficient memory to clone c (must be a run-time error check)

Papers and other resources

Last updated on 1/15/04