Eiffel Language and Design by Contract

• Contract – An agreement between the client and the supplier

• Characteristics– Expects some benefits and is prepared to incur some obligations– Documented in a contract document

• Eiffel – A language that implements the Design by Contract principles by

Bertrand Meyer – Applying Design by Contract, B. Meyer, IEEE Computer, pp. 40-51,

October 1992.

Design by Contract and Module Design

• Design by contract promotes using pre and post-conditions (such as assertions) in a module design

• Eiffel is an object oriented programming language that supports design by contract– In Eiffel the pre and post-conditions are written using require and ensure

constructs, respectively

Pre and post conditionof a procedure

between the caller and the callee

Pre and post conditionof a procedure

between the caller and the callee

Obligations and benefitsof a contract

between the clientand the supplier

Obligations and benefitsof a contract

between the clientand the supplier

Eiffel Example

-- A typical Eiffel procedure:

procedure_name(argument declarations) is -- Header commentrequire Preconditiondo Procedure bodyensure PostconditionEnd

-- A typical Eiffel procedure:

procedure_name(argument declarations) is -- Header commentrequire Preconditiondo Procedure bodyensure PostconditionEnd

-- An example:

put_child(new_child: NODE) is -- Add new to the children -- of current noderequire new_child /= Void do ... Insertion algorithm ...ensure new_child.parent = Current; child_count = old child_count + 1end -- put_child

-- An example:

put_child(new_child: NODE) is -- Add new to the children -- of current noderequire new_child /= Void do ... Insertion algorithm ...ensure new_child.parent = Current; child_count = old child_count + 1end -- put_child

Contracts

• The pre and postconditions are assertions– Evaluate to true or false– Precondition

• Requirements that any call must satisfy

– Postcondition • Properties that are ensured at the end of the procedure

execution

• The precondition or postcondition is assumed to be true

Assertion Violations

• The assertions can be checked dynamically at run-time as an approach to debugging the software

PreconditionViolation

PreconditionViolation

Caller BugCaller Bug

PostconditionViolation

PostconditionViolation

Callee BugCallee Bug

Defensive Programming vs. Design by Contract

• Defensive Programming– An approach that promotes putting checks in every module

to detect unexpected situations

– This results in redundant checks

– A lot of checks makes the software more complex and harder to maintain

• In Design by Contract the responsibility assignment is clear and it is part of the module interface

Class Invariants

• An assertion that holds for all instances of the class– A class invariant must be satisfied

after creation of every instance of the class

– The invariant holds at the method entry it should hold at the method exit

– conjunction added to the precondition and postcondition of each method in the class

Example: A class invariant for a binary tree

invariant left /= Void implies (left.parent = Current) right /=Void implies (right.parent = Current)

Example: A class invariant for a binary tree

invariant left /= Void implies (left.parent = Current) right /=Void implies (right.parent = Current)

Inheritance

ClassA

aMethod()

ClassB

Client

aMethod()

What happens to pre and postconditions in inheritance?

By definition we enforce

(1) The precondition of a derived method to be weaker

(2) The postcondition of a derived method to be stronger