Towards a VSTTE Research Roadmap for Enhanced Languages and Methods

1
Towards a VSTTEResearch Roadmap for Enhanced
Languages and Methods

• Gary T. Leavens and committeeSupport from US NSF
  grants CCF-0428078 and CCF-0429567April 1, 2006

2
Summary and Conclusions

• JML is the solution!

3
April Fools!

• Seriously now

4
Background

• Hoares verifying compiler grand challenge
  (JACM, Jan. 2003)
• check correctness of programs
• specified by types, assertions, and other
  redundant annotations
• VSTTE workshop, Oct. 2005.
• Hoare (Misra and Shankar) chose leaders
• Charged them to form groups
• To write research roadmaps

5
Problem

• How can
• the grand challenge
• and
• specification languages,
• program generation,
• verification by construction, and
• programming languages
• help each other?

6
Common Theme Verifiable Artifacts

• Dont just verify a bare program
• Specify interesting properties
• Add information from generationor refinement
  process
• Support verification in programming languages
• E.g., not
• C code and no specification
• Java code with a few preconditions

7
Why Enhancements?

• Fundamental reasons
• Need interesting specificationsfor verification
  to be interesting
• Verification arbitrarily difficultfor arbitrary
  specification program

8
Spectrum of Properties
No deadlock

FunctionalBehavior
No crash
No Exceptions
No type errors
Preconditionshold
9
Caveats

• Group chosen by me
• Biased towards VSTTE attendees, etc.
• Intentionally small
• No official standing
• Only focused on the 4 areas

10
Common Need Delineation of Scope

• Properties and languages of interest
• Challenge problems

11
Specifying Verification Problems

• Precisely
• Verification problem
• (Specification language, Programming
  language)
• Several such pairs may be of interest
• At least need constraints on such pairs

12
Challenge Problems

• Needed especially in the short term
• Various sizes
• Must have
• Requirements
• Formal specification of properties of interest
• Helpful
• Implementation
• Test cases

13
Why Challenge Problems NeededNot These Million
Lines

• assert k 0
• k k 1
• assert k 1
• k k 2
• assert k (23)/2
• //
• k k 1000000
• assert k (10000001000001)/2

14
Proof that sum(1..n) n(n1)/2

• base case n 1 12/2 1 sum(1..1)
• inductive suppose sum(1..n) n(n1)/2.
• sum(1..n1)
• sum(1..n) n1
• (n(n1)/2) n1
• ((nnn2n2)/2)
• (n1)(n11)/2

15
Challenge ProblemsAre Not Enough

• Specifying class of verification problems by
  example
• Makes researchers inferwhat is really of
  interest
• Hypocritical

16
Common Goals

• Short-termextensible languages and tools
• Long-termunification of diverse approaches

17
Subtopics within Enhanced Languages and Methods

• Specification languages
• Describes properties (what)
• Program generation
• Synthesize implementations automatically
• May be domain specific
• Verification by construction approach
• Refinement techniques
• Non-automatic methods for synthesis
• Programming language design
• Describes algorithms and data (how)

18
Specification Languages

• Kathi Fisler (WPI)
• Cliff Jones (Newcastle)
• Murali Sitaraman (Clemson)

19
Specification LanguagesShort Term Research
Directions

• Open languages and tools(foster experimentation)
• Tools to reason about partial specifications
• Refinement(tools to help debug and prove)
• Modular description of components(helps describe
  larger systems)
• Specify resources(e.g., time, space)

20
Interface SpecificationShort Term Research
Directions

• Translate programming-style assertions(e.g., for
  theorem provers)
• Heap structuring(e.g., ownership)
• Inference with user-specified abstractions(helps
  describe larger systems)
• New language paradigms?(e.g., aspect-oriented
  programming)

21
Specification LanguagesLong Term Research
Directions

• Specify both data and control(transitions over
  relations? atomicity?)
• Traceability to requirements
• Tool frameworks to support integration
• Theory of interface specification language
  design(faster language design)

22
Program Generation

• Don Batory (U. Texas, Austin)
• Alessandro Coglio (Kestrel)
• Douglas R. Smith (Kestrel)

23
Program Generation Short Term Research
Directions

• Formalizing language semantics
• Tools that work with semantics and proofs
• Certified code generation(produce certificate)
• Catalog of transformation patterns(easier to
  implement new generators)
• Better algorithms for analysis and constraint
  solving

24
Program GenerationLong Term Research Directions

• Taxonomy of transformations(in various
  dimensions)
• Better languages, tools, frameworks(Refine or
  Stratego-like?)
• Factoring out what remains to test
• Allow update of running systems(so can apply to
  embedded systems)
• Better user control(some manual control
  possible?)

25
Verification by Construction (VxC) Approach

• Michael J. Butler (Southampton)
• Cliff Jones (Newcastle)
• Eric Hehner (Toronto)
• Jean-Raymond Abrial (ETH)

26
VxC ApproachShort Term Research Directions

• Document a range of case studies(e.g.,
  distributed and control systems)
• Extend links between existing tools(powerful
  theorem proving, inference)
• Generate ancillary properties(for generated
  code, to aid checking)

27
VxC ApproachLong Term Research Directions

• Support for program evolution(modularity of
  refinement steps?)
• Complex system design(better abstractions?
  decompositions?)
• Richer refinement theories
• Refinement patterns(which may still require
  further proof)
• Unified tool frameworks(integrate different
  theories)

28
Programming Languages

• Simon Peyton-Jones (MSR)
• Aaron Stump (Wash. U. St. Louis)
• Dale Miller (INRIA-Futurs, Polytechnique)

29
Programming Languages View

• Goal increase confidence
• Existing approaches
• Type systems
• Program analysis
• Assertions
• Testing
• Problems
• Need lots of effort
• Lack of extensibility

30
Programming LanguagesShort Term Research
Directions

• Open extensible specification annotations
• Eliminate the common/easy errors(dangling
  pointers, null dereference, )

31
Programming LanguagesLong Term Research
Directions

• Integrate verification tools and
  languages(Eclipse-like?)
• More integration of types and specifications
  (sweet spots between them?)
• Integration of rich static checking(logical
  frameworks?)

32
Conclusions

• Spectrum of specifications no crashes ? full
  functional specifications
• Common needdelination of scope
• Common short-term goalextensible languages and
  tools
• Common long-term goalunification of diverse
  approaches