Challenges in increasing tool support for programming

1
Challenges in increasing tool support for
programming

• K. Rustan M. LeinoMicrosoft Research, Redmond,
  WA, USA

joint work with Mike Barnett, Bor-Yuh Evan Chang,
Robert DeLine, Manuel Fähndrich, Peter Müller,
David A. Naumann, Wolfram Schulte, andHerman
Venter
23 Sep 2004ICTACGuiyang, Guizhou, PRC
2
Software engineering problem

• Building and maintaining large systems that are
  correct

3
Approach

• Specifications record design decisions
• bridge intent and code
• Tools amplify human effort
• manage details
• find inconsistencies
• ensure quality

4
Spec demo
5
Challenge areas

• 0. Program verification
• 1. A better language
• 2. Methodology

6
0. Program verification
an extreme form ofmanaging the details
7
Basic architecture of a verifier
program with specifications
verification conditiongenerator
verification condition
theorem prover
correct or list of errors
8
Generating verification conditions
Weakest preconditions

• int AbsX(Robot c) requires c ? null ensures 0
  result if (0 c.x) a c.x else
  a -c.x return a

c ? null ? c ? null ? (0 c.x ? c ? null ? 0
sel(c,x)) ? ((0 c.x) ? c ? null ? 0
-sel(c,x))
c ? null ? (0 c.x ? c ? null ? 0 sel(c,x))
?((0 c.x) ? c ? null ? 0 -sel(c,x))
c ? null ? 0 sel(c,x)
c ? null ? 0 -sel(c,x)
0 a
0 result
9
Analyzing verification conditions

• Automatic theorem prover
• can be hidden from programmer
• generates counterexamples
• Interactive theorem prover
• requires gurus
• not limited by built-in decision procedures

10
Theory opportunities

• Developing good encodings of verification
  conditions
• Combining inference techniques for different
  domains
• Combining inference and proving

11
Spec verifier architecture
Spec
Spec compiler
MSIL (bytecode)
Boogie
translator
inference engine
Boogie PL
V.C. generator
verification condition
automatictheorem prover
correct or list of errors
12
1. A better language

• the programming languageis the software
  engineer'sprimary thinking and working tool

13
Designing more rigor into the language
Examples

• Type system
• impose coarse-grained restrictions
• easy to understand and use
• sound efficient checking
• General specifications
• enforce by mix of dynamic and static checking
• dont worry about completeness or decidability
• Develop good defaults

non-null types
requires Premodifies Frameensures Post
requires this.Validmodifies this.ensures
true
14
Enforcing specifications

• Dynamic checking
• may leave out expensive checks, if not required
  for soundness
• example modifies clauses
• Static checking
• requires more effort from the user
• example modifies clauses
• modular checking a necessity

15
Language design problem example

• procedure P (Robot c)
• int a c.x

error possible null dereference
16
Language design problem example

• procedure P (Robot c)
• Robot d new Robot()int a d.x
• if (c ? null) a c.x
• if (c.f ? null)
• a sqrt(a) OpenFile(b.txt) c.M()

a c.f.g
error?
17
Migration problems

• To the new language
• how does the language compare to existing ones?
• From (!) the new language
• development organizations may have process
  requirements

18
2. Programming methodology
light-weight rules forsimpler reasoning
19
Pre/post are not enough

• class C
• private int x
• private int y
• public void Update(int z) requires 0 z x
  y T a new Tz T b new Ty
  x

20
Object invariants

• class C
• private int x
• private int y
• invariant x y
• public void Update(int z) requires 0 z T
  a new Tz T b new Ty x

21
The reentrance problem

• class C
• int x
• int y
• invariant x y
• public void M()
• x P() y

invariant assumedto hold on entry
invariant may betemporarily broken here
what if P calls back into M?
invariant is restored here
invariant checkedto hold on exit
22
The reentrance solution

• class C
• int x
• int y
• invariant x ypublic void M()
• requires this.inv Valid
• expose (this) x P() y

represent explicitlythat invariant
holds (without revealingwhat the invariant is)
change this.invfrom Valid to Mutable
field updates allowedonly on Mutable objects
check invariantthen, change this.invfrom
Mutable to Valid
23
The abstraction problem

• class Set
• Hashtable h
• invariant h ? nullpublic void Add(Element e)
• requires this.inv Valid
• expose (this)
• h.Add(e, e)
• class Hashtable
• public void Add(object o) requires this.inv
  Valid

how do we know h is Valid here?
24
The abstraction solution

• class Set
• owned Hashtable h
• invariant h ? nullpublic void Add(Element e)
• requires this.inv Valid
• expose (this)
• h.Add(e, e)
• class Hashtable
• public void Add(object o) requires this.inv
  Valid

• set uniquely owns set.h
• set.invValid implies set.h.invValid

ownership temporarilyrelinquished here
ownership re-obtained here
25
Wanted methodology for

• advanced invariants
• multiple owners
• delegates (closures)
• events

26
Conclusions

• Because of tool support, were ready for
  programming at the next level of rigor
• Still requires theory support
• language design
• program semantics
• specification techniques
• inference algorithms
• decision procedures
• Methodology is underdeveloped
• Can programming theory yet fully explain why
  real big programs work?
• programming theory has not kept up with practice

Some papers at http//research.microsoft.com/lein
o