Applying “Design by Contract”

Motivation(s)

Despite the quick adoption of OOD, there has been few contributions toward a methodology of reliable OO software construction. Defensive programming is the most emphasized technique to improve software reliability at the cost of redundant checking and unnecessary complexity.

Proposed Solution(s)

The author proposes a methodological way to use assertions, subcontracts, and exception handling.

Evaluation(s)

The technique was applied to several generic scenarios and were soundly analyzed. An outstanding problem is the use of design by contract in parallel computation.

Future Direction(s)

  • In parallel architectures, would design by contract be reduced to event logging?

  • [BHTY10] proposed a distributed version of design by contract, but wouldn’t a DbC version at the service level be satisfactory?

Question(s)

  • Why is there no mention of Parnas’ works at all?

  • It seems that the rescue clause is very similar to try-catch-finally construct?

  • How come invariants can only be applied to classes? Shouldn’t it be applicable to any computation that carries state?

Analysis

Effective use of assertions, subcontracts, and exception handling on top of the system decomposition is necessary for maintainable and reliable software.

Notes

Assertions

  • A mechanism to express the relationship between the client (caller) and the supplier (callee).

  • Describes expected (not special) cases that needs special treatment (see Figure 3).

  • Types

    • Precondition/Require

      1. Expresses requirements that any call must satisfy if it is to be correct.

      2. Violation indicates a bug in the client (caller) i.e. the caller did not observe the conditions imposed on correct calls.

    • Postcondition/Ensure

      1. Expresses properties that are ensured when the call finishes execution.

      2. Violation indicates a bug in the supplier (callee) i.e. the callee failed to deliver on its promises.

    • Invariants

      1. Only feasible with OO design.

      2. A property that applies to all instances of the class.

      3. Must be satisfied after the creation of every instance of the class.

      4. Must be preserved by every routine available to clients.

Software Contracts

  • Opposite Idea of Defensive Programming

    • A function either asserts a precondition or checks it manually in the routine (e.g. if-statement), but never both.

  • Who should perform the checks?

    • Optimize for overall architecture simplicity.

    • Making the client handle the checks can be quite successful.

      1. Clients do not have to necessarily perform any checks if they can guarantee the preconditions.

      2. Each client has a more global view than the routine in terms of how to handle violations of preconditions.

    • Should many clients have the same special treatment for violating the preconditions, the callee’s contract should be relaxed to include the special treatment as part of the specification.

Inheritance

  • Redeclaration Types

    1. Redefinition assumes the abstract feature already had an implementation and changes the specification and/or implementation to handle specific cases.

    2. Effecting applies to features for which the abstract feature had no implementation and only specification.

  • Redeclaration is not a way to turn a routine into something completely different i.e. set of (inherited) assertions cannot contradict.

  • Subcontracting: redeclaration -> polymorphism and dynamic binding.

    • The new set of preconditions must be guaranteed to be weaker than or equal to the original set.

    • The new set of postconditions must be guaranteed to be stronger than or equal to the original set.

    • The invariant of a class is always stronger than or equal to the invariants of each of its parents.

Dealing with Abnormal Situations

  • Failure is the basic concept, and exception is a derived notion.

  • An exception occurs when a certain strategy for fulfilling a routine’s contract has not succeeded.

  • Possible Responses

    1. Resumption reverts to the previous consistent state and tries again using a different strategy.

    2. Organized panic reverts to the previous consistent state and report failure to the caller.

    3. False alarm (applicable to OS and hardware signals) performs some corrective actions before continuing execution.

  • Do versus Rescue Execution

    • A module’s implementation assumes that the preconditions are satisfied, preserves the class invariant, and ensures that the postconditions are satisfied.

    • Exception handling mechanism has no preconditions and needs to restore the invariants, but it does not have to worry about postconditions.

References

BHTY10

Laura Bocchi, Kohei Honda, Emilio Tuosto, and Nobuko Yoshida. A theory of design-by-contract for distributed multiparty interactions. CONCUR 2010-Concurrency Theory, pages 162–176, 2010.

Mey92

Bertrand Meyer. Applying “design by contract”. Computer, 25(10):40–51, 1992.