Mondex Revisited with Perfect Developer

1
Mondex Revisitedwith Perfect Developer

• David CrockerEscher Technologies Ltd.

2
Background to Perfect Developer

• Its intended area of application is
  component-based software development
• PD has facilities for
• Specifying software components and systems
• Refining the specifications (manually or
  automatically)
• Verifying the specifications and any manual
  refinements
• Generating ready-to-compile code
• PD is designed and built around automated
  reasoning
• There is no direct user interaction with the
  prover

3
System-level specifications in PD

• A model of the system that surrounds the software
  is to be used can be expressed in PD
• To help verify that the software specification is
  consistent with the required system behaviour
• We did not intend that PD be used to refine
  system-level models

4
What we have donewith Mondex so far

• At the Refinement Workshop in September 2004 we
  expressed the Mondex abstract world in PD
• Using classes Purse, TransferDetails and AbWorld
• We verified all verification conditions generated
  from the abstract world model using the automatic
  prover
• No value created security property
• All value accounted security property
• 30 VCs arising from preconditions, class
  invariants and type constraints

5
Improvements made since the Refinement Workshop

• We completed some work on the PD prover and
  mappings
• Allows us to represent the world of purses as
  amap of (NAME-gtPurse) instead of a seq of
  Purse
• We added a construct for directly representing
  guarded nondeterministic choice in schema
  postconditions
• Provides a simpler way of translating Z schema
  disjunction to PD
• so the current PD translation follows the Z
  original more closely
• General improvements to the prover
• Proof time down from 2 minutes to 20 seconds

6
Our goals in this project

• Learn more about how to best represent
  system-level specifications in PD
• Understand the limitations of the PD prover in
  this context, and overcome them
• Achieve a fully automatic proof of the Mondex
  case study
• Use what we have learned to make PD more usable
  for system-level verification

7
The top-level plan

• Translate the concrete model from Z to PD
• Adapt the refinement steps as needed
• Make them more suitable for PD
• Work on the unproven verification conditions
• Where necessary, improve the prover and/or
  provide hints
• Generate code for the purse and other components
• If time, write a simple Java framework in which
  to exercise them

8
Nature of the Z refinement

• Two stage refinement
• The tricky one is from A to B
• The retrieve relation is non-functional and
  non-deterministic
• The Concrete and Between worlds have maybe lost
  and definitely lost values
• Value that is maybe lost is value in transit
• A finalization step is needed for the A to B
  refinement
• All maybe lost value becomes successfully
  transferred or definitely lost

9
Refinement VCs in PD

• Let R be the deterministic retrieve function,A
  be the abstract state space,C be the concrete
  state space,opA(a, a) be the abstract operation
  relating a to aopC(c, c) be the concrete
  operation relating c to c
• ? cC ? pre R(c)
  R is total
• ? cC ? R(c)A R maps all of
  C into A
• ? cC ? pre opA(R(c)) gt pre opC(c)
  applicability
• ? cC ? pre opA(R(c)) gt ? cC ? opC(c,
  c) gt opA(R(c), R(c)) correctness

10
Notes on refinement VCs

• We do not attempt to prove that all states in A
  can be represented by states in C
• There may be inaccessible abstract states
• If the abstract and/or concrete operations are
  composed of multiple sequential private steps,
  then R need only hold in the initial and final
  states
• The intermediate states are not observable
• They may even violate the invariants of A and C
• This is very common in software, e.g. updating a
  table and then its index

11
Multi-step operations

• Suppose we refine opA1 then opA2 by opC1 then
  opC2
• The correctness VC generated by PD is
• ? cC ? pre opA(R(c)) gt ? c,cC ?
  opC1(c, c) opC2(c, c) gt ? aA ?
  opA1(R(c), a) opA2(a, R(c))
• In PD the retrieve relation need not hold during
  unobserved intermediate states
• So the question of the concrete model resolving
  nondeterminism earlier or later than the abstract
  does not arise unless the intermediate state is
  observed

12
Structuring the Mondex refinement

• We still need a finalization step
• Because the abstract model describes atomic
  transactions (no concept of value in transit)
• In theory, we could use a single-step approach
• Refine an abstract transfer attempt to a concrete
  transfer attempt followed by finalization
• but we intend to try 2-step refinement
• Our between-world is not the same as the Z
  original
• It is closer to the abstract world than the Z
  between-world
• Its purpose is to introduce value in transit

13
Our Between-World

• Each Purse has a single attribute balance nat
• The world has the following attributes
• purses map of (NAME -gt Purse)
• lost map of (NAME -gt nat)
• inTransit map of (NAME -gt map of (NAME -gt nat))
• lost is an attribute of the world, not of Purse,
  because an individual purse cannot know whether
  missing value has been lost or is still in
  transit
• inTransit describes all value that has left one
  purse for another but neither reached it nor been
  declared lost

14
Transactions in the Between-World

• A successful transaction is performed in two
  steps
• Move value from fromPurse.balance to inTransit
• Move value from inTransit to toPurse.balance
• A lost transaction fails to perform the second
  step
• Finalization moves all inTransit value to lost
• We can state security properties for all three
  operations
• tBalance tInTransit tBalance
  tInTransittBalance tInTransit tLost
  tBalance tInTransit tLost

15
Where we go from here

• Specify and verify the between model (just
  started)
• Verify it for well-formedness and consistency
• Verify that the security properties hold
• Verify that it refines the abstract model
• Specify and verify the concrete model
• Initially, we will leave out the movement of
  exception logs from purses to the system (either
  add this to the model later, or treat it as
  another refinement)
• Verify it for consistency
• Verify that it refines the between-model

16
Questions?What do you think of our approach?
17
Software inevitably contains bugs
- lets dispel that myth!