2. Bertrand Meyer ETH Zurich, Eiffel Software & ITMO With Cristiano Calcagno, Carlo Furia, Alexander Kogtenkov*, Martin Nordio, Manuel Oriol +, Yu Pei, Nadia Polikarpova, Emmanuel Stapf*, Julian Tschannen, Stephan van Staden, Yi Wei, Andreas Zeller = & others *Eiffel Software + ETH, then U. of York, now ABB = U. Saarbrücken Microsoft Summer School, Moscow, July 2011 Verification As a Matter Of Course

3. SEL at ITMO S oftware E ngineering L aboratory | Лаборатория Программной Инженерии Создано в июне 2011 Ещё остаются открытые позиции!  Аспиранты и Кандидаты (на полной ставке)  Временные гранты (“sabbaticals”) для исследователей, 2 до 6 месяцев 2

4. Initiatives SEC-R conference in October 2011 ESEC 2013 will take place in Saint Petersburg New LinkedIn group: Программная Инженерия / Software Engineering Russia Software Engineering Seminar in Saint Petersburg ITMO and Polytechnical University (V. Itsykson) Every Thursday 18-21, visitors welcome http://meyerseminar.org 3

5. Contents 1.The goal: trusted components 2.The EVE environment 3.Technical developments:  3.1 Towards full contracts  3.2 Negative variables & the essence of object- oriented programming  3.3 Language convention for frames  3.4 The alias calculus  3.5 A Calculus of Object Programs 4.Conclusion and assessment Not included: concurrency 4

6. - 1 - Scope & Goals 5

7. Three forms of software development  1. Casual  2. Professional  3. Critical Simple Web sites, spreadsheets, … Enterprise computing, simulation, “soft” real-time, … Transportation, critical infrastructure, “hard” real-time, … Enterprise computing, simulation, “soft” real-time, … 6

8. Language techniques for professional development Dynamic allocation Classes, objects Exception handling Closures (agents) Exceptions Genericity Inheritance Polymorphism, dynamic binding... 7

9. Research context (1): method and language Our work is based on Eiffel:  Method and language for quality-focused development  For professional systems, including very large ones  Continuous, seamless development  ISO standard, significant user base and code base  Libraries  Excellent development environment: EiffelStudio Some advantages:  Built-in, deeply ingrained use of contracts: preconditions, postconditions, class invariants  Open-source, no patent or other proprietary issues  We can shape the future method, language and IDE Java is not a Law of Nature 8

10. - 2 - The EVE environment 9

11. Research context (2): EVE Eiffel Verification Environment  Open source  Developed at ETH, others’ contributions welcome  Continuous integration (weekly) with EiffelStudio  The platform for trying new ideas  All ETH and ITMO contributions included 10

12. Verification As a Matter Of Course Arbiter AutoProof Alias analysis AutoFix Test case generation EVE Test execution Test results Inter. prover Sep. logic prover AutoTest Invariant inference Suggestions 11

13. Scores Failed test: score = -1 Successful test run: 0 < score <= 0.9 Correctness proof: score = 1 May be scaled down if some aspects not taken into account, e.g. arithmetic overflow In practice (AutoProof):  Successful proof: score = 1  Out-of-memory, timeout: score = 0  Failed proof with abstract trace: score = -1 Carlo Furia, Julian Tschannen, Martin Nordio 12

14. Demo 13

15. Combining static and dynamic techniques Static verification: + More modular + Scales up better - Not always feasible - Often tests idealized version of the software - Captures only specified properties Testing: + Generally possible + Can be automated + Tests software as it is + Can integrate non-software parts - Partial (very!) - Captures only specified properties - Not always feasible 14

16. Testing To test a software system is to try to make it fail Fiodor Chaliapine as Mephistopheles “Ich bin der Geist, der stets verneint” Goethe, Faust, Act I 15

17. AutoTest (e.g. IEEE Computer, Sep. 2009) Integral part of EiffelStudio Has already uncovered hundreds of bugs in libraries and other software Three components:  Test generation  Test extraction (from failures)  Manual tests Ilinca Ciupa Andreas Leitner Yi Wei Emmanuel Stapf Arno Fiva Manuel Oriol… 16

18. AutoTest: Test generation  Input: set of classes  Generates instances, calls routines with automatically selected arguments  Oracles are contracts:  Direct precondition violation: skip (precondition satisfaction techniques minimize this)  Postcondition/invariant violation: bug found  Any test (manual or automated) that fails becomes part of the test suite 17

19. 18 Maurice Maeterlinck, La Vie des Abeilles, 1901

20. 19

21. AutoTest: Test generation * SET **** + SET1 + SET2 ++ ++ Test: s1, s2 : SET s2  s1 *: Deferred + : Effective Bernd Schoeller 20

22. AutoTest: Test extraction  Turn a failed execution into a test case 21

23. Who finds what faults? On a small EiffelBase subset, we compared:  AutoTest  Manual testing (students) (3 classes, 2 with bugs seeded)  User reports from the field Largely separate kinds of faults AutoTest: 62% specification, 38% implementation User reports: 36% specification, 64% implementation I.Ciupa, A. Leitner, M.Oriol, A. Pretschner ICST 2008 (best paper) 22

24. CITADEL: Daikon for Eiffel How do programmer-written and inferred contracts compare? Can contract inference be used to improve the quality of programmer-written contracts? Nadia Polikarpova Ilinca Ciupa ISSTA 2009 23

25. CITADEL results  A high proportion of inferred contract clauses are correct (90%) and relevant (64%)  Contract inference does not find all programmer- written contracts (only 59%)  Programmers do not write all inferred contracts (25%)  Contract inference can strengthen programmer- written postconditions and invariants and find missing precondition clauses 24

26. AutoFix: programs that fix themselves 16 faults fixed out of 42 Some of the fixes are exactly the same as those proposed by professional programmers Passing & failing test cases Difference Fix to minimize the difference Fix to minimize the difference Yi Wei, Yu Pei, Andreas Zeller, ISSTA 2010 Yi Wei, Yu Pei, Carlo Furia, ASE 2011 (etc.) 25

27. - 3.1 - Towards complete contracts 26

28. Typical contract: list insertion put_right (v: G) -- Insert v to the right of cursor require index <= count ensure i_th (index + 1) = v count = old count + 1 index = old index end count 1 v -- Previous elements unchanged! index 27

29. Complete contracts Contracts are typically incomplete (unlike those of fully formal approaches such as Z) Our solution:  Use models A model is a mathematical interpretation of the structures Model library: MML (Mathematical Model Library) Fully applicative (no side effects, attributes, assignment etc.) But: expressed in Eiffel (preserving executability) Bernd Schoeller, Tobias Widmer (2008) Nadia Polikarpova (VSTTE 2010) 28

30. Typical contract: list insertion put_right (v: G) -- Insert v to the right of cursor require index <= count ensure i_th (index + 1) = v count = old count + 1 index = old index end count 1 v -- Previous elements unchanged! index 29

31. List insertion with model-based contract note model: sequence, index class LIST [G]... sequence: MML_SEQUENCE [G] put_right (v: G) -- Insert v to the right of cursor. require index <= sequence.count ensure sequence = old (sequence.front (index).extended (x) + sequence.tail (index + 1)) index = old index end... 30

32. Model-based contracts: applications On 7 of the most popular EiffelBase classes Testing found 4 “functional” faults by violation of model-based contracts EiffelBase2: a data structures library with full contracts  Aim is to prove the code against these contracts Now in progress: specifying application libraries (graphics, networking...) 31

33. - 3.2 - Negative Variables & the Essence of Object-Oriented Programming 32

34. O-O analysis, design & programming “Principle of general relativity”: every operation in a class is expressed relative to a “current object” (self, this, Current), known only at execution time class C feature r do x := 1 x. f (...) end... end Need to model this property in the logic 33

35. Simplified denotational rule for routines (unqualified call) (call r (c)) (  ) = r (  r  c]) Notations:  r: body of r  r : list of formal arguments of r  F  v  e] : Substitution of v for e in F (for variable v and expression e; generalized to vectors of variables and expressions)  Distributed dot (used next), for a list v = : x v= 34

36. Classic axiomatic rule for routines (Ignoring recursion) {P} r {Q} {P  r  c]} call r (c) {Q  r  c]} 35

37. Tentative rule for qualified (O-O) calls (Inadequate!) {P and INV} r {Q and INV} {x P  r  c]} call x r (c) {x Q  r  c]} Standard solution (e.g. Peter Müller’s thesis): in r, replace all occurrences of an attribute a by Current. a 36

38. Object-oriented calls call x r (c) x x’x’ Current Target object Negative variables: y Known by the target as x’ y x Current = x Current x = x x’ x = Current x x’ = Current Current’= Current 37

39. Denotational rule for calls Unqualified calls: (call r (c)) (s) = r (s [r : c]) Qualified calls: (call x r (c)) (s) = x call r (x’ c) (s) Then for any property  (such that “ ” distributes over  ):  (call x r (c)) = x  (call r (x’ c)) = x r (s [r : x’ c]) = x (  ( r) [r : x’ c]) 38

40. Adequate Hoare rule for qualified calls Reminder: inadequate rule {P and INV} r {Q and INV} {x P  r  x’ c]} call x r (c) {x Q  r  x’ c]} {P and INV} r {Q and INV} {x P  r  c]} call x r (c) {x Q  r  c]} Proper rule 39

41. - 3.3 - Framing: a language convention 40

42. The frame issue: In a class ACCOUNT: deposit (sum: INTEGER) require... do... ensure balance = old balance + sum end What about other queries other than balance, e.g. owner, account_number, overdraft_limit...? What about descendant classes, e.g. MAFIA_ACCOUNT? Specifying what does not change 41

43. “Modifies” clauses ESC-Java, JML, Spec#: specify what a command can change Theoretical problems:  This can be an infinite set  Requires careful design for inheritance Practical problem: tedious to express Pragmatic observation from survey of JML code:  Every item listed in a modifies clause also appears in the postcondition! 42

44. The proposed language convention A routine may only modify queries listed (outside of an old expression) in its postcondition deposit (sum: INTEGER ) require... do... ensure balance = old balance + sum end This also avoids introducing a special language notation to express that a routine is pure has_penalty = (cur /= currency) ; cur: CURRENCY old involved (is_overdraft) 43

45. - 3.4 - The Alias Calculus 44

46. The question asked by the Alias Calculus Given expressions e and f, and a program location p : Can e and f ever be attached to the same object at p ? Broy volume (IJSI, 2011) 45

47. An example y x   46

48. Why is this important? Alias analysis can be a key tool for proving O-O programs (as an alternative to separation logic) 47

49. Applications of alias analysis 1. Without it, cannot apply standard proof techniques to programs involving pointers 2. Concurrent program analysis, in particular deadlock 3. Program optimization -- y. a = b x. set_a (c) ? a x y set_a (c) b c -- x. a = c -- c = c, i.e. True Understand as x. a := c -- y. a = b 48

50. Alias relations Relation of interest: “In the computation, x might become aliased to y” Definition: Not necessarily transitive: if c then x := y else y := z end A binary relation is an alias relation if it is symmetric and irreflexive Can alias x to y and y to z but not x to z 49

51. Describing an alias relation If r is a relation in E  E, the following is an alias relation: r r  r -1 ― Id [E] Example: {[x, x], [x, y], [y, z]} = Generalized to sets: {x, y, z} = =  Set difference Identity on E Set of binary relations on E; formally: P (E x E) {[x, y], [y, x], [y, z], [z, y]}  {[x, y], [y, x], [x, z], [z, x], [y, z], [z, y]} 50

52. Canonical form and alias diagrams Canonical form of an alias relation: e.g., meaning None of the sets of variables is a subset of another x, y, y, z, x, u, v x u, v y x y, z Make it canonical: x, x, y y {x, y}  { y, z}  {x, u, v} (not canonical) Alias diagram: yy 51

53. Alias diagrams (non-O-O) x u, v y, z x,, y Source node Value nodes In canonical form: no label is subset of another; each label has at least two variables 52

54. Operations on alias relations If a is an alias relation in in and A a set, the following are alias relations: r \– A =r — E x A a / x ={y: E | (y = x)  [x, y]  a} 53  “Quotient”, similar to equivalence class in equivalence relation  “Minus” Set of all variables

55. What the calculus is about The purpose of the calculus is to define, for any instruction p and any alias relation a, the value of a » p which denotes: The aliasing relation resulting from executing p from an initial state in which the aliasing relation is a For an entire program: compute  » p 54

56. Limits of the calculus The calculus is exact But language simplifications cause over-approximation:  Conditional instruction: then p else q end  Loop: loop p end To correct over-approximation: cut instruction 55

57. Basic instructions x, y, … are variables Instructions (p, q, …):  skip  create x  x := y  forget x  (p ; q)  then p else q end -- Eiffel: x := Void -- Java etc.: x = null; 56

58. Basic properties a » skip = a a » (then p else q end ) = (a » p)  (a » q) a » (p ; q)= (a » p) » q a » (forget x) = a \- {x} a » create x = a \- {x} 57

59. The forget rule a » (forget x) = a \- {x} y x,x, y, z x, u, v x, y 58

60. Assignment a » (x := y) =given b = a \- {x} then b  ({x} x (b / y)) end  All pairs of the form [x, y] or [x, u] where u was aliased to y Symmetrize and de-reflect a deprived of all pairs involving x 59

61. Operations on alias relations (reminder) r \– A =r — E x A a / x ={y: E | (y = x)  [x, y]  a}  “Quotient  “Minus” 60

62. Assignment example 1 x u, v x,, y After z := x, z 61

63. Assignment example 2 x u, v x,, y After x := u x, y 62

64. Assignment example 3 x u, v x,, y After x := z x, y x, z x, 63

65. Correcting over-approximations manually  cut x, y Semantics: remove any aliasing between x and y 64

66. Cut example 1 65 x u, v x,, y x After cut x, y

67. Cut example 2 x, y After cut x, u u, v x, x, v 66

68. Cut rule a » cut x, y= a ― x, y 67

69. The role of cut cut x, y informs the alias calculus with non-alias properties that come from other sources Example: if m < n then t := u else t := y end m := m + 1 if m < n then x := t end In fact x cannot be aliased to y (only to u), but the alias theory does not know this property To express it, add the instruction cut x, y; This expression represents check x /= y end (Eiffel) assert x != y ;(JML, Spec#) 68 Alias relation:  t, u, x, t, y, x t, u, t, y

70. Iterations and loops  p n (for integer n): n executions of p (auxiliary notion)  loop p end : any sequence (incl. empty) of executions of p 69

71. Iterations and loops a » p 0 = a a » p n+1 = (a » p n ) » p-- For n  0 a » (loop p end)=  (a » p n ) n  Nn  N 70

72. Loop aliasing theorem a » (loop p end) is also the fixpoint of the sequence t 0 = a t n+1 = t n  (t n » p) Gives a practical way to compute a » (loop p end) 71

73. Routines Routine definitions (one of them designated as main): r (args) do p end Routine call: call r (c) r r Notations:  Body of r:  Formal arguments of r: (args above)  Substitution in an expression F: F [u: v] 72

74. Alias calculus rule for routine call a » call r (c) = a » [r : c]-- Because of recursion, no longer just definition but equation For entire set of routines R, making up a program, this gives a vector equation  a » R= F (a » R) Interpret as fixpoint) equation and solve iteratively r 73

75. Introducing object-oriented constructs  1. Qualified expressions: e f g … Can be used as source (not target!) of assignments x := e f  2. Remote calls: x r  3. Current 74

76. Assignment (original rule) a » (x := y) = given b = a \- {x} then b  ({x} x (b / y) ) end  a deprived of all pairs involving x This includes [x, y] ! All pairs [x, u] where u is either aliased to y in b or y itself All u aliased to y in b, plus y itself 75

77. Assigning a qualified expression x y x x z x does not get aliased to x y! (only to any z that was aliased to x y) x := x y 76

78. Assignment rule revisited a » (x := y) =given b = a \- {x} then b  ({x} x (b / y)) end  a deprived of all pairs involving x or an expression starting with x 77

79. Non-O-O diagrams x u, v y, z x,, y Source node Value nodes Single source node (represents stack) Each value node represents a set of possible run-time values Links: only from source to value nodes (will become more interesting with E4!) Edge label: set of variables; indicates they can all be aliased to each other In canonical form: no label is subset of another; each label has at least two variables 78

80. O-O diagrams := x y x y x x z Links may now exist between value nodes (now called object nodes) Cycles possible (see next) Source node Value nodes Object nodes 79

81. Representing a qualified call with arguments call x r (a, b) With, in a class C: r (t: T ; u: U) The formals mean t: x ’ a u: x ’ b Negated variables x x’x’ a 80

82. The qualified call rule a » call x r (c) = x ((x ’ a) » call r (x ’ c)) Example: c := d call x r (c) with r (u: T) do v := u end x x’x’ c, d Understand as: c := d call with r do v := u end u := x ’ c u, v, x ’ c, x ’ d x u, x v, x r 81

83. Processing a qualified call a » call x r (c) = x ((x ’ a) » call r (c) Alias relation: c, d x ’ c, x ’ d Prefix with x ’ : u, x ’ c, x ’ d c := d call with r do v := u end u := x ’ c x f v, u, x ’ c, x ’ d Prefix with x : x v, x u, c, d x x’x’ c u,, x ’ c, x ’ d v, x x x x c, d Current c x ’ c, x c, x ’ c, x ’ d x d u, v, x x, d 82

84. How to prove a program with references  Compute alias relation up to and including the largest expression involved in the program  Add alias properties to contracts of program  Prove program through usual axiomatic techniques  Prove correctness of cut instructions 83

85. - 3.5 - A Calculus of Object Programs 84

86. The general goal A theory to verify object-oriented programs  Handles references, aliasing  Sound  Mechanizable  Clear  In line with Eiffel’s Design by Contract  In particular, contracts can still be evaluated dynamically (for testing, debugging) 85

87. Reversing a list reverse local previous, next: LINKABLE [G] do from next := first ; previous := Void invariant end first right next ? ? first  right = - old first  right next  right + previous  right = - old first  right until next = Void loop temp := previous previous := next next := next right previous put_right (temp) end first := previous ensure previous 86

88. Components of the solution 1.Compositional logic for programming languages 2.Calculus of object structures 3.Inverse variables 4.Alias calculus 5.The proof 87

89. Compositional logic Compositional logic deals with properties of the form i ; e where i is an instruction and e an expression Meaning: the value of e after executing i Expressed in terms of values of expressions before this execution Examples: (x := 1) ; x= 1 (x := x + 1) ; x= x + 1 88

90. Comparison with other approaches Denotational: State  : State where State = Variable  Value Expressione : State  Valuee.g. e (  ) = 3 Command c : State  State Advantage:defines program as mathematical object Disadvantage:not verification oriented Axiomatic (Hoare): Pre-post:{P} A {Q} Advantage:intended for verification; invariants Disadvantage:not a calculus Axiomatic (Weakest precondition): Operator:A wp Q Advantage:Calculus version of Hoare logic Disadvantage:Boolean expressions only 89

91. A special case If Q is boolean, then i ; Q is the weakest precondition of i for Q 90

92. Hoare-style properties To prove {P } i {Q } prove that P  ( i ; Q ) 91

93. Properties of “;” i ; (j ; e ) = ( i ; j ) ; e Associativity i ; ( x  y ) = ( i ; x )  ( i ; y ) Distributivity -- For most operators  -- Only if e does not involve the old operator (see next) CA CD 92

94. Reminder: function composition Given f : A  B g : B  C their composition f g : A  C is the function a | g (f (a)) 93 f g A B C a Composition is associative: [f g] h = f [g h] f g

95. “;” in non-OO programming Instructions i, j : State  State Expressions e : State  Value Then “ ; ” is the usual composition “”, as in e.g. i ; j (State  State) (State  State), i.e. (State  State) i ; e (State  State) (State  Value), i.e. (State  Value) i ; j ; e -- Using associativity (CA1) 94

96. “;” in object-oriented programming It is again a form of composition, but applied to functions working on the “current object” Instructions i, j : Object  State  State Expressions e : Object  State  Value Then i ; j = o |  | (i (o ) j (o)) (  ) i ; e = o |  | (i (o ) e (o)) (  ) 95

97. The Current rule For any instruction i : i ; Current = Current CUR 96

98. The memory operator For any instruction i and any expression e : i ; old e = e No associativity here; for example ((x := 0 ; x := 1)) ; old x= x but (x := 0) ; ((x := 1) ; old x)= (x := 0) ; x = 0 OLD 97

99. The assignment rule (x e) ; x = e (x e) ; y = y := This rule applies to values of any type, including references, but will be extended for object expressions General convention: x, y, z indicate different variables (values may be the same) A2 A1 98

100. An example proof in compositional logic (item := item + 1) ; (item = old item + 1) By distributivity of ; for =, this is: ((item := item + 1) ; item) = (item := item + 1) ; old item + 1 By the rule of old, this is: ((item := item + 1) ; item) = item + 1 By the assignment rule, this is: item + 1 = item + 1 To be proved: CD OLD A1 99

101. The call rule The unqualified call rule:  Denotational: (call r (c)) (  ) = r (  r  c])  Compositional: (call r (c)) ; e = r  r  c] ; e UC 100

102. The unqualified setter theorem For an attribute a of type T, consider the routine set_a (f: T) do whatever ; a := f end Then (call set_a (c)) ; a = c Proof: this is a direct application of the preceding result (call r (c)) ; e = r  r  c] ; e A more general version of the theorem ( ) applies to any routine with the postcondition a = f Proof: add at the end of the routine an instruction a := f ; this does not change its semantics. Then apply. US1 UC US2 101

103. The alias calculus a » skip = a a » (then i else j end)= (a » i)  (a » j) a » (i ; ))= (a » i) » ) a » (forget x)= a \- {x} a » (create x)= a \- {x} a » (x := y) = a [x: y] a » cut x, y= a – x, y a » p 0 = a a » p n+1 = (a » p n ) » i a » (loop i end)=  (a » p n ) a » call r (  )= (a [ r :  ]) » r a » call x r (  ) = x (x’ (a [x r :  ]) » r) \– x r 102 n  Nn  N Plus: x Current = x Current x = x x’ x = Current x x’ = Current Current’= Current a [x: y] = given b = a\- {x} then b  ({x} x (b/y)) end a purged of expressions starting with x

104. The calculus of object structures: paths Syntax: a path is one of:  Empty, written <>  a, where a is the name of an attribute  a p, where p is (recursively) a path Semantics: x y z … denotes the object obtained from the current object by following the link corresponding to x, then the link for y, then the link for z etc. (If from any object in this sequence the next link is not defined, that object is the value of the path.) x y z Current x y z 103

105. Compositional semantics for O-O programs Reminder for variables and expressions of non-ref types: (x e) ; y = y (x e) ; x = e := A2 A1 They still hold, but we need to include the effect on paths: (x e) ; x p = e p := A3 -- If x is cycle-free for e before p (see next) (x e) ; y p = y p := A4 -- If x is cycle-free for e before p Special case 104

106. The cycle-free condition holds under the following condition: no prefix of p is of the form q x where e q may be aliased to Current (“x is cycle-free for e before p”) This condition holds in particular if the structure is acyclic y (x e) ; x p = e p := x Counter-example: (x := y ) ; x z x z Current O2 O1 p  In final state: x z x is attached to O2 But in initial state: e p, i.e. y z x, is attached to O1 e A3 105

107. Sequence closure  b denotes the sequence of objects Current, b, b b, b b b, … stopping at the first from which the a link either is void or leads to an object already encountered Generalization: if p is a path, p  b denotes the sequence p, p b, p b b, p b b b, … right  right right 106

108. List reversal: expressing the invariant - previous  right + next  right ~ old  right previousnext 123 45 right 107

109. Reversing a list reverse local previous, next: LINKABLE [G] do from next := first ; previous := Void invariant end first right next ? ? - first  right = old first  right - previous  right + next  right = old first  right until next = Void loop temp := previous previous := next next := next right previous put_right (temp) end first := previous ensure previous - previous  right + next  right 108

110. Acyclic attributes In a class C, an attribute a : C is acyclic if no element of  a may be aliased to Current 109

111. The closure theorem  x = + x  x Proof: from definition of  No particular condition on x (e.g. x does not have to be acyclic) More generally: p  x = p + p x  x x x x x Current Sequence concatenation One-element sequence SC1 SC2 110

112. Assignment and sequence closure (1) Theorem: (x := e) ; x p  a = e p  a (also applicable if a is x, and if the path p is empty) Proof: since the two sides are sequences, it suffices to prove that elements of the sequences are pairwise equal. The individual equalities to prove are (x := e) ; x p a n = e p a n where a n is a a … a (n times), for a finite number of values of n starting at 0. They follow from which is applicable since by the definition of  every a n path is acyclic. (q in this equality is p a n.) AS1 (x e) ; x q = e q := A3 111

113. Assignment and sequence closure (2) Theorem: (x := e) ;  x = + e  x Proof: apply successively  The closure theorem:  x = + x  x  Distributivity  The Current theorem : (x := e) ; =  The preceding theorem: (x := e) ; x  x = e  x AS2 CUR CD SC1 AS1 112

114. The qualified setter theorem Consider set_a (f: T) with the postcondition a = f Unqualified setter theorem (reminder): (call set_a (c)) ; a = c QS US2 Qualified setter theorem: (call x set_a (c)) ; x a = c 113

115. Remote assignment and sequence closure Reminder: (x := e) ;  x = + e  x AS2 Qualified closure assignment theorem: (call x set_a (c )) ; x  a = + c  a QC Proof: (call x set_a (c )) ; x  a = + (call x set_a (c )) ; x a  a (call x set_a (c )) ; x = x (call x set_a (c )) ; x a  a = c  a SC2 AS1 114

116. Reminders p  x = p + p x  x (x := e) ; x p  a = e p  a SC2 AS1 115

117. The Proof 116

118. Reversing a list reverse local previous, next: LINKABLE [G] do from next := first ; previous := Void invariant end first right next ? - first  right = old first  right until next = Void loop temp := previous previous := next next := next right previous put_right (temp) end first := previous ensure previous - previous  right + next  right 117

119. The invariant - previous  right + next  right temp := previous previous := next next := next right previous put_right (temp) - previous  right + next  right 118

120. Proof illustration 119

121. Handling previous  right temp := previous previous := next next := next right previous put_right (temp) previous  right - previous  right + next  right 120

122. Handling previous  right temp := previous previous := next next := next right previous put_right (temp) + temp  right previous  right - previous  right + next  right 121

123. Handling previous  right temp := previous previous := next next := next right previous put_right (temp) + temp  right previous  right - previous  right + next  right 122

124. Handling previous  right temp := previous previous := next next := next right previous put_right (temp) + temp  right previous  right - previous  right + next  right 123

125. Handling previous  right temp := previous previous := next next := next right previous put_right (temp) + temp  right + previous  right previous  right - previous  right + next  right 124

126. Handling next  right temp := previous previous := next next := next right previous put_right (temp) next  right - previous  right + next  right 125

127. Handling next  right temp := previous previous := next next := next right previous put_right (temp) next  right - previous  right + next  right 126

128. Handling next  right temp := previous previous := next next := next right previous put_right (temp) next  right next right  right next  right - previous  right + next  right 127

129. Handling next  right temp := previous previous := next next := next right previous put_right (temp) next  right next right  right next  right next right  right - previous  right + next  right 128

130. Handling next  right temp := previous previous := next next := next right previous put_right (temp) next  right next right  right next  right next right  right - previous  right + next  right 129

131. Putting the two pieces together temp := previous previous := next next := next right previous put_right (temp) next right  right + previous  right + – - previous  right + next  right 130

132. Putting the two pieces together temp := previous previous := next next := next right previous put_right (temp) next right  right – previous  right + + = next right  right + previous  right + – next  right – previous  right + = - previous  right + next  right 131

133. Assessment Limitations:  Not implemented  Needs more examples  Does not yet handle inheritance  No proof of soundness Pros:  Minimum annotation effort  High-level (uses contracts of routines)  Adapted to modern programming style  Handles aliasing automatically  Reflects how O-O programmers think about programs 132

134. - 5 - Conclusion 133

135. Verification As a Matter Of Course 134