Download presentation

Presentation is loading. Please wait.

Published byKayley Parrett Modified about 1 year ago

1

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 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

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
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
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
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
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
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

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 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

Similar presentations

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google