Technologies for finding errors in objectoriented software - PowerPoint PPT Presentation

1 / 35
About This Presentation
Title:

Technologies for finding errors in objectoriented software

Description:

Technologies for finding errors in objectoriented software – PowerPoint PPT presentation

Number of Views:64
Avg rating:3.0/5.0
Slides: 36
Provided by: Rustan5
Category:

less

Transcript and Presenter's Notes

Title: Technologies for finding errors in objectoriented software


1
Technologies for finding errorsin
object-oriented software
  • K. Rustan M. LeinoMicrosoft Research, Redmond, WA

Lecture 3Summer school on Formal Models of
Software5 Sep 2003, Tunis, Tunisia
2
Review An object-oriented programming notation
  • C w E
  • assert P
  • var w in C end
  • C0 C1
  • if P then C0 else C1 end
  • o.f E
  • x new(T)
  • w o.m(E0, E1)

3
Invariants straw man
Object invariants hold on public method
boundaries and are shorthands for
pre/post-conditions
  • class T // field declarations ...
  • invariant J
  • T(...) requires P modifies v ensures
    Q
  • method m(...) requires R modifies
    w ensures T

class T // field declarations
... T(...) requires P modifies v ensures
Q ? J method m(...) requires R ? J
modifies w ensures T ? J
4
Invariants, example
  • class T
  • private int x, y invariant 0 ? x lt y
  • public T() x 0 y 1
  • public method m() modifies x, y assert
    y-x ? 0 x x 3 y 4 y

class T private int x, y public
T() ensures 0 ? x lt y x 0 y 1
public method m() requires 0 ? x lt y
modifies x, y ensures 0 ? x lt y
assert y-x ? 0 x x 3 y 4
y
5
Invariants, problems
  • class T
  • private int x, y invariant 0 ? x lt y
  • public T() x 0 y 1
  • public method m() modifies x, y assert
    y-x ? 0 x x 3 y 4 y

class T private int x, y public
T() ensures 0 ? x lt y x 0 y 1
public method m() requires 0 ? x lt y
modifies x, y ensures 0 ? x lt y
assert y-x ? 0 x x 3 y 4
y
callers are expected to establish property about
internal data structure
6
Invariants, problems
  • class T
  • private int x, y invariant 0 ? x lt y
  • public T() x 0 y 1
  • public method m() modifies x, y assert
    y-x ? 0 x x 3 y 4 y

class T private int x, y public
T() ensures 0 ? x lt y x 0 y 1
public method m() requires 0 ? x lt y
modifies x, y ensures 0 ? x lt y
assert y-x ? 0 x x 3 y 4
y
possible solution (?) callers dont need to be
checked for this preconditionit holds
automatically!
7
Invariants, problems
  • class T
  • private int x, y invariant 0 ? x lt y
  • public T() x 0 y 1
  • public method m() modifies x, y assert
    y-x ? 0 x x 3 y 4 y

class T private int x, y public
T() ensures 0 ? x lt y x 0 y 1
public method m() requires 0 ? x lt y
modifies x, y ensures 0 ? x lt y
assert y-x ? 0 x x 3 y 4
y
invariant does not hold here
8
Invariants, problems
  • class T
  • private int x, y invariant 0 ? x lt y
  • public T() x 0 y 1
  • public method m() modifies x, y assert
    y-x ? 0 x x 3 y 4 y

class T private int x, y public
T() ensures 0 ? x lt y x 0 y 1
public method m() requires 0 ? x lt y
modifies x, y ensures 0 ? x lt y
assert y-x ? 0 x x 3 p(...)
y 4 y
invariant does not hold here, so what if p calls
m?!
9
The problem of specifying modifications
  • class Kitchen private Dishes d private bool
    hasGarbage private Stove s private Light l
    ...
  • public method SpiffUp() modifies
    hasGarbage, s.foodPieces, s.big.sufaceColor,
    d.Clean() hasGarbage false
    s.Wipe() l.TurnOff() ...

class Stove private Burner big private
Burner small private int foodPieces private
Knob knobs ... public method
Wipe() modifies foodPieces,
big.surfaceColor, big.Polish()
small.Polish() foodPieces 0 ...
these lists are long, and they mention private
state
10
The problem of specifying modifications
  • class Kitchen private Dishes d private bool
    hasGarbage private Stove s private Light l
    ...
  • public method SpiffUp() modifies
    hasGarbage, s.foodPieces, s.big.sufaceColor,
    d.Clean() hasGarbage false
    s.Wipe() l.TurnOff() ...

class Stove private Burner big private
Burner small private int foodPieces private
Knob knobs ... public method
Wipe() modifies foodPieces,
big.surfaceColor, big.Polish()
small.Polish() foodPieces 0 ...
possible solution (?) dont need to declare
modifications of private stateit cant be
observed anyhow
11
The problem of specifying modifications
  • class Kitchen private Dishes d private bool
    hasGarbage private Stove s private Light l
    ...
  • public method SpiffUp() modifies
    d.Clean() hasGarbage false
    s.Wipe() assert ?hasGarbage
    l.TurnOff() ...

class Stove private Burner big private
Burner small private int foodPieces private
Knob knobs ... public method
Wipe() modifies big.Polish()
small.Polish() foodPieces 0 ...
SpiffUp treats Wipe as if Wipe modified nothing,
so what if Wipe calls a method in Kitchen that
sets hasGarbage to true?!
12
Soundness of verification
  • Soundness verification finds all errors
  • Soundness follows from
  • pre- and postconditions are the same for caller
    and callee
  • Note In addition to soundness, we want
    something usable

13
Methodology
  • object invariant declaration
  • class T int x, y invariant x lt y
  • special variable st Invalid, Valid
  • Idea program invariant (?o ? o.st Invalid
    ? Inv(o))
  • st is changed by commands pack and unpack

for any o T, we writeInv(o) o.x lt o.y
holds at everyprogram point!
14
pack and unpack
  • pack o assert o.st Invalid assert
    Inv(o) o.st Valid
  • unpack o assert o.st Valid o.st
    Invalid

15
Example
receiver parameter(this, self, current)
  • class T int x, y invariant 0 ? x lt y
  • method init(t)? requires t.st
    Invalid modifies t.st, t.x, t.y ensures t.st
    Valid t.x 0 t.y 1 pack t
  • method m(t) requires t.st Valid modifies
    t.x, t.y unpack t t.x t.x 3 t.y
    4 t.y pack t

16
Program invariant
  • (?o ? o.st Invalid ? Inv(o))
  • x new(T) ... assume x.st Invalid
  • pack o ... assert Inv(o) o.st Valid
  • unpack o ... o.st Invalid
  • o.f E assert o.st Invalid ...
  • Inv(o) can mention only the fields of o

17
Methodology, summary
  • invariant ...
  • st Invalid, Valid
  • pack, unpack
  • modifications of o.f require o.stInvalid
  • Inv(o) can mention only the fields of o
  • (?o ? o.st Invalid ? Inv(o))

18
Methodology, extended
  • component declarations
  • class Kitchen component Stove s
  • st Invalid, Valid, Committed
  • Idea program invariant (?o ? o.stInvalid ?
    (Inv(o) ? (?p?Comp(o) ?
    p.stCommitted)))
  • pack o and unpack o change st for o and
    o's components

for any k Kitchen, we havek.s ? Comp(k)
19
pack and unpack, extended
  • pack o assert o.st Invalid ? Inv(o)
    assert (?p ? Comp(o) ? p.stValid) o.st
    Valid change st such that (?p ? (p ?
    Comp(o) ? p.stCommitted) ? (p ? Comp(o)
    ? p.stp.st0))
  • unpack o assert o.st Valid change st
    such that (?p ? (p ? Comp(o) ? p.stValid)
    ? (p ? Comp(o) ? p.stp.st0)) o.st
    Invalid

/
/
20
Example
class Stove method Wipe(s) requires
s.stValid
  • class Kitchen method SpiffUp(k) requires
    k.stValid unpack k k.d.Clean()
    k.s.Wipe() pack k

Committed
Committed
Dishes
Committed
Committed
Stove
s
d
Committed
k
Kitchen
Valid
21
Example
class Stove method Wipe(s) requires
s.stValid
  • class Kitchen method SpiffUp(k) requires
    k.stValid unpack k k.d.Clean()
    k.s.Wipe() pack k

Committed
Committed
Dishes
Committed
Committed
Valid
Stove
s
d
Committed
Valid
k
Kitchen
Valid
Invalid
22
Program invariant
  • (?o ? o.stInvalid ? (Inv(o) ? (?p?Comp(o) ?
    p.stCommitted)))
  • x new(T) ... assume x.stInvalid
  • pack o, unpack o
  • o.f E assert o.stInvalid ...
  • Inv(o) can mention only the fields of o andof
    o.p for any component field p

23
Extended methodology, summary
  • invariant ...
  • component ...
  • st Invalid, Valid, Committed
  • pack, unpack
  • modifications of o.f require o.stInvalid
  • Inv(o) can mention only the fields of o and of
    o.p for any component field p
  • (?o ? o.stInvalid ? (Inv(o) ? (?p?Comp(o) ?
    p.stCommitted)))

24
Verification system
  • We let st be used in method specifications
    (requires, modifies, ensures)
  • We must address the Problem of Specifying
    Modifications

25
An alternative heap model
  • class T f U g V ...
  • In my previous lecture
  • many one-dimensional map variables (one per
    field)
  • x o.f x fo x select(f, o)
  • o.f E fo E f store(f, o, E)
  • Now
  • one two-dimensional map variable
  • x o.f x Heapo, f x select(Heap,
    o, f)
  • o.f E Heapo, f E Heap
    store(Heap, o, f, E)

26
Meaning of modifies
viewed as set of object/field-name pairs
  • modifies w modifies Heap ensures
    (?o,f ? Heapo,f Heap0o,f
    ? (o,f) ? w0 )

27
Meaning of modifies
  • modifies w modifies Heap ensures
    (?o,f ? Heapo,f Heap0o,f ? (o,f) ? w0
    ? ?Heap0o,alloc )

28
Meaning of modifies
  • modifies w modifies Heap ensures
    (?o,f ? Heapo,f Heap0o,f ? (o,f) ? w0
    ? ?Heap0o,alloc ? Heap0o,stCommitted )

29
Example
class Stove method Wipe(s) requires
s.stValid modifies s.foodPieces
  • class Kitchen method SpiffUp(k) requires
    k.stValid modifies k.hasGarbage unpack k
    k.d.Clean() k.hasGarbage false
    k.s.Wipe() assert ?k.hasGarbage pack
    k

30
Another example
  • method m(p) requires p.stCommitted var y, z
    in y p.x z sqrt(49) assert y
    p.x end

31
Yet another example
method m(p) requires p.stCommitted p.x
p.x 1
Is this field update allowed?
32
Soundness
  • Pre- and postconditions are the same for callers
    and callees, so verification system is sound!

33
Methodology conclusions
  • Invariants different from pre/post-conditions
  • Resulting program invariants hold at every
    program point
  • Uses pack/unpack commands, but good defaults can
    be constructed for these
  • No linear-type system
  • Components are not unique referencesobjects
    (pointers) can freely be copied
  • Fields can freely be read
  • No additional features of abstraction needed to
    support the specification of modifications
  • Sound

?
For more details, see Barnett, DeLine, Fahndrich,
Leino, Schulte, 2003 (reference 65 in my
lecture-notes bibliography).
34
Research challenges
  • experience, understanding of limits
  • extensions to support more good programs

35
Summary of lectures
  • Automatic high-precision programming tools can be
    built for object-oriented languages
  • need more research to explore other design
    trade-offs
  • Semantics of programming languages (including
    object-oriented languages) can be defined from
    the semantics of simple commands
  • Object-oriented programming requires methodology
  • needs further research

See lecture notes for selected bibliographic
references. http//research.microsoft.com/leino
Write a Comment
User Comments (0)
About PowerShow.com