1. Presenter: Chris Treml
Design By Contract
Presenter: Chris Treml
March 19th

2. 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

3. 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

4. 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.

5. 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.

6. 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.

7. How does DBC work?
Design by Contract primarily works through two ways:
Invariants
Class Invariants
Loop Invariants
Conditions
Pre-conditions
Post-conditions

8. Conditions Pre-Conditions Post-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.

9. 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.

10. 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…… }

11. 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.

12. 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.

13. 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 }

14. 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 }

15. 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

16. 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.

17. 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.

18. Error Propagation

19. 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.

20. 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 }

21. 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.

22. 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.

23. 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 }

24. Loop Invariants Used to make sure a loop is running correctly.
Must be true upon entry, throughout, and upon exit of the loop.

25. 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

26. 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.

27. 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

28. 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 )

29. 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

30. 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

31. 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

32. 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

33. Different Implementations
Used only as a debugging tool
Removed from release code
Used as exception handling system
Remove only conditions
Remove only invariants

34. Design By Contract
The End

35. Works Cited www.eiffel.com http://www.artima.com/intv/contracts.html