SLIDE 1 3BA31 Formal Methods 1
How To Build (VDM♣) Models
We are now going to explore how to go about building good formal models of systems of interest. The key notions are: Entities things, concepts, individuals, . . . Collections groups, birds of a feather, . . . Relationships connections, interactions, constraints, “knock-on effects” . . . Adequacy Have we captured all relevant aspects of problem ?
3BA31 Formal Methods 2
Entities
- Basic elements of model
- What are key attributes: equality ? ordering ? numeric, or identifiers ?
SLIDE 2 3BA31 Formal Methods 3
Collections
- What’s in a collection?
- Does order or multiplicity matter ?
– Membership ? – Ordering, Priority, Queueing ? – Counting ? Measuring ?
- Collections of collections ?
3BA31 Formal Methods 4
Relationships
- Multiplicity again — many/one-to-many/one ?
- Uniqueness ?
- “Intentional” vs “Inherent” !
- Experiment
SLIDE 3 3BA31 Formal Methods 5
Scribbles 7 : Entity Examples
Consider a Birthday Book Example: entities are Persons and Birthdays A Person simply needs a unique identifier, for which the only operation need be an equality check: p ∈ Person
Id The basic type Id is simply an unbounded set of values to be used as identifiers. For a Birthday, we could give it structure (Day/Month/Year), or simply record the day number (1 . . . 366): b ∈ Birthday
N
Ordering might be useful, to establish which birthday is next. etc.
3BA31 Formal Methods 6
Scribbles 7 : Collection Examples
Ordering Multiplicity Example Math.
X X
Class Attendance Set (PA)
X
Bag/Multiset (A
→ N1)
Queue Unique Sequences (A∗
! )
Sequences (A∗)
SLIDE 4 3BA31 Formal Methods 7
Scribbles 7 : Relationship Examples
Multiplicity Examples Math. Many-to-Many Persons to Holiday Dest. P1...m ↔ 1...nH
P(P × H),
P → PH H → PP relation inverse switches between these two many-to-one Person to Birthday P1...n ↔ 1B P → B One-to-One Student to Id-No S1 ↔ 1N S N (here denotes injective fn.) N S An injective function maps different inputs to different outputs: f : A B ∧ f(a1) = f(a2)
⇒
a1 = a2
3BA31 Formal Methods 8
Mini-Exercise 3
Provide convincing examples of
- 1. All four types of collections, depending on the importance of otherwise of ordering and multiplicity
- 2. A three types of relationships, based on their many/one-to-many/one nature (for the many-to-one
relationship be clear about which side is “many” and which side is “one” Give a short reason for each example of why it belongs in the category it is in. Due: at start of 12noon Lecture, Thursday, February 22nd, 2007.
SLIDE 5 3BA31 Formal Methods 9
Formal Model: Reminder of Goals
State Type Invariant Initial-State Operations State-Change Build vs. Run State-Query
3BA31 Formal Methods 10
Developing/Determining Relationships
- “Intentional” vs “Inherent” !
Intentional: Relationships we want as modellers Inherent: Relationships we obtain from the mathematics
SLIDE 6 3BA31 Formal Methods 11
Experimentation
- Pick a structure
- Write down examples
- Ask — does it make sense ?
- If not, figure out how to “stop it happening”
Key idea here: “Initialise & Build”.
3BA31 Formal Methods 12
Operations
- How does system change?
- How do users interact with system?
- What do we want to observe about the system?
- Under what conditions do certain actions make sense?
SLIDE 7 3BA31 Formal Methods 13
Adequacy
- Have we covered the problem space?
- Can we represent all relevant entities?
- Can we describe the key collections ?
- Have we captured all relationships ?
- Do we have descriptions (as Operations) of everything relevant that can happen ?
3BA31 Formal Methods 14
State Construction
What do we do if it is not possible to build a safe (invariant preserving) state bit-by-bit ? Issue: can we start with a blank-slate or does the initial system have to be fully formed ?
SLIDE 8 3BA31 Formal Methods 15
Real Life: BASE Trusted Gateway
Goal — Trusted Gateway for transferring messages between different security levels, for British Aerospace Systems & Equipment. Approach — Two teams, one conventional, the other using formal methods. Method — Formal team employed VDM-SL, using IFAD Toolkit. Who — T.M.Brookes, J.S.Fitzgerald & P .G.Larsen, “Formal and Informal Specifications of a Secure System Component” in FME’96: Industrial Benefit and Advances in Formal Methods, Springer-Verlag, LNCS 1051, pp214–227, 1996.
3BA31 Formal Methods 16
BASE: Key Results (1)
- Formal approach spent more time up front in System Design (43% as against 34%).
- Formal approach uncovered an implicit special condition from requirements.
Informal code had to be re-written at late stage to cope.
- Formal code was less complex (“McCabe Complexity”)
- Formal code one-fifth the size of informal code.
SLIDE 9 3BA31 Formal Methods 17
BASE: Key Results (2) Formal system started up slower (4 times)
- 1. Formal System Invariant better understood, so more care was taken by resulting initialisation
code.
- 2. Not a big issue as the system is meant to stay up and running.
3BA31 Formal Methods 18
BASE: Key Results (3) Formal system throughput higher (almost 14 times !)
- 1. The informal system had to have a last-minute fix, so the code speed got worse.
- 2. If code is formally verified, then you don’t need so many run-time checks (array bounds, etc.)
SLIDE 10 3BA31 Formal Methods 19
Scribbles 8 : Modelling the “World Cup”
Initial Q&A:
- Which countries ? Only those in tournament
- Whole tournament,or just knock-out phase? Stick with knock-out phase
These choices all impact on initial state and invariant
3BA31 Formal Methods 20
Scribbles 8 : Main Concepts
Entities Countries Events Playing a Match Relationships Contest Draw A first stab: c ∈ Country
=
Id State
PCountry × . . .
The state mentions only those countries still in the contest.
SLIDE 11 3BA31 Formal Methods 21
Scribbles 8 : Modelling the Draw
A draw looks like: Ireland
- Brazil
- England
- Samoa
- Ireland
- England
- ?
The green entries shows how the contest might evolve ! We see we have a binary tree of slots, where a slot can be empty or contain a country.
3BA31 Formal Methods 22
Scribbles 8 : Badly Drawn
An invalid draw might be Ireland
- Brazil
- England
- Brazil
- Japan
- The picture above violates a number of well-formedness conditions:
- the winner of a match must be one or other contestant (i.e. not Japan)
- a country can only occur once in the draw at a level (Brazil can’t occur twice).
We need to find a way to capture this mathematically as an invariant.
SLIDE 12 3BA31 Formal Methods 23
Scribbles 8 : Attempt 1 — A Binary Tree
- The leaf slots (1st round) have countries, while intermediate nodes in the tree may be empty.
- We use a tree built from leaf-nodes with a country, and match-nodes with left and right sub-trees,
and a slot.
- A leaf node is either empty, or identifies the Winning country
Draw
LEAF Country | MATCH Draw Slot Draw Slot
EMPTY | WINNER Country
3BA31 Formal Methods 24
Scribbles 8 : Attempt 1 Example
Ireland
- Brazil
- MATCH(LEAF Ireland) EMPTY (LEAF Brazil)
Ireland
MATCH(LEAF Ireland) (WINNER Ireland) (LEAF Brazil) . . . which might then be reduced to . . . Ireland LEAF Ireland
SLIDE 13 3BA31 Formal Methods 25
Scribbles 8 : Attempt 1 Invariant
We need to define an invariant that looks (semi-formally) like: invariant(LEAF )
=
TRUE invariant(MATCH d1 slot d2)
=
invariant d1 ∧ invariant d2
∧
slot = EMPTY
∨
slot = WINNER p where p won d1 ∨ p won d2
∧ countriesof d1 ∩ countriesof d2 = ∅
This is a complex invariant. Can it be simplified? One idea is that once a match is decided, we simply replace it by a leaf with the winner, so no slots are required.
3BA31 Formal Methods 26
Scribbles 8 : Attempt 2 — A different Binary Tree
- The leaf slots have countries.
- We use a tree built from leaf-nodes with a country, and match-nodes with left and right sub-trees.
Draw
LEAF Country | MATCH Draw Draw
SLIDE 14 3BA31 Formal Methods 27
Scribbles 8 : Attempt 2 Example
Ireland
- Brazil
- MATCH(LEAF Ireland) (LEAF Brazil)
. . . which then reduces to . . . Ireland LEAF Ireland
3BA31 Formal Methods 28
Scribbles 8 : Attempt 2 Invariant
We need to define an invariant that looks (semi-formally) like: invariant(LEAF )
=
TRUE invariant(MATCH d1 d2)
=
invariant d1 ∧ invariant d2
∧ countriesof d1 ∩ countriesof d2 = ∅
This is a much less complex invariant. The red stuff about slots has disappeared.
SLIDE 15 3BA31 Formal Methods 29
Scribbles 8 : Countries in Tournament
We can easily define the countries involved: countriesof
:
Draw → PCountry countriesof(LEAF c)
{ c }
countriesof(MATCH d1 d2)
(countriesof d1) ∪ (countriesof d2)
We now have to consider the initial state, which should be a tree of uniform depth with distinct countries at leaves. We need to consider a partial operation Play : Draw
→ Draw.
We can say what it does when a Match has two leaves: Play(MATCH(LEAF c1) (LEAF c2))
winner(c1, c2) Here winner is a function that determines the victor (somehow) ! The trick now is to determine which match gets played when.
3BA31 Formal Methods 30
QuickCheck
Haskell module for testing properties of Haskell Programs Properties are defined as functions of one or more variables, returning a value of type Bool
QuickCheck tests a property (using function test !) by generating random test values for each
- f its arguments, and then evaluating the property.
It repeats this 100 times, or until a False result is returned. In the event of a False result, it prints out the test values that caused the test to fail,
- therwise it states that the test was Ok.
See http://www.cs.chalmers.se/∼rjmh/QuickCheck/ Simply import QuickCheck to use it.
SLIDE 16
3BA31 Formal Methods 31
Monomorphism Type Restriction QuickCheck cannot work with functions of polymorphic type (e.g. [a]), but instead must have a
fully specified type (monomorphic), (e.g. [Int]). This is required because QuickCheck needs to know how to generate and print test values, so it needs a concrete type to work with.
3BA31 Formal Methods 32
Example: Testing List reversal
The function reverse ::
[a] -> [a] reverses its list argument.
If we reverse the list twice, we should get the original back:
reverse (reverse xs) == xs
We can define such a property for lists as:
prop RevRev xs = reverse (reverse xs) == xs
This is just a standard Haskell function definition, so it has type
prop RevRev :: [a] -> Bool.
This is polymorphic, so when we test it we need to give it a concrete type:
test (prop RevRev :: [Int] -> Bool)
[ DEMO: Testing the Double Reverse Property ]
SLIDE 17
3BA31 Formal Methods 33
List Reversal, continued
If we reverse a list once, we do not get the original back. Let’s test this:
prop Rev xs = reverse xs == xs test (prop Rev :: [Int] -> Bool)
[ DEMO: Testing the Single Reverse Property ] We see that the failure is indicated by an example of a list which is not equal to its reverse. Properties with a name beginning prop... can be checked automatically by a script called
quickCheck (on Unix systems).
3BA31 Formal Methods 34
Generic Properties (I)
Sometimes we want a property that we can use with a variety of operators. Consider the property of commutativity - an operator ∗ is commutative if x∗y
=
y∗x We can define the property as a function of the operator:
pOpComm op x y = x ‘op‘ y == y ‘op‘ x
To test it we need to supply the operator, and type information:
test (pOpComm (+) :: Int -> Int -> Bool)
[ DEMO: Testing commutativity of + ]
SLIDE 18
3BA31 Formal Methods 35
Generic Properties (II)
Consider operator associativity: pOpAssoc op x y z = x ‘op‘ (y ‘op‘ z) ==
(x ‘op‘ y) ‘op‘ z
To test if list concatention is associative ((++) ::
[a] -> [a] -> [a])
we need to type the following:
test (pOpAssoc (++) :: [Int] -> [Int] -> [Int] -> Bool)
It is useful to have shorthands defined commonly used property signatures, e.g. type LC3B = [Char] -> [Char] -> [Char] -> Bool Then our test could use character sequences instead:
test (pOpAssoc (++) :: LC3B)
[ DEMO: Testing associativity of ++ ]
3BA31 Formal Methods 36
Commonly used test types
We use the following shorthands:
B Bool C Char I Int F Float Lx [x] Sx Set x Mxy Map x y
A function Bool->Char->Char->Bool is then given by BCCB. A function with repeated list, set or map types uses a digit to indicate how many, so [Char]->[Char]->[Char]->Bool is denoted by LC3B See IVDM Check for list of types so defined.
SLIDE 19 3BA31 Formal Methods 37
Using QuickCheck with VDM♣
Two modules have been defined to integrate QuickCheck with IVDM:
This module describes – how to generate test sets and maps – useful shorthands for commonly used test types – useful generic properties
Use this module to import both QuickCheck and IVDM — it resolves a name-clash (forAll) between the modules, by renaming the IVDM version to be for all
3BA31 Formal Methods 38
Common Generic Properties
The following generic properties have been defined Name Property
pOpComm
x∗y = y∗x
pOpAssoc
x∗(y∗z) = (x∗y)∗z
pOpIdem
x∗x = x
pOpId
i∗x = x = x∗i
pOpZero
x∗z = z = z∗x See IVDM Check for a complete list. [ DEMO: Testing properties using IVDM Test ]
SLIDE 20 3BA31 Formal Methods 39
QuickCheck: Class Arbitrary
QuickCheck defines a class called Arbitrary that defines two operators for generating random values of a type:
class Arbitrary a where arbitrary :: Gen a coarbitrary :: a -> Gen b -> Gen b
The type Gen a denotes something capable of generating random values of a given type — by a mechanism we shall ignore for now. We shall also ignore the coarbitrary function, whose role is quite technical.
3BA31 Formal Methods 40
Type Constructor Gen
While the details of how a generator works are complex, there are functions supplied to build generators:
choose :: Random a => (a,a) -> Gen a
Given type a an instance of the standard Random class, return a random value within bound of first argument
elements :: [a] -> Gen a
Pick a value at random from a list
vector :: Arbitrary a => Int -> Gen [a]
Generate a list of arbitrary elements of given length
[Gen a] -> Gen a
Pick a generator at random from a list, and use that
sized :: (Int -> Gen a) -> Gen a
Takes a generator depending on an integer and generates that integer internally (starts small and gets larger over time).
SLIDE 21 3BA31 Formal Methods 41
Some Arbitrary Instances
We can now show some simple instances of Arbitrary:
instance Arbitrary Bool where arbitrary = elements [True, False] instance Arbitrary Int where arbitrary = sized $ \n -> choose (-n,n) instance Arbitrary a => Arbitrary [a] where arbitrary = sized (\n -> choose (0,n) >>= vector)
3BA31 Formal Methods 42
Function test
Function test ::
Testable a => a -> IO() allow us to run tests on any type
belonging to the Testable class.
class Testable a where property :: a -> Property
We have instances of Testable for Bool, Property, and for a -> b where b is an instance of Testable, and a is an instance of Arbitrary and Show. This latter case means we automatically get testable instances of functions of type a1 -> a2 ->
....
- > ab -> Bool, as long as the ai can be generated arbitrarily.
SLIDE 22
3BA31 Formal Methods 43
What is type Property ?
A problem arises when testing implications: P ⇒ Q This is always true when P is false, so benefit arises from test-cases where P does not hold. We have a variation of implication that does not count case where antecedent fails:
(==>) :: Testable a => Bool -> a -> Property
The Property type is best viewed as a special form of Bool. QuickCheck testing of Property looks for 100 cases where antecedent is true, but gives up after 10,000 attempts. [ DEMO: Testing n = m2 ⇒ n · m = m3 ]
3BA31 Formal Methods 44
Exercise (Optional)
Read
http://www.cs.chalmers.se/∼rjmh/QuickCheck/manual.html
SLIDE 23
3BA31 Formal Methods 45
Scribbles 9 : Generator Examples choose (1,10) :: Gen Int
generate a random integer between 1 and 10
elements [1..10] :: Gen Int
as above
vector 5 :: Gen [a]
generate list of length 5 of arbitrary elements
sized vector :: Gen [a]
generate list of arbitrary elements of some length, the length chosen starts small and gets larger as this generator is repeatedly used.
3BA31 Formal Methods 46
Scribbles 9 : What is $ for ?
The infix operator $ has a simple definition:
($) :: (a -> b) -> a -> b f $ x = f x
Its main use is to reduce the need for brackets:
sized $ \ n -> choose (-n,n) = sized ( \ n -> choose (-n,n) ) = sized nchoose where nchoose n = choose (-n,n)
SLIDE 24 3BA31 Formal Methods 47
Scribbles 9 : Testable Instances
- Bool is an instance of Testable,
- Int is an instance of Arbitrary and Show,
- . . . so Int -> Bool is an instance of Testable.
- Char is an instance of Arbitrary and Show,
- . . . so Char -> Int -> Bool is an instance of Testable.
- Also Char -> Char -> Int -> Bool is an instance of Testable,
- and Int -> Char -> Char -> Int -> Bool,
- and . . .