DBC

1. DBC NOTES

2. Design By Contract • A contract carries mutual obligations and benefits. • The client should only call a routine when the routine’s pre-condition is respected. • The routine ensures that after completion its post-condition is respected.

3. Design by Contract • Created by Bertrand Meyer, in Eiffel • Each class defines a contract, by placing assertions inside the code • Assertions are just Boolean expressions • Eiffel: identified by language keywords • iContract: identified by javadoc attributes • Assertions have no effect on execution • Assertions can be checked or ignored

4. Methods • Each feature is equipped with a precondition and a postcondition • double sqrt (double x) • require • x >= 0 • do • … • ensure • result * result == x • end

5. Methods II • The same in iContract syntax: • //** return Square root of x • @pre x >= 0 • @post return * return == x */ • double sqrt (double x) { … } • Assertions are just Boolean expressions • Except result and old in postconditions • Function calls are allowed, but… • Don’t modify data: ++i, inc(x), a = b

6. Class B Class A m1() Design by Contract Consider the relationship between a class and its clients: contract DbC views this as a formal agreement, or contract, expressing each party’s rights and obligations. claims responsibilities Without such a precise definition we cannot have a significant degree of trust in large software systems. Contract violations lead to run-time errors, i.e. exceptions. So we will also consider exceptionhandling.

7. Software Correctness Suppose someone comes to you with a program, and asks “Is this program correct?”. This question is meaningful only if there is a precise description of what the program is supposed to do regardless of the size of the program Such a description is called a specification. A specification must be precise. Otherwise it is not possible to reason about correctness.

8. Expressing a Specification Let A be some operation. A correctness formula is an expression of the form: e.g. a single instruction or a whole method { P }A{ Q } PandQareassertions(logical predicates):Pis thepre-condition, Qthepost-condition. It means: “Any execution of A, starting in a state where P holds, will terminate in a state where Q holds”. E.g.{x  9}x  x + 5{x 13}

9. Pre- and Post-conditions pre-condition post-condition { P }A{ Q } – expresses the constraints under which a method will function properly – expresses properties of the state resulting from a method’s execution – expresses a guarantee that the method will yield a state satisfying certain properties, assuming it has been called with the pre-condition satisfied. – applies to allcalls of the method both from within the class and from clients. A correctsystem will neverexecute a call in a state that does not satisfy the pre-condition of the called method. A correctsystem will alwaysdeliver a state that satisfies the post-condition of the called method.

10. contract Class B m(x); pre: p post: q Class A Contracting for Software Reliability p binds the client A. It is an obligation for A but a benefit for B. q binds the supplier B. It is an obligation for B but a benefit for A. Consider Class B says to its clients: “If you promise to call m with p satisfied, then I, in return, promise to deliver a final state in which q is satisfied.”

11. contract Class B x a put(x); a pre:… b post:… b c c Class A E.g. Consider the put operation for stacks: Stack not full Stack updated B.put(x) Obligations Benefits Client (A) Must satisfy precondition: Only call put(x) on a non-full stack. (From postcondition) Get stack updated. (From precondition) Simpler processing, can assume stack not full. Supplier (B) Must satisfy postcondition: Update stack with x on top.

12. count >= 0 and count <= capacity and Class Stack stack_is_empty = (count = 0) Attrs … Methods … Inv:… Class Invariants Preconditions and postconditions describe the properties of individual methods. A classinvariant isa global property of the instances of a class, which must be preserved by allmethods. A class invariant is an assertion in the class definition. E.g. a stack class might have the following class invariant: An invariant may link attributes (e.g. count and capacity), or functions (e.g. stack_is_empty), or attributes and functions.

13. An invariant for a class C must be satisfied by every instance of C at all “stable” times. “Stable” timesare those in which the instance is in an observable state i.e. on instance creation and beforeand afterevery method call. S1 a.new(...) a.m1(...) Si S2 is an observable state a.m2(...) S3 is not an observable state

14. Example E.g. a (mutable) class representing a range of real numbers: public class RealRange { private RealNumber min, max; public RealRange(RealNumber min, RealNumber max) { this.min = min; this.max = max; } public void setRange(RealNumber newMin, RealNumber newMax) {this.min = newMin; this.max = newMax;} During the execution of setRange(),min may temporarily be more than max. Clearly this class should have aninvariant:min <=max. • The constructor RealRangeestablishes the invariant. Before the constructor is executed, the invariant is meaningless —minand max are null. • The invariant is re-established by the time the method setRange()terminates.

15. S1 a.new(...) a.m1(...) S2 a.m2(...) S3 The Invariant Rule An assertion I is a correct invariant for a class C if and only if: • Every constructor of C, when applied to arguments satisfying its precondition in a state where the attributes have their default values, yields a state satisfying I. satisfies I constructor with pre-condition

16. S1 a.new(...) a.m1(...) S2 a.m2(...) S3 • Every method of the class, when applied to arguments and a state satisfying both Iand the method’s precondition, yields a state satisfying I. satisfies I method with pre-condition satisfies I

17. DbC and Inheritance What happens to assertions when classes are inherited? pre-, post-conditions and invariants How can assertions be “preserved” in the face of redeclaration (overriding) and dynamic binding? Actually assertions help maintain the semantics of classes and methods when they are inherited. Only through DbC can we understand what inheritance is really about!

18. Class Parent Class Parent Class Child Class Child Attrs … Attrs … Attrs … Attrs … Methods … Methods … Methods … Methods … Inv: P Inv: P Inv: P  C Inv: C Invariants The invariants of all the parents of a class apply to the class itself. The parents’ invariants are added (logically “and”ed) to the class’s own invariants.  The parents’ invariants neednotbe repeated in the class.

19. pre-condition post-condition { p }m{ q } Pre and Postconditions A method redeclaration may only: replace the original precondition by one equal or weaker replace the original postcondition by one equal or stronger The new version must accept all calls that were acceptable to the original. The new version must guarantee at least as much as the original. It may, but does not have to, accept more cases. It may, but does not have to, guarantee more. e.g. replace pre: x=10 by pre: x<=10 e.g. replace post: x<=10 by post: x=10

20. Summary • Software reliability requires precise specifications which are honoured by both the supplier and the client. • DbC uses assertions (pre and postconditions, invariants) as a contract between supplier and client. • DbC works equally well under inheritance.

21. DbC & Inheritance • Software reliability requires precise specifications which are honoured by both the supplier and the client. • Remember the LSP! • “The subclass must require less and ensure more” )Meyer, OOSC) • The only question is how to ensure this property!