Basics of Formal Methods: Proof Obligations 2

1
Basics of Formal Methods Proof Obligations 2

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

2
VDM Development Process
Check implementable
Consistency
Analyse
Requirements Statement
Check new data model is adequate
Check pre-conditions Check post-conditions
3
Refinement

• Redefine specification
• Use data types closer to implementation
• Reify data model
• Respecify operations
• Will have to show these match the originals
• Create a specification closer to a program

4
Modelling a semaphore

• Operations
• acquire (wait) release (signal)
• Data model
• Data structures for semaphore thread
• Will need to model the state of the threads

5
Semaphore Data Model

• Scope of the model
• Need to decide what we are interested in
• Its a model cant show all details
• Modelling the Semaphore
• Collection of waiting threads
• Count of permits
• Modelling the thread state
• is thread running or suspended

6
VDM Semaphore Model

• Semaphore
• count int
• wait set of Thread
• Thread
• id int
• suspended Boolean

Fairness? Starvation?
What are the implications of using a set to
represent the collection of waiting threads?
Can you think of a better type for count? Why is
it better?
7
acquire()

• Obtain a permit from the semaphore
• acquire ()
• Ext wr sem Semaphore
• Ext wr t Thread
• Pre t.suspended false
• Post if sem.count gt 0
• sem ?(sem, count ?sem.count-1) ? t t
• else
• sem ?(sem, wait?sem.wait ? t)
• ? t ?( t, suspended ?true)
• What are we omitting from our model?

What does this mean?
Not dealing with replacing the running thread
8
Release()

• Is the following ok?
• release ()
• Ext wr sem Semaphore
• Ext rd t Thread
• pre t.suspended false
• Post if card sem.wait gt 0
• ? a Thread (a ? sem.wait
• ? sem ?(sem, wait?sem.wait-a)
• ? a.suspendedfalse)
• else
• sem ?(sem, sem.count ? count1)

Why doesnt t appear in the post-condition?
9
Refinement
Would a sequence help?
If not,what could we do?

• 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
• Old - wait set of Thread
• New - wait sequence of Thread
• Respecify operations
• Will have to show these match the originals

Sequence or Map (item ? boolean)
10
Refined Semaphore Model

• Closer to the implementation
• Semaphore
• count int
• wait seq of Thread
• Where inv-Semaphore(s Semaphore)
• len s.wait lt 10
• Thread
• id int
• suspended true

?
A sequence is closer to an implementation as a
linked list or an array.
The length restriction is because Im planning to
implement the queue using an array.
11
Adequacy

• Can the new representation represent everything
  that the old one did?
• To help reason about the representations
• Image a function (a retrieve function) mapping
  the new representation to the old one
• We will concentrate on the wait queue
• Obviously the rest can be implemented
• retrieve-Set(new seq of Thread)? set of Thread
• something that returns the set of things in the
  sequence

retrieve-Set(new seq of Thread)? set of Thread
elements new
retrieve-Set(new seq of Thread)? set of Thread
???
12
Adequacy 2

• Proof Obligation
• For every old model,
• there must be a new model
• ? s set of Thread ? l seq of Thread
• s retrieve-Set(l)
• For every set there must be a sequence that we
  can get the set back from.

• If the set has fewer than 10 members
• Easy, a list with any permutation of the elements
• If the set has more than 10 members
• Impossible because of the invariant

13
Adequacy 3

• How can we fix this?
• Change the new representation
• So it can represent any set
• Change the old representation
• So it is more constrained
• And can be represented by the new one
• You are changing the model of the real world
• We will remove the length constraint
• Maybe an array wasnt the best idea
• A linked list has no fixed length

14
acquire() 2

• Obtain a permit from the semaphore
• acquire ()
• Ext wr sem Semaphore
• Ext wr t Thread
• Pre t.suspended false
• Post if sem.count gt 0
• sem ?(sem, count ?sem.count-1) ? t t
• else
• sem ?(sem, wait? sem.wait t) ? t ?(
  t, suspended ? true)

Explain this
15
Applicability
Given corresponding before states, newBS and
oldBS (that is oldBS retrieve(newBS)), if
the old pre-condition applies to oldBS, the new
pre-condition must apply to newBS
Why not exactly as easy to meet? It doesnt
matter if the new operation can be applied to
more situations. If I buy rock-crusher promising
to crush rocks up to 10cm diameter, I dont mind
if it actually crushes rocks up to 12cm diameter.

• Proof obligation on the new pre-conditions
• Operation preconditions in the new model must be
  no more restrictive than in the old one.

The Old Representation
Old Before State
Match
Match
?
The New Representation
New Before State
16
Check the New Representation

• For acquire, the two pre-conditions are the same
  no need to check
• Pretend the pre-conditions were
• Old pre-condition
• card oldS.wait lt 10 (using a set)
• New pre-condition
• len newS.wait lt 11 (using a sequence)
• Need to show
• card oldS.wait lt 10 ? len newS.wait lt 11

17
Check the New Representation 2

• Need to show
• card oldS.wait lt 10 ? len newS.wait lt 11
• Use the retrieve function
• retrieve (newS.wait) elements newS.wait
• Need to show
• card elements newS.wait lt 10
• ? len newS.wait lt 11
• Is this true?
• If not, need to modify the pre-conditions

?
If the old operation can be applied
18
Equivalence

• The final proof obligation
• The results of operations in the new model must
  match the results of the old model

The Old Representation
Old Before State
Old After State
Old operation
?
Match
Match
?
These must match
The New Representation
New Before State
New After State
New operation
19
Check the New Representation

• If count gt 0, new and old operations match
• Looking at a semaphore with a queue
• Concentrate on the queue

sem ?(sem, wait?sem.wait ? t)
(elements sSeq) ? t
elements sSeq
?
Must match
elements (sSeq t)
sem ?(sem, wait? sem.wait t)
sSeq
sSeq t
20
Finishing the proof

• We need to show that
• (elements semSeq) ? t elements (semSeq
  t)
• elements (semSeq t) will contain
• all the elements that occur in semSeq as well as
  t
• But elements (semSeq) all the elements in
  semSeq
• So elements (semSeq t) is (elements semSeq)
  ? t

21
The proof obligations

• The specification must be consistent
• Operations must preserve invariants
• The new model must be sufficient to represent
  anything the old one can
• New pre-condition must be true if the old one is
  (on corresponding states)
• All new operations must produce equivalent results

22
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 pre-conditions must not be more
  restricting
• The new operations produce matching results

More Proof Obligations