Design by Contract
From Software testing and development
Portions of this from “Object-Oriented Software Construction: 2nd Ed.” by B. Meyer. Within a Trust Region the correctness of the software itself can be verified using DbC.
The basic and remarkably simple idea of DbC is that each routine is a contract. The programmer of the routine contracts to meet the postcondition clause, if and only if, the client has met the preconditions.
Design by Contract.
Each function must contract to fulfilled it's postcondition if and only if the precondition was true when it was invoked.
Contents |
[edit] Preconditions and Postconditions
Preconditions are assertions placed at the start of a function. They are a boolean expression that asserts what the state of the system must be prior to executing this function.
Postconditions are assertions placed after the function (just before the return) and are a boolean expression that asserts what the state of the system will be after the function has executed, PROVIDED THAT THE PRECONDITION WAS TRUE.
[edit] REQUIRE and ENSURE
The following is from the EventHelix framework site. [4]
Create a REQUIRE macro to assert preconditions and a matching ENSURE macro to assert postconditions. As recommended by Meyer [2], if you must switch any asserts off, start with postconditions.
[edit] Strong and Weak Conditions.
A Stronger condition is one that is more difficult to satisfy. The strongest being
assert(false);
since it is never satisfied.
The weakest condition is
assert( true);
since it is always satisfied no matter what the software did!
Software that is easy to use has weak preconditions and strong postconditions.
Software that is easy to write has strong preconditions and weak postconditions.
[edit] Who to blame...
- A run-time assertion violation is the manifestation of a bug in the software.
- A precondition violation is the manifestation of a bug in the client.
- A postcondition violation is the manifestation of a bug in the supplier.
- An invariant failure means the object itself is Barking Mad.
Previous: Reliable Collaborations and Trust Regions Next: Asserts and Architecture
