Design By Contract

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

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? • Invariants • Class Invariants • Loop Invariants • Conditions • Pre-conditions • Post-conditions Design by Contract primarily works through two ways:

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

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 • http://www.muc.de/~hoelzl/tools/dbc/dbc-intro.html • http://se.ethz.ch/~meyer/publications/computer/contract.pdf