Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany

Transcription

1 Softwaretechnik Lecture 13: Design by Contract Peter Thiemann University of Freiburg, Germany

2 Table of Contents Design by Contract Contracts for Procedural Programs Contracts for Object-Oriented Programs Contract Monitoring Verification of Contracts Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

3 Contracts for Procedural Programs Contracts for Procedural Programs Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

4 Contracts for Procedural Programs Reminder: Underlying Idea Transfer the notion of contract between business partners to software engineering What is a contract? A binding agreement that explicitly states the obligations and the benefits of each partner Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

5 Contracts for Procedural Programs Example: Contract between Builder and Landowner Obligations Landowner Provide 5 acres of land; pay for building if completed in time Builder Build house on provided land in less than six month Benefits Get building in less than six months No need to do anything if provided land is smaller than 5 acres; Receive payment if house finished in time Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

6 Contracts for Procedural Programs Who are the contract partners in SE? Partners can be modules/procedures, objects/methods, components/operations,... In terms of software architecture, the partners are the components and each connector may carry a contract. Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

7 Contracts for Procedural Programs Contracts for Procedural Programs Goal: Specification of imperative procedures Approach: give assertions about the procedure Precondition must be true on entry ensured by caller of procedure Postcondition must be true on exit ensured by procedure if it terminates Precondition(State) Postcondition(procedure(State)) Notation: {Precondition} procedure {Postcondition} Assertions stated in first-order predicate logic Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

8 Contracts for Procedural Programs Example Consider the following procedure: a an integer square root of a / int root (int a) { int i = 0; int k = 1; int sum = 1; while (sum <= a) { k = k+2; i = i+1; sum = sum+k; } return i; } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

9 Contracts for Procedural Programs Specification of root types guaranteed by compiler: a integer and root integer (the result) 1. root as a partial function Precondition: a 0 Postcondition: root root a < (root + 1) (root + 1) 2. root as a total function Precondition: true Postcondition: (a 0 root root a < (root + 1) (root + 1)) (a < 0 root = 0) Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

10 Contracts for Procedural Programs Weakness and Strength Goal: find weakest precondition a precondition that is implied by all other preconditions highest demand on procedure largest domain of procedure (Q: what if precondition = false?) find strongest postcondition a postcondition that implies all other postconditions smallest range of procedure (Q: what if postcondition = true?) Met by root as a total function : true is weakest possible precondition defensive programming Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

11 Contracts for Procedural Programs Example (Weakness and Strength) Consider root as a function over integers Precondition: true Postcondition: (a 0 root root a < (root + 1) (root + 1)) (a < 0 root = 0) true is the weakest precondition The postcondition can be strengthened to (root 0) (a 0 root root a < (root + 1) (root + 1)) (a < 0 root = 0) Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

12 Contracts for Procedural Programs An Example Insert an element in a table of fixed size class TABLE<T> { int capacity; // size of table int count; // number of elements in table T get (String key) {...} void put (T element, String key); } Precondition: table is not full count < capacity Postcondition: new element in table, count updated count capacity get(key) = element count = old count + 1 Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

13 Contracts for Procedural Programs Caller Procedure Obligations Call put only on non-full table Insert element in table so that it may be retrieved through key Benefits Get modified table in which element is associated with key No need to deal with the case where table is full before insertion Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

14 Contracts for Object-Oriented Programs Contracts for Object-Oriented Programs Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

15 Contracts for Object-Oriented Programs Contracts for Object-Oriented Programs Contracts for methods have additional complications local state receiving object s state must be specified inheritance and dynamic method dispatch receiving object s type may be different than statically expected; method may be overridden Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

16 Contracts for Object-Oriented Programs Local State Class Invariant class invariant INV is predicate that holds for all objects of the class must be established by all constructors must be maintained by all visible methods Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

17 Contracts for Object-Oriented Programs Pre- and Postconditions for Methods constructor methods c {Pre c } c {INV } visible methods m {Pre m INV } m {Post m INV } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

18 Contracts for Object-Oriented Programs Table example revisited count and capacity are instance variables of class TABLE INV TABLE is count capacity specification of void put (T element, String key) Precondition: count < capacity Postcondition: get(key) = element count = old count + 1 Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

19 Contracts for Object-Oriented Programs Inheritance and Dynamic Binding Subclass may override a method definition Effect on specification: Subclass may have different invariant Redefined methods may have different pre- and postconditions raise different exceptions method specialization Relation to invariant and pre-, postconditions in base class? Guideline: No surprises requirement (Wing, FMOODS 1997) Properties that users rely on to hold of an object of type T should hold even if the object is actually a member of a subtype S of T. Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

20 Contracts for Object-Oriented Programs Invariant of a Subclass Suppose class MYTABLE extends TABLE... each property expected of a TABLE object should also be granted by a MYTABLE object if o has type MYTABLE then INV TABLE must hold for o INV MYTABLE INV TABLE Example: MYTABLE might be a hash table with invariant INV MYTABLE count capacity/3 Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

21 Contracts for Object-Oriented Programs Method Specialization If MYTABLE redefines put then... the new precondition must be weaker and the new postcondition must be stronger because in TABLE cast = new MYTABLE (150);... cast.put (new Terminator (3), Arnie ); the caller only guaranties Pre put,table and expects Post put,table Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

22 Contracts for Object-Oriented Programs Requirements for Method Specialization Suppose class T defines method m with assertions Pre T,m and Post T,m throwing exceptions Exc T,m. If class S extends class T and redefines m then the redefinition is a sound method specialization if Pre T,m Pre S,m and Post S,m Post T,m and Exc S,m Exc T,m each exception thrown by S.m may also be thrown by T.m Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

23 Contracts for Object-Oriented Programs Example: MYTABLE.put Pre MYTABLE,put count < capacity/3 not a sound method specialization because it is not implied by count < capacity. MYTABLE may automatically resize the table, so that Pre MYTABLE,put true a sound method specialization because count < capacity true! Suppose MYTABLE adds a new instance variable T lastinserted that holds the last value inserted into the table. Post MYTABLE,put item(key) = element count = old count + 1 lastinserted = element is sound method specialization because Post MYTABLE,put Post TABLE,insert Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

24 Contracts for Object-Oriented Programs Interlude: Method Specialization in Java 5 Overriding methods in Java 5 only allows specialization of the result type. (It can be replaced by a subtype). The parameter types muss stay unchanged (why?) Example : Assume A extends B class C { A m () { return new A(); } } class D extends C { B m () { // overrides method C.m() return new B(); } } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

25 Contract Monitoring Contract Monitoring Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

26 Contract Monitoring Contract Monitoring What happens if a system s execution violates an assertion at run time? A violating execution runs outside the system s specification. The system s reaction may be arbitrary crash continue Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

27 Contract Monitoring Contract Monitoring What happens if a system s execution violates an assertion at run time? A violating execution runs outside the system s specification. The system s reaction may be arbitrary crash continue Contract Monitoring evaluates assertions at run time raises an exception indicating any violation assign blame for the violation Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

28 Contract Monitoring Contract Monitoring What happens if a system s execution violates an assertion at run time? A violating execution runs outside the system s specification. The system s reaction may be arbitrary crash continue Contract Monitoring evaluates assertions at run time raises an exception indicating any violation assign blame for the violation Why monitor? Debugging (with different levels of monitoring) Software fault tolerance (e.g., α and β releases) Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

29 Contract Monitoring What can go wrong precondition: evaluate assertion on entry identifies problem in the caller postcondition: evaluate assertion on exit identifies problem in the callee invariant: evaluate assertion on entry and exit problem in the callee s class hierarchy: unsound method specialization need to check (for all superclasses T of S) Pre T,m Pre S,m on entry and Post S,m Post T,m on exit how? Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

30 Contract Monitoring Hierarchy Checking Suppose class S extends T and overrides a method m. Let T x = new S() and consider x.m() on entry if Pre T,m holds, then Pre S,m must hold, too PreS,m must hold on exit Post S,m must hold if Post S,m holds, then Post T,m must hold, too in general: cascade of implications between S and T pre- and postcondition only checked for S! If the precondition of S is not fulfilled, but the one of T is, then this is a wrong method specialization. Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

31 Contract Monitoring Examples interface IConsole { int { getmaxsize > 0 } void display (String { s.length () < this.getmaxsize() } } class Console implements IConsole { int getmaxsize () {... { getmaxsize > 0 } void display (String s) {... { s.length () < this.getmaxsize() } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

32 Contract Monitoring A Good Extension class RunningConsole extends Console { void display (String s) {... super.display(string. substring (s,...,... + getmaxsize()))... { true } } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

33 Contract Monitoring A Bad Extension class PrefixedConsole extends Console { String getprefix() { return >> ; } void display (String s) { super.display (this.getprefix() + s); { s.length() < this.getmaxsize() this.getprefix().length() } } caller may only guarantee IConsole s precondition Console.display can be called with to long argument blame the programmer of PrefixedConsole! Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

34 Contract Monitoring Properties of Monitoring Assertions can be arbitrary side effect-free boolean expressions Instrumentation for monitoring can be generated from the assertions Monitoring can only prove the presence of violations, not their absence Absence of violations can only be guaranteed by formal verification Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

35 Verification of Contracts Verification of Contracts Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

36 Verification of Contracts Verification of Contracts Given: Specification of imperative procedure by Precondition and Postcondition Goal: Formal proof for Precondition(State) Postcondition(procedure(State)) Method: Hoare Logic, i.e., a proof system for Hoare triples of the form {Precondition} procedure {Postcondition} named after C.A.R. Hoare, the inventor of Quicksort, CSP, and many other here: method bodies, no recursion, no pointers (extensions exist) Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

37 Verification of Contracts Syntax E ::= c x E + E... expressions B, P, Q ::= B P Q P Q boolean expressions E = E E E... C, D ::= x=e assignment C;D sequence if B then C else D conditional while B do C iteration H ::= {P}C{Q} Hoare triples (boolean) expressions are free of side effects Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

38 Verification of Contracts Semantics Domains and Types BValue = true false IValue = σ State = Variable Value E : Expression State IValue B : BoolExpression State BValue S : State State State := State { } result indicates non-termination Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

39 Verification of Contracts Semantics Expressions E c σ = c E x σ = σ(x) E E+F σ = E E σ + E F σ... B E=F σ = E E σ = E F σ B B σ = B B σ... Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

40 Verification of Contracts Semantics Statements S C = S skip σ = σ S x=e σ = σ[x E E σ] S C;D σ = S D (S C σ) S if B then C else D σ = B B σ = true S C σ, S D σ S while B do C σ = F (σ) where F (σ) = B B σ = true F (S C σ), σ McCarthy conditional: b e 1, e 2 Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

41 Verification of Contracts Proving a Hoare triple {P} C {Q} holds if ( σ State) P(σ) (Q(S C σ) S C σ = ) (partial correctness) alternative reading/notation: P, Q State {P} C {Q} S C P Q reading predicates as boolean expressions B P σ = true (B Q (S C σ) = true S C σ = ) Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

42 Verification of Contracts Proof Rules for Hoare Triples Proving that {P} C {Q} holds directly from the definition is tedious Instead: define axioms and inferences rules Construct a derivation to prove the triple Choice of axioms and rules guided by structure of C Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

43 Verification of Contracts Skip Axiom {P} skip {P} Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

44 Verification of Contracts Skip Axiom {P} skip {P} Correctness S skip σ = σ S skip P = P Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

45 Verification of Contracts Assignment Axiom {P[x E]} x = E {P} Examples: {1 == 1} x = 1 {x == 1} {odd(1)} x = 1 {odd(x)} {x == 2 y + 1} y = 2 y {x == y + 1} Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

46 Verification of Contracts Assignment Axiom Correctness {P[x E]} x = E {P} Semantics S x=e σ = σ[x E E σ] Have to show B P[x E] σ = true (B P (S x = E σ) = true S x = E σ = ) By induction on P; result of B E ρe σ must remain the same; result of E E σ must remain the same Sufficient to show E E [x E] σ = E E σ[x E E σ] Holds because E x[x E] σ = E E σ = E x σ[x E E σ] Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

47 Verification of Contracts Sequence Rule Example: {P} C {R} {R} D {Q} {P} C;D {Q} {x == 2 y + 1} y = 2 y {x == y + 1} {x == y + 1} y = y + 1 {x == y} {x == 2 y + 1} y = 2 y; y = y + 1 {x == y} Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

48 Verification of Contracts Sequence Rule Example: {P} C {R} {R} D {Q} {P} C;D {Q} {x == 2 y + 1} y = 2 y {x == y + 1} {x == y + 1} y = y + 1 {x == y} {x == 2 y + 1} y = 2 y; y = y + 1 {x == y} Correctness If σ P then σ = S C σ R { } If σ = then S D = If σ R then S D σ Q { } Hence: σ P S C; D σ Q { } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

49 Verification of Contracts Conditional Rule {P B} C {Q} {P B} D {Q} {P} if B then C else D {Q} Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

50 Verification of Contracts Conditional Rule {P B} C {Q} {P B} D {Q} {P} if B then C else D {Q} Correctness Show: σ P implies S if B then C else D Q { } Exercize Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

51 Verification of Contracts Conditional Rule Issues Examples: {P x < 0} z = x {z == x } {P x 0} z = x {z == x } {P} if x < 0 then z = x else z = x {z == x } incomplete! precondition for z = x should be (z == x )[z x] x == x need logical rules Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

52 Verification of Contracts Logical Rules weaken precondition strengthen postcondition P P {P} C {Q} {P } C {Q} {P} C {Q} Q Q {P} C {Q } Example needs strengthening: P x < 0 x == x holds if P true! similarly: P x 0 x == x Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

53 Verification of Contracts Logical Rules weaken precondition strengthen postcondition P P {P} C {Q} {P } C {Q} {P} C {Q} Q Q {P} C {Q } Example needs strengthening: P x < 0 x == x holds if P true! similarly: P x 0 x == x Correctness P P iff P P (as set of states) Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

54 Verification of Contracts Completed example: D 1 = x < 0 x == x { x == x } z = x {z == x } {x < 0} z = x {z == x } D 2 = x 0 x == x {x == x } z = x {z == x } {x 0} z = x {z == x } D 1 D 2 {x < 0} z = x {z == x } {x 0} z = x {z == x } {true} if x < 0 then z = x else z = x {z == x } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

55 Verification of Contracts While Rule {P B} C {P} {P} while B do C {P B} P is loop invariant Example: try to prove { a>=0 /\ i==0 /\ k==1 /\ sum==1 } while sum <= a do k = k+2; i = i+1; sum = sum+k { i*i <= a /\ a < (i+1)*(i+1) } while rule not directly applicable... Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

56 Verification of Contracts While Rule Step 1: Find the loop invariant a>=0 /\ i==0 /\ k==1 /\ sum==1 => i*i<=a /\ i>=0 /\ k==2*i+1 /\ sum==(i+1)*(i+1) P i i a i 0 k == 2 i + 1 sum == (i + 1) (i + 1) holds on entry to the loop To prove that P is an invariant, requires to prove that {P sum a} k = k + 2; i = i + 1; sum = sum + k {P} It follows by the sequence rule and weakening: Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

57 Verification of Contracts Proof of loop invariance { i*i<=a /\ i>=0 /\ k==2*i+1 /\ sum==(i+1)*(i+1) /\ sum<=a } { i>=0 /\ k+2==2+2*i+1 /\ sum==(i+1)*(i+1) /\ sum<=a } k = k+2 { i>=0 /\ k==2+2*i+1 /\ sum==(i+1)*(i+1) /\ sum<=a } { i+1>=1 /\ k==2*(i+1)+1 /\ sum==(i+1)*(i+1) /\ sum<=a } i = i+1 { i>=1 /\ k==2*i+1 /\ sum==i*i /\ sum<=a } { i*i<=a /\ i>=1 /\ k==2*i+1 /\ sum+k==i*i+k /\ sum+k<=a+k } sum = sum+k { i*i<=a /\ i>=1 /\ k==2*i+1 /\ sum==i*i+k /\ sum<=a+k } { i*i<=a /\ i>=1 /\ k==2*i+1 /\ sum==i*i+2*i+1 /\ sum<=a+k } { i*i<=a /\ i>=1 /\ k==2*i+1 /\ sum==(i+1)*(i+1) /\ sum<=a+k } { i*i<=a /\ i>=0 /\ k==2*i+1 /\ sum==(i+1)*(i+1) } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

58 Verification of Contracts Step 2: Apply the while rule {P sum a} k = k + 2; i = i + 1; sum = sum + k {P} {P} while sum a do k = k + 2; i = i + 1; sum = sum + k {P sum > a} Now, P sum > a is { i*i<=a /\ i>=0 /\ k==2*i+1 /\ sum==(i+1)*(i+1) /\ sum>a } implies { i*i<=a /\ a<(i+1)*(i+1) } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

59 Verification of Contracts Correctness of While-Rule {P B} C {P} {P} while B do C {P B} Consider S while B do C σ = F (σ) where F (σ) = B B σ = true F (S C σ), σ Case n N, B B (S C (n) σ) = true: set F (σ) =. Case n N, B B (S C (n) σ) = false: let n 0 be minimal Let σ P = (P B) (P B) Case n 0 = 0: σ P B, then F (σ) = σ P B. OK. Case n 0 > 0: σ P B, then σ = S C σ P { } by assumption. By induction, F (σ ) = S C (n 0 1) σ P B { } Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54

60 Verification of Contracts Properties of Formal Verification requires more restrictions on assertions (e.g., use a certain logic) than monitoring full compliance of code with specification can be guaranteed scalability is a challenging research topic: full automatization manageable for small/medium examples large examples require manual interaction real programs use arrays and dynamic datastructures (pointers, objects) Peter Thiemann (Univ. Freiburg) Softwaretechnik / 54