Design By Contract

tunisianbromidrosisInternet και Εφαρμογές Web

5 Φεβ 2013 (πριν από 4 χρόνια και 8 μήνες)

84 εμφανίσεις

Design By Contract

Presenter: Chris Treml

March 19
th


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 == newYear


Month == old Month


Day == 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 >= 0


EditAble == true


End Pre
-
Conditions


….Code goes here…


PostConditions:


Year == newYear


Month == old Month


Day == 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 >= 0


EditAble == true


End Pre
-
Conditions


….Code goes here…


PostConditions:


Year == newYear


Month == old Month


Day == old Day

}

Invariants


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


There are two types of invariants in
Design By Contract


Class Invariants


Loop 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 >= 0


Hour <= 23


Minute >= 0


Minute < 60


Second >= 0


Second < 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 >= 0


Hour <= 23


Minute >= 0


Minute < 60


Second >= 0


Second < 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 := 1

until


I = 10

invariant


K >= 0

loop


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 together

Public class Time

{


…Fields go Here…


public AddTime(Time increaseTime)


{



PreConditions:



increaseTime != null



…Code Goes Here….



PostConditions:



Hour == (old Hour + increaseTime.Hour) % 24



Minute == (old Minute + increaseTime.Minute) % 60



Second == (old Second + increaseTime.Second) % 60


}


Invariants:


Hour >= 0


Hour < 24


Minute >= 0


Minute < 60


Second >= 0


Second < 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 projects


Outsourcing

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 tool


Removed 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.ht
ml



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



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