Software Engineering

Transcription

1 Software Engineering Lecture 07: 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) Software Engineering / 62

3 Contracts for Procedural Programs Contracts for Procedural Programs Peter Thiemann (Univ. Freiburg) Software Engineering / 62

4 Contracts for Procedural Programs 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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

14 Contracts for Object-Oriented Programs Contracts for Object-Oriented Programs Peter Thiemann (Univ. Freiburg) Software Engineering / 62

15 Contracts for Object-Oriented Programs Contracts for Object-Oriented Programs Contracts for methods have additional features 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) Software Engineering / 62

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 public methods Peter Thiemann (Univ. Freiburg) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

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) Software Engineering / 62

21 Contracts for Object-Oriented Programs Method Specialization If MYTABLE redefines put then... the precondition in the subclass must be weaker and the postcondition in the subclass must be stronger than in the superclass because in TABLE personnel = new MYTABLE (150);... personnel.put (new Terminator (3), Arnie ); the caller only guarantees Pre put,table and expects Post put,table Peter Thiemann (Univ. Freiburg) Software Engineering / 62

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) Software Engineering / 62

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 is 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 a sound method specialization because Post MYTABLE,put Post TABLE,put Peter Thiemann (Univ. Freiburg) Software Engineering / 62

24 Contracts for Object-Oriented Programs Interlude: Method Specialization since 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 B extends A class Original { A m () { return new A(); } } class Specialization extends Original { B m () { // overrides method Original.m() return new B(); } } Peter Thiemann (Univ. Freiburg) Software Engineering / 62

25 Contracts for Object-Oriented Programs Interlude: NO Specialization Method specialization interferes with overloading in Java Class Specialization has two different methods Example : Assume B extends A class Original { void m (B x) { return; } } class Specialization extends Original { void m (A x) { // does NOT override method Original.m() return; } } Peter Thiemann (Univ. Freiburg) Software Engineering / 62

26 Contract Monitoring Contract Monitoring Peter Thiemann (Univ. Freiburg) Software Engineering / 62

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 Peter Thiemann (Univ. Freiburg) Software Engineering / 62

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 Peter Thiemann (Univ. Freiburg) Software Engineering / 62

29 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) Software Engineering / 62

30 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 in class S 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) Software Engineering / 62

31 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 If the precondition of S is not fulfilled, but the one of T is, then this is a wrong method specialization. on exit Post S,m must hold if PostS,m holds, then Post T,m must hold, too In general, with more than two classes: Cascade of implications between S and T must be checked. All intermediate pre- and postconditions must be checked. Peter Thiemann (Univ. Freiburg) Software Engineering / 62

32 Contract Monitoring Examples interface IConsole { getmaxsize > 0 } int { s.length () < this.getmaxsize() } void display (String s); } class Console implements IConsole { getmaxsize > 0 } int getmaxsize () {... { s.length () < this.getmaxsize() } void display (String s) {... } Peter Thiemann (Univ. Freiburg) Software Engineering / 62

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

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

35 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) Software Engineering / 62

36 Verification of Contracts Verification of Contracts Peter Thiemann (Univ. Freiburg) Software Engineering / 62

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

38 Verification of Contracts Syntax of While A small language to illustrate verification E ::= c x E + E... expressions B, P, Q ::= B P Q P Q boolean expressions E = E E E... C, D ::= skip no operation 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) Software Engineering / 62

39 Verification of Contracts Proof Rules for Hoare Triples It is possible, but tedious, to prove that {P} C {Q} holds directly from the definition: If P(σ) and σ = S C σ is terminating, then P(σ ) holds 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) Software Engineering / 62

40 Verification of Contracts Skip Axiom {P} skip {P} Peter Thiemann (Univ. Freiburg) Software Engineering / 62

41 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) Software Engineering / 62

42 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) Software Engineering / 62

43 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) Software Engineering / 62

44 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) Software Engineering / 62

45 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 for all P similarly: P x 0 x == x Peter Thiemann (Univ. Freiburg) Software Engineering / 62

46 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) Software Engineering / 62

47 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) Software Engineering / 62

48 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) Software Engineering / 62

49 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) Software Engineering / 62

50 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) Software Engineering / 62

51 Verification of Contracts Soundness of the Rules Intuitively, the proof rules are ok. But are they sound? Is there a definition from which {P} C {Q} can be proved directly? Answer: Yes! Each rule can be proved correct from this definition. First step: define the meaning of expressions and statements Peter Thiemann (Univ. Freiburg) Software Engineering / 62

52 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) Software Engineering / 62

53 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) Software Engineering / 62

54 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 ( ) = F (σ) = B B σ = true F (S C σ), σ McCarthy conditional: b e 1, e 2 Peter Thiemann (Univ. Freiburg) Software Engineering / 62

55 Verification of Contracts Proving a Hoare triple Theorem The Hoare triple {P} C {Q} holds according to the rules of Hoare calculus if ( σ State) P(σ) (Q(S C σ) S C σ = ) (partial correctness) Alternative readings predicates as sets of states: P, Q State {P} C {Q} S C P Q predicates as boolean expressions: B P σ = true (B Q (S C σ) = true S C σ = ) Proof By induction on the derivation of {P} C {Q}: For each Hoare rule, if the above hypothesis holds for the assumptions, then it holds for the conclusion. Peter Thiemann (Univ. Freiburg) Software Engineering / 62

56 Verification of Contracts Skip Axiom Correctness {P} skip {P} Correctness S skip σ = σ Assume B P σ = true. Then B P (S skip σ) = B P σ = true Peter Thiemann (Univ. Freiburg) Software Engineering / 62

57 Verification of Contracts Assignment Axiom Correctness {P[x E]} x E {P} Semantics: S x E σ = σ[x E E σ] Under assumption B P[x E] σ = true show that (B P (S x E σ) = true S x E σ = ) Apply definition of semantics to rhs; show that B P[x E] σ = true implies (B P (σ[x E E σ]) = true S x E σ = ) Requires induction on boolean expression P: Peter Thiemann (Univ. Freiburg) Software Engineering / 62

58 Verification of Contracts Assignment Axiom Correctness II Prove B P[x E] σ = B P (σ[x E E σ]) by induction on P. Case P Q: B Q[x E] σ def = B Q[x E] σ IH = B Q (σ[x E E σ]) def = B Q (σ[x E E σ]) Cases P Q Q and P Q Q analogously. Case P E = E : B (E = E )[x E] σ def = (E E [x E] σ = E E [x E] σ) Need another lemma: E E [x E] σ = E E σ[x E E σ] = (E E σ[x E E σ] = E E σ[x E E σ]) def = E E = E σ[x E E σ] Case P E E etc: analogously. Peter Thiemann (Univ. Freiburg) Software Engineering / 62

59 Verification of Contracts Assignment Axiom Correctness III Remains to show that E E [x E] σ = E E σ[x E E σ] by induction on E. Case E x: E x[x E] σ = E E σ = E x σ[x E E σ] Case E y, y x: E y[x E] σ = E y σ = σ(y) = σ[x E E σ](y) = E y σ[x E E σ] Case E E : Immediate by induction. E E [x E] σ def = E E [x E] σ IH = E E σ[x E E σ] def = E E σ[x E E σ] Case E E + E etc: analogously. Peter Thiemann (Univ. Freiburg) Software Engineering / 62

60 Verification of Contracts Sequence Rule Correctness Proof {P} C {R} {R} D {Q} {P} C;D {Q} Assume B P σ = true Show S C; D σ = or B Q (S C; D σ) = true Induction on {P} C {R} yields B R (S C σ) = true S C σ = If S C σ = then the rule is correct because S C;D σ =. Otherwise: induction on {R} C {Q} yields B Q (S D (S C σ)) = true S D (S C σ) = Recall that S D (S C σ) def = S C;D σ If S D (S C σ) = then the rule is correct because S C;D σ =. Otherwise: B Q (S C;D σ) = true QED Peter Thiemann (Univ. Freiburg) Software Engineering / 62

61 Verification of Contracts Conditional Rule Correctness {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 { } Exercise Peter Thiemann (Univ. Freiburg) Software Engineering / 62

62 Verification of Contracts Logical Rules Correctness weaken precondition strengthen postcondition Correctness P P iff P P (as set of states) P P {P} C {Q} {P } C {Q} {P} C {Q} Q Q {P} C {Q } Peter Thiemann (Univ. Freiburg) Software Engineering / 62

63 Verification of Contracts While-Rule Correctness {P B} C {P} {P} while B do C {P B} Recall the semantics of while: S while B do C σ = F (σ) where F ( ) = and F (σ) = B B σ = true F (S C σ), σ It is sufficient to show (fixpoint induction): If ( σ P), F (σ) P B { } then ( σ P), B B σ = true F (S C σ), σ P B { } Case B B σ = true: By induction on {P B} C {P}, either S C σ = (then F (S C σ) = F ( ) = completes the proof), or S C σ P (then F (S C σ) P B { } completes the proof) Case B B σ = false: Then σ P B. QED Peter Thiemann (Univ. Freiburg) Software Engineering / 62

64 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 and expressivity are challenging research topics: full automation manageable for small/medium examples large examples require manual interaction real programs use dynamic datastructures (pointers, objects) and concurrency Peter Thiemann (Univ. Freiburg) Software Engineering / 62