Design By Contract

Presenter: Chris TremlMarch 19th

General Concept behind DBC

Software Systems work together through mutual obligations and benefits

Method calls are viewed as a contract between supplier (the object with the method) and client (the object making the call)

Both parties must obey their own laws during the contract

What is Design By Contract

Systematic approach to building bug-free systems

Framework for debugging, testing, and quality insurance.

Integrated documentation method Greater control of inheritance Exception Handling System Increased Abstraction Do this all in one clean, integrated, unobtrusive

way

Design By Contract?

First created for the Eiffel programming language.

Created by Bertrand Meyer Created in 1985 Rather new technique that has steady been

gaining popularity and usability.

Real Life Example

Let’s us a real world example: A person flying to Florida.

The client is the person.

The supplier is the Airline.

The airline must first have a flight to Florida for the time the person wants (obligation). By having this the Airline can obtain their fee from the person (benefit).

The person must have the money to pay the airline’s fee (obligation). Then the person can arrive in Florida at the specified time (benefit)

In order for this contract to work all obligations must be fulfilled otherwise neither party gets their benefit.

Real Life continued…

The Laws must be obeyed though…

If during the course of this contract the person does something they are not suppose to, such as disrupt the flight or smuggling contraband, the contract shall be cancelled.

Likewise, the Airline must follow their laws also. If the plane is not flight worthy the contract shall be cancelled.

How does DBC work?

Invariants Class Invariants Loop Invariants

Conditions Pre-conditions Post-conditions

Design by Contract primarily works through two ways:

Conditions

Pre-Conditions Something that must be true before the

method can execute Post-Conditions

Something that must be true after the method is done executing.

If any pre-condition or post-condition is must fulfilled the method will be cancel.

Pre-Conditions

These are the obligations that both the client and supplier must fulfill.

Used to make sure that parameters passed are valid.

Used to make sure the object is in a proper state to execute the method.

Note: Pre-Conditions help to separate DBC from other methods such as defensive programming.

Pre-Conditions in use

Here is an example of what how Pre-Conditions might be used for a non growing container class’s AddAt method.

public void AddAt(int index)

{

PreConditions:

index >= 0

index < Capacity

this[index] == null

…… Code goes here……

}

Post-Conditions

The Post-Conditions are the benefits , or outcomes, that must be true when the method is done executing.

Used to make sure no side-effects have occurred.

Used to make sure the method has done it’s purpose.

Post-Conditions in use

Here is an example of how post-conditions can be used in a Date Class’s SetYear() method

Public void setYear(int newYear){

…Code goes here…PostConditions:Year == newYearMonth == old MonthDay == old Day

}

Note: The “old” keyword is essential for DBC post-conditions as it will make the variable placed after it be the value of the variable before the

method was executed.

Pre and Post Conditions combined

Now let’s show an example of a method that uses both types of conditions:

public void setYear(int newYear){

PreConditions:newYear >= 0EditAble == trueEnd Pre-Conditions….Code goes here…PostConditions:Year == newYearMonth == old MonthDay == old Day

}

OK, but what’s the point?

Completely Independent of Implementation Abstraction

Tells the method’s user everything they need to know Documentation

Alerts user if a condition is not met Exception Handling

public void setYear(int newYear){

PreConditions:newYear >= 0EditAble == trueEnd Pre-Conditions….Code goes here…PostConditions:Year == newYearMonth == old MonthDay == old Day

}

Invariants

The invariants are the “laws” that a class must always follow.

There are two types of invariants in Design By ContractClass InvariantsLoop Invariants

Class Invariants

A Class Invariant is something that must always be true throughout the course of a class instance’s existence.

Used to define the boundaries between an object’s valid state and invalid state.

Concept behind Class Invariants

In an OO system, errors happen when an object enters an invalid state.

Objects however cannot report this. These invalid states then propagate

through the system. By the time an error is found the object

that caused the root problem may be buried deep within the system.

Error Propagation

Error is thrown

Uses Invalid Data Valid State Valid State

Uses Invalid Data

Uses Invalid Data

Uses Invalid Data

Valid State Uses Invalid Data

Uses Invalid Data

Invalid State

Valid State Valid State

Valid State

Class Invariants Continued…

Class Invariants let a class know when it is in an invalid state.

Once a class enters an invalid state it can take actions to fix it or alert it’s users about the error.

Using Class Invariants

Here is an example of class invariants for a Time Class

Public class Time{

…Members Go Here……Methods Go Here…Invariants:Hour >= 0Hour <= 23Minute >= 0Minute < 60Second >= 0Second < 60

}

Class Invariants effect on Inheritance

Class Invariants have a profound effect on inheritance. Making inheritance much more effective

and useful. Child classes inherit all class invariants. Child classes can only add to (constrain)

class invariants.

How does that help Inheritance? Inheritance relationships are not as used as the

client-user relationship This is because inheritance allows access to the

internals of the parent class And could let the user allow the child to enter a state

that would make the parent invalid. This is the reason behind “sealed” and “final” in .Net

and Java Since a child inherits all class invariants, there is

no worry of this. This means a child truly can be used anywhere a

parent is.

OK, but why use Class Invariants?

Gives object responsibility of staying in valid states. Reliability

Fixes many problem with inheritance Reusability

Gives users of the class an explicit understanding of the class Documentation

Users of the class do not need to know the internals of the class Abstraction

Public class Time{

…Members Go Here……Methods Go Here…Invariants:Hour >= 0Hour <= 23Minute >= 0Minute < 60Second >= 0Second < 60

}

Loop Invariants

Used to make sure a loop is running correctly.

Must be true upon entry, throughout, and upon exit of the loop.

Using Loop Invariants

Here is an example of a loop invariant

K := 1;from

I := 1until

I = 10invariant

K >= 0loop

K = K + 1;end

Why use Loop Invariants?

Loop Invariants are used to prove the properties of a loop.

Prove the soundness of the logic behind the loop.

Design By Contract provides an easy way of using Loop Invariants on actual code Making loop invariants more useful than

questions on final exams.

Putting it all togetherPublic class Time{

…Fields go Here…public AddTime(Time increaseTime){

PreConditions:increaseTime != null…Code Goes Here….PostConditions:Hour == (old Hour + increaseTime.Hour) % 24Minute == (old Minute + increaseTime.Minute) % 60Second == (old Second + increaseTime.Second) % 60

}Invariants:Hour >= 0Hour < 24Minute >= 0Minute < 60Second >= 0Second < 60

}

That’s neat, but what languages have it?

Eiffel (original language design around DBC) D C#(plugins: eXtensible C# and Spec# ) Java(plugins: STclass, Jcontract, iContract2) Ruby(plugins: DesignByContract, Ruby DBC) C (plugins: DBC for C and GNU Nana ) C++(plugins: C2 and Digital Mars )

Is it useful if my language doesn’t use it?

Absolutely! DBC can applied at low level design. Can be used to help trace classes and code

to requirements. Clears up ambiguity.

Large projectsOutsourcing

Outsourcing and Large Projects Many times the people who design the system

do not write every line of code. Many bugs and errors happen from ambiguity of

design. Coders interpret differently than Designers

intended DBC eliminates this by explicitly saying what

methods need to do by conditions DBC eliminates Class ambiguity with invariants Coders have a better understand of class without

needed to know how other classes will use it

What industry and projects would this work well for?

Any industry that has reliability as a type priority. Power Plants Weapons Platforms Real Time Systems Nuclear Submarines

Industry continued…

Design by Contract will also work well for any system were reuse is a top priority In an OO world, pretty much everything

In Non-OO industries DBC also works Only conditions and loop invariants are

used

Different Implementations

Used only as a debugging toolRemoved from release code

Used as exception handling system Remove only conditions Remove only invariants

Design By Contract

The End

Works Cited

www.eiffel.com

http://www.artima.com/intv/contracts.html

http://www.muc.de/~hoelzl/tools/dbc/dbc-intro.html

http://se.ethz.ch/~meyer/publications/computer/contract.pdf