Basics of Formal Methods: Proof Obligations

1
Basics of Formal Methods Proof Obligations

• Explain the purpose of refinement
• Refine simple models
• Show why proof obligations are needed

2
VDM Development Process
Data types variables
High-level types (e.g. sets, sequences)
Analyse
Requirements Statement
VDM-speak Make more real
3
Modelling a scheduler

• Formally specify behaviour of part of the
  run-time system that manages threads
• Why?
• To check the design works
• To make sure we understand whats needed
• To reduce bugs in the implementation
• We will look at the overall system
• Then consider a small part
• To llustrate ideas
• To introduce proof obligations

4
The Overall System
finished
running
blocked
created
ready
5
Modelling a scheduler

• Data model
• Model of scheduler data structures
• Operations
• Moving threads between states
• Scheduler data model includes
• A running thread
• How should this be modelled?
• Variable of type Thread?
• Set of Thread?
• Ready threads
• How should this be modelled?

Ensures only one running thread. Can it handle no
active thread?
Handles multiprocessor Handles no thread Risk of
adding threads by mistake needs constraint
6
Defining a collection of threads

• Data Model
• The best datatype to model a thread collection?
• A set why?
• A sequence why?
• Collection set of Thread
• Leave Thread undefined
• Operations
• What do we want to do to a Collection?
• Define VDM operations to model these

Items only occur once? Are items ordered
7
Collection Operations

• Operations
• addThread
• removeThread
• .
• What do we need to define for each?
• Parameters
• External variables
• Pre-conditions
• Post-conditions
• Exceptions

8
addThread

• Add a thread to the collection
• addThread (t Thread)
• Ext wr coll Collection
• Pre true
• Post coll coll ? t

Initial State
Final State
Parameter to operation
If addThread had a result, that would also be a
parameter to Post-addThread. Why?
9
removeThread 1

• Is the following ok?
• removeThread () t Thread
• Ext wr coll Collection
• Pre true
• Post coll coll - t ? t ? coll

10
removeThread 2

• Is the following ok?
• removeThread () t Thread
• Ext wr coll Collection
• Pre coll ?
• Post coll coll ? t
• Errs EMPTYCOLLECTION coll ? coll

What is this?
11
removeThread 3

• Is the following ok?
• removeThread () t Thread
• Ext wr coll Collection
• Pre coll ?
• Post coll coll - t ? t ? coll
• Errs EMPTYCOLLECTION coll ? coll

12
Is the specification right?

• One specification is logically wrong
• One specification doesnt match our expectations,
  but isnt illogical
• How can we show a specification is illogical?
• Prove theres at least one situation where the
  post-condition is impossible to achieve even
  though the pre-condition is true.

13
Implementability

• An operation, OP, is implementable if, for all
  valid inputs ( state s and parameters args )
  there is at least one output (final state, f, and
  result, res ) that satisfies the post-condition.
• ? s , args ? (pre-OP( s, args ) ?
• ? f , ? res ? post-OP(s, args, f, res )
• As long as the input is valid, it is possible to
  find a valid result

14
Proving Implementability

• removeThread () t Thread
• Ext wr coll Collection
• Pre true
• Post coll coll - t ? t ? coll
• Proof Obligation
• Need to show

? coll ? true ? ? collOut, t ? collOut coll -
t ? t ? coll
? coll ? ? collOut, t ? collOut coll - t ? t
? coll
? coll ? ? t ? t ? coll
15
Proving Implementability

• removeThread () t Thread
• Ext wr coll Collection
• Pre coll ?
• Post coll coll - t ? t ? coll
• Proof Obligation
• Need to show that

? coll ? coll ? ? ? collOut, t ? collOut
coll - t ? t ? coll
Since theres at least one element in coll, lets
call it a
? coll ? coll a,.. ? ? collOut, t ? collOut
coll - t ? t
? coll
Obviously true t can be a
16
Is this the right specification?

• Does the model do what we want?
• Does it describe the desired behaviour?
• What do we want?
• Dealing with threads
• Is the collection fair?
• Is starvation possible?
• What can we do if it isnt
• Re-write the specification so it is fair
• Use a more appropriate data type
• What data type would be best for a fair
  collection?
• Could an unfair collection be ok (why?)

First in, first out
Thread left in collection forever
17
Collection2 Using Lists

• Assume there is a maximum size
• Data Model
• Collection2 Seq of Thread
• Where
• invariant-Collection2(coll Collection2)
• len coll lt 10

?
18
addThread2

• Collection2 Seq of Thread
• Add a thread to the collection
• addThread (t Thread)
• Ext wr coll Collection
• Pre true
• Post coll coll t
• Is it correct?
• Is it fair?
• (Do you need any more information?)

You cant tell if its fair until youve seen
what removeThread2 does
19
addThread2 revisited

• Collection2 Seq of Thread
• Add a thread to the collection
• addThread (Thread t)
• Ext wr Collection coll
• Pre len coll lt 9
• Post coll coll t
• Is it correct?

20
Preservation of Invariants

• If a data type is used in an ext wryou must show
  that the operation preserves the invariant,
  whenever the operation is properly used
• The value of the variable afterwards, must
  satisfy the invariant.
• This is a proof obligation

21
Example

• Ext wr coll Collection - satisfies the invariant
• Pre len coll lt 9 - this must be true
• if routine is used
• Post coll coll t - this must be true
• after routine called
• Given
• len coll lt 10 ? len coll lt 9 coll coll
  t
• Show
• len coll lt 10
• Clearly
• len coll len coll 1, and len coll lt 9

From the invariant on coll
The invariant on the new state
22
Refinement

• Redefine specification
• Assuming the set model is satisfactory
• Use data types closer to implementation
• How could we implement a set?
• Linked list
• Array
• Boolean array
• Reify data model
• Collection2 sequence of Thread
• Can this represent any Collection?
• Respecify operations
• Will have to show these match the originals

Sequence or Map (item ? boolean)
23
Summary
Proof Obligations

• Incremental specification
• Initial specification
• Using high-level data types
• Need to check that
• The specification can be implemented
• The specification maintains invariants
• Refine data model and operations
• New specification closer to implementation
• Need to show new model matches original
• Need to check that
• The new model can represent as much as the old
  one
• The new operations produce matching results

More Proof Obligations