1. ceg860(Prasad)L10DC1 Design by Contract Invariants Pre-post conditions : Rights and Obligations Exceptions : Contract Violations

2. ceg860(Prasad)L10DC2 Correctness correctImplementation is correct relative to a specification. { P } S { Q } Precondition binds the client. It is an obligation for the client and a benefit for the supplier. Postcondition binds the supplier (routine). It is an obligation for the supplier and a benefit for the client. Non-Redundancy Principle Non-Redundancy Principle

3. ceg860(Prasad)L10DC3 Spec vs Impl Spec: pre: x=0 /\ y=3 post: x=3 /\ y=0 Implementations x := 3; y := 0 x :=x+y; y:=x*y t=x; x=y; y=t; Spec? pre: true post: x*x = 2 Spec pre: > 0 post: x*x -2 <

4. ceg860(Prasad)L10DC4 Insertion Sort (define (insertion-sort lon) (if (null? lon) () (insert (car lon) (insertion-sort (cdr lon)) ) // car = first/head, cdr = rest/tail (insertion-sort '(2 3 1 4 7 5) ) = (1 2 3 4 5 7)

5. ceg860(Prasad)L10DC5 (define (insert n lon) (cond ((null? lon) (list n)) ((> n (car lon)) (cons (car lon) (insert n (cdr lon)) ) (else (cons n lon)) )) Precondition : lon is ordered. Postcondition : (insert n lon) is ordered.

6. ceg860(Prasad)L10DC6 Assertions In theory, assertions are first-order logic formulae. In a programming language, assertions are computable boolean expressions that can contain program variables, arithmetic/boolean operations, and possibly, user-defined functions.

7. ceg860(Prasad)L10DC7 (contd) In Eiffel, the expression OLD attr in postcondition denotes the value of the attribute attr on routine entry. In general, the preconditions must not use features hidden from the clients. However, the postconditions can use any feature, even though only clauses without hidden features are directly usable by the client.

8. ceg860(Prasad)L10DC8 Algebraic Specification Example

9. ceg860(Prasad)L10DC9 ADT GStack create: -> GStack push: Gstack x G -> GStack pop: Gstack -> GStack top: GStack -> G empty: Gstack -> boolean constructors : create, push observers : top, empty non-constructors :pop

10. ceg860(Prasad)L10DC10 Forall s GStack, x G : pop(push( s, x )) = s top(push( s, x )) = x empty(create()) = true empty(push( s, x )) = false Preconditions: pop( s ) requires s =/= create() top( s ) requires s =/= create()

11. ceg860(Prasad)L10DC11 ADT (Bounded) GStack create: int -> GStack push: Gstack x G -> GStack pop: Gstack -> GStack top: GStack -> G empty: Gstack -> boolean full: Gstack -> boolean constructors : create, push observers : top, empty, full non-constructors :pop

12. ceg860(Prasad)L10DC12 Auxiliary functions: Forall s Gstack Terms : n int, x G : n >0 : count(create( n )) = 0 count(push( s, x )) = 1 + count( s ) capacity(create( n )) = n capacity(push( s, x )) = capacity( s )

13. ceg860(Prasad)L10DC13 Preconditions: Forall s Gstack Terms, n int, x G : n >0 : pop( s ) requires s =/= create( n ) top( s ) requires s =/= create( n ) push( s,x ) requires capacity( s ) >= count( s ) + 1

14. ceg860(Prasad)L10DC14 Forall s GStack, n int, x G : n >0 : pop(push( s, x )) = s top(push( s, x )) = x empty(create( n )) = true empty(push( s, x )) = false full( s ) = (capacity( s ) = count( s ))

15. ceg860(Prasad)L10DC15 Specifying Class

16. ceg860(Prasad)L10DC16 Categories of Operations Creators ( … x … Constructors Queries (… x T x … …) Observers Commands (… x T x … Constructors, Non-constructors

17. ceg860(Prasad)L10DC17 class IntStack { private int capacity ; private int count; public IntStack(int c) {... // require: c >=0 // ensure: capacity = c // ensure: empty() // ensure: count = 0 } public void push(int e) {... // require: not full() // ensure: top() = e // ensure: not empty() // ensure: count = old count + 1 }

18. ceg860(Prasad)L10DC18 public void pop() {... // require: not empty() // ensure: not full() // ensure: count = old count - 1 } public int top() {... // require: not empty() } public boolean empty() {...} public boolean full() {...} // class invariants: // empty() = (count = 0) // full() = (count = capacity) // pop(push(e)) = identity-map }

19. ceg860(Prasad)L10DC19 Class Invariant class invariantA class invariant for C is a set of assertions that every instance of C must satisfy at all stable times. That is, immediately after its creation and before/after a public method call (by a client). The class invariant relates attributes and/or functions. E.g., 0 <= count <= capacity E.g., (count > 0) => (s[count] = top())

20. ceg860(Prasad)L10DC20 Role of Class Invariants in Software Engineering InvariantsInvariants not only apply to the routines actually written in the class, but also to any routines added later. Correctness of a method methCorrectness of a method meth {P and Inv} meth_body {Q and Inv} Role of constructor definitionsRole of constructor definitions If default initialization of the fields violates class invariant, an explicit constructor is needed.

21. ceg860(Prasad)L10DC21 From ADT specs to Pre-Post Conditions function routineA precondition for a specs function reappears as a precondition for the corresponding routine. command queries procedureAxioms involving a command (possibly with queries) reappear as postconditions of the corresponding procedure.

22. ceg860(Prasad)L10DC22 (contd) queries functionsclausesAxioms involving only queries reappear as postconditions of the corresponding functions or as clauses of the class invariant. creator constructor procedureAxioms involving a creator reappear in the postcondition of the corresponding constructor procedure.

23. ceg860(Prasad)L10DC23 Introducing Representation class IntStack { private int[] s ;... public IntStack(int c) {... // ensure: s =/= null }; public void push(int e) {... // ensure: s[count] = e // ensure: for i in [1..count-1] do // s[i] = old s[i] }; public void pop() {... // ensure: for i in [1..count-1] do // s[i] = old s[i] };... } //--FRAME AXIOMS--//

24. ceg860(Prasad)L10DC24 Model-based Spec. and Impl. Implementation/Representation invariant Assertion characterizing the set of concrete objects that are implementations of the abstract objects (cf. class invariant). Abstraction function Maps a concrete object (satisfying representation invariant) to the corresponding abstract object. ontonot one-oneUsually onto but not one-one.

25. ceg860(Prasad)L10DC25 Bugs A run-time assertion violation is a manifestation of a bug in the software. Precondition violation : Bug in the client. Postcondition violation : Bug in the supplier. Error A wrong decision made during software development. Defect The property of a software that may cause the system to depart from its intended behavior. Fault The event of a software departing from its intended behavior.

26. ceg860(Prasad)L10DC26 Failure failsA routine call fails if it terminates its execution in a state that does not satisfy the routines contract. Violates postcondition or class invariant. Calls a routine whose precondition is violated. Causes an abnormal OS signal such as arithmetic overflow, memory exhaustion, etc.

27. ceg860(Prasad)L10DC27 Exception exceptionAn exception is a run-time event that may cause a routine call to fail. Every failure results from an exception, but not every exception results in a failure (if the routine can recover from it).

28. ceg860(Prasad)L10DC28 Disciplined Exception Handling Rescue Clause –Retry Attempt to change the conditions that led to the exception and execute the routine again from the start (possibly, exploring alternatives). –Software fault tolerance. { true } Retry_Body { Inv and Pre } –Failure Clean-up the environment (restore the invariant), terminate the call and report failure to the caller. { true } Rescue_Body { Inv }

29. ceg860(Prasad)L10DC29 Developer Exceptions Exceptions are propagated up the call chain (dynamic). A supplier code can define an exception and raise it, to enable context-sensitive handling of the exception by the various clients. –In Java, an exception is a typed packet of information (object), which is useful in locating and diagnosing faults. Checked exceptions contribute to robustness by forcing the client to process exception explicitly, or propagate it explicitly.