The Spec

1
The Spec programming system

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

joint work withMike Barnett, Robert DeLine,
Manuel Fähndrich, Wolfram Schulte, Herman
Venter, Francesco Logozzo, Peter Müller, David A.
Naumann, Bor-Yuh Evan Chang, Bart Jacobs,
Xinming Ou, and Qi Sun
18 May 2005Software Quality Research Laboratory
distinguished lectureMcMaster UniversityHamilton
, ON, Canada
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

• Experimental mix of contracts and tool support
• Aimed at experienced developers who know the high
  cost of testing and maintenance
• Superset of C
• non-null types
• pre- and postconditions
• object invariants
• Tool support
• more type checking
• compiler-emitted run-time checks
• static program verification

contracts everywhere
C
into the future
type checking
static verification
run-time checks
degree of checking,effort
5
Spec demo
6
Challenge areas

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

7
0. Program verification
an extreme form ofmanaging the details
8
Basic architecture of a verifier
program with specifications
verification conditiongenerator
verification condition
theorem prover
correct or list of errors
9
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 sel(c,x) ? c ? null
? 0 sel(c,x)) ? ((0 sel(c,x)) ? c ? null ?
0 -sel(c,x))
c ? null ? (0 sel(c,x) ? c ? null ? 0
sel(c,x)) ?((0 sel(c,x)) ? c ? null ? 0
-sel(c,x))
c ? null ? 0 sel(c,x)
c ? null ? 0 -sel(c,x)
0 a
0 result
10
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

11
Research opportunities

• Develop good encodings of verification conditions
• Combine inference techniques for different
  domains
• Combine inference and proving

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

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

14
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.inv Validmodifies
this.ensures true
15
Enforcing specifications

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

type checking
static verification
run-time checks
degree of checking,effort
16
Migration problems

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

contracts everywhere
C
into the future
17
2. Programming methodology
light-weight rules forsimpler reasoning
18
Objects have invariants

• class C
• private int xprivate int y
• public void M() int t 100 / (y x) x
  x 1 P(t) y y 1

division by zero
19
Pre/post are not enough

• class C
• private int xprivate int y
• public void M() requires x lt y int t 100
  / (y x) x x 1 P(t) y y 1

20
Object invariants

• class C
• private int xprivate int y
• invariant x lt y
• public void M() int t 100 / (y x) x
  x 1 P(t) y y 1

21
When do object invariants hold?

• class C
• private int xprivate int y
• invariant x lt y
• public C() x 0 y 1
• public void M() int t 100 / (y x) x
  x 1 P(t) y y 1

invariant checked to holdat end of constructor
invariant assumed to holdon entry to method
invariant may betemporarily broken here
what if P calls back into M?
invariant is restored here
invariant checked to holdon exit from method
22
Object states

• Mutable
• Object invariant may not hold
• Field updates allowed
• Valid
• Object invariant holds
• Field updates not allowed

23
Valid vs. mutable objects

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

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
24
Aggregate objects

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

how do we know h is Valid here?
25
Aggregate objects

• class Set
• Hashtable h
• invariant public void Add(Element e)
• requires this.inv Valid
• expose (this)
• h.Add(e, e)
• public Hashtable Leak() return h
• class Hashtable
• invariant
• public void Add(object key, object
  val) requires this.inv Valid

how do we know h is Valid here?
Perhaps it isnt! void Violation(Set
s) requires s.inv Valid Hashtable g
s.Leak() expose (g) g.x
s.Add()
26
Object states

• Mutable
• Object invariant may not hold
• Field updates allowed
• Valid
• Object invariant holds
• Field updates not allowed
• Committed
• Valid and owned
• Cannot be exposedowner must be exposed first,
  which makes this object Valid

27
Ownership

• For any s Set,
• s uniquely owns s.h
• validity of s implies validity of s.h

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

ownership of htemporarilyrelinquished here
ownership of hre-obtained here
28
Object states a picture of the heap
expose (s)
s Set
ownership
h
Mutable
Hashtable
Valid
Committed
29
Object states a picture of the heap
expose (s)
s Set
ownership
h
Mutable
Hashtable
Valid
Committed
30
Object states a picture of the heap
expose (s)
s Set
ownership
h
Mutable
Hashtable
Valid
Committed
31
Object states a picture of the heap
expose (s)
s Set
ownership
h
Mutable
Hashtable
Valid
Committed
32
Summary of object invariants

• invariant
• owned T f
• inv Mutable, Valid, Committed
• expose
• updates of o.f require o.inv Mutable
• Inv (o) can mention only the fields of o and the
  fields of owned fields
• example invariant this.n this.h.Count
• (?o ? o.inv Mutable ? Inv (o))
• (?o ? o.inv Mutable ? o.f.inv Committed)

33
Wanted methodology for

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

34
Conclusions

• Because of tool support, were ready for
  programming at the next level of rigor
• Some ingredients
• 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

http//research.microsoft.com/leino
download Specfrom here
http//research.microsoft.com/specsharp