COMP 2600: Formal Methods for Software
Engineeing
Specification in Z: Introduction and Examples
Dirk Pattinson
Semester 2, 2013
System Specification in Z
Logic
• we have met first-order logic – speaks about properties of structures
• formal notion of proof – those statements which are true
Set Theory
• basic mechanism to speak about, well, sets
• basic operations to construct sets: power sets, products etc.
System Specification in Z
Logic + Set Theory
• Set Theory speaks about types
• Logic speaks about properties
(Z is one particular specification formalism – there are others.)
Specification and Proof
Functional Programs
• techniques to show that a function has a desired property
• to verify that a program meets its specification
Imperative Programs
1
• techniques to reason about state changes brought about by a program
• to verify that a program meets its specification.
System Specification
• What on earth is a specification?
• How can we write down and combine specifications?
Our View on System Specification
Basic Tenet
A Type is a Set. [1ex] An operation is a function on sets.
(Hardcore theorists may disagree. But we take this view here.)
Specification is Abstract
• we don’t care about the how . Only the what matters.
• we don’t care about the internal structure of types.
• we don’t care about implementation.
But we care a lot about the effects of operations!
Why should we care at all?
Specification as Contract
• typical requirement specifications are English prose. Often several
hunderes of pages.
• Ambiguities abound! Specifications are a way to be precise.
Specification as Language
• Software developmens typically involves large teams. Often hundereds
of people.
• Interfaces matter! Specifications are a way to be precise.
Specifications are Machine-Checkable
• formal language enables tool support
• idealy spans the whole software life cycle.
(But of course, specification is not a magic bullet.)
2
Introductory Example
Spivak’s Birthday Book
• consists of a set of people – my friends
• every person has a birthday – which may be unknown.
But I know the birthdays of all my friends!
Data / Property Split
Data:
• my friends: a subset of the set of people.
• the mapping: a partial function from people to birthdays
Constraint.
• The birthdays of my friends are known.
(This structure / property split is typical. We’ll see it all the time.)
A more abstract view
Static Aspects: Legal Data
Data The basic containers that store information
Constraint Containers may not be filled at random.
Examples abound:
• lists that have to be sorted
• August 57 is an invalid date
• . . . I know the birthdays of my friends ;-)
Dynamic Aspect: Operations on Legal Data
Operations Described in terms of before / after relation
Examples abound:
• after inserting a tuple into a database, we have it
• ordered insert into an ordered list produces an ordered list
• . . . looking up a birthday gives the correct date ;-)
3
Birthday Book: Basic Types
Basic Ingredients
• Person and Date. These are types (i.e. sets) and we don’t care about
their structure. But we need to declare them. Like so:
[Person, Date]
• types declared in this way are called given types.
Birthday Book: Structure and Constraints
People known to me
(P is powerset)
• every element of known is a subset of Person.
• so known: PPerson – note the role of P as type constructor!
(→
7 is partial functions)
Records of birthdays
• everybody has at most one birthday.
• so birthday : P erson →
7 Date – note →
7 as type constructor!
I know my friends’ birthdays
(dom is domain)
• every element of known is in the domain of birthday (and vice versa)
• so known = dom birthday – note dom as built-in function!
Birthday Book as Z-Specification
Graphical Notation
[P erson, Date]
BirthdayBook
known : P Person
birthday : Person →
7 Date
known = dom birthday
Terminology
• The bit in the box is a Z-schema. It encapsulates the fundamental
structure / property pattern.
4
• the bit above the horizontal line declares structure
• and the bit below is the constraint.
• The schema together with the declatration is an example of specification, also called Z-document.
(So far lots of overhead to express something very simple . . . )
Built in Type Constructors
BirthdayBook
known : P Person
birthday : Person →
7 Date
known = dom birthday
Type Constructors
Z has a number of built in type constructors, containing
powerset
total functions
integers
P
→
Z
→
7
↔
seq
partial functions
relations
sequences
(we will see more later. I’ll try and provide a cheat sheet.)
Types are expressions built from type constructors using given types.
Built in Functions
BirthdayBook
known : P Person
birthday : Person →
7 Date
known = dom birthday
Built in Functions/ Relations
Z has a number of built in functions and relations, containing
dom
∈
the domain of a function/relation
set membership
≤
]
less than
cardinality
Every function/relation has a type which may be polymorphic. There
are more builtins than shown above.
Constraints are just formulae of predicate logic involving these.
5
Operations: A simple Example
AddBirthday
inputs person? and date?
outputs none
action add the person/date pair to birthdays
(By convention, input variables end in ? and output variables end in !.)
Precondition
• the new person should not be in the birthday book already.
• so person? 6∈ known.
(before-values of schema variables have the declared name)
Postcondition
• after the update, the new birthday is known
• so birthday 0 = birthday ∪ {person? 7→ date?}
(after-values of schema variables are primed, e.g. birthday 0 )
AddBirthday as a Schema
Explicit Variant
AddBirthday
known : P Person; known 0 : P Person
birthday : Person →
7 Date; birthday 0 : Person →
7 Date
person? : Person
date? : Date
known = dom birthday; known 0 = dom birthday 0
person? 6∈ known; birthday 0 = birthday ∪ {person? 7→ date?}
This is overkill . . . but shows that operations are schemas
• the new schema incorporates two copies of BirthdayBook
• one for before (non-primed) and one for after (primed)
• augmented with input variables and just one formula!
Surely we can do better . . .
6
Operations on Schemas
Priming a Schema
If S is a schema, then S 0 is the schema where all variable names in declaration
and constraints have been primed.
Example
BirthdayBook
known : P Person
birthday : Person →
7 Date;
known = dom birthday;
BirthdayBook 0
known 0 : P Person
birthday 0 : Person →
7 Date
known 0 = dom birthday 0
Operations that change state
Delta, or before/after
If S is a schema, then ∆S is the union of S and S 0 (both of variables and
constraints, separately).
Example
BirthdayBook
known : P Person
birthday : Person →
7 Date
known = dom birthday;
∆BirthdayBook
known : P Person; known 0 : P Person
birthday : Person →
7 Date; birthday 0 : Person →
7 Date
known = dom birthday; known 0 = dom birthday 0
Schema Import
Adding a Birthday, More Concisely
7
AddBirthday
∆BirthdayBook
person? : Person
date? : Date
person? 6∈ known
birthday 0 = birthday ∪ {person? 7→ date?}
Schema Import on the Sly
• we have included a schema as a declaration
• this adds all declared variables and constraints
(Schema import as above is an important mechanism for defining schemas.
It saves lots of writing!)
Birthday Lookup
As a schema
FindBirthday
∆BirthdayBook
person? : Person
date! : Date
person? ∈ known
date! = birthday(person?)
(Note the convention of banged variables (date!) designating output.)
Question
Is this a good specification, at least for the case where name? ∈ known
Birthday Book from Hell
Is this a good specification?
FindBirthday
∆BirthdayBook
person? : Person
date! : Date
perosn? ∈ known
date! = birthday(person?)
birthday 0 = ∅; known 0 = ∅
8
?
Strenghening of Schemas
Every implementation that is consistent with the augmented schema is consistent with the original schema (without the red bits).
• this is trivial – we just ask that more assertions are satisfied
• but it shows that there’s something we haven’t thought about . . .
Operations that don’t change state
Xi, or before = after
If S is a schema, then ΞS is the schema ∆S with additional constraints
v = v 0 for every declared variable of S .
Example
BirthdayBook
known : P Person
birthday : Person →
7 Date
known = dom birthday;
ΞBirthdayBook
known : P Person; known 0 : P Person
birthday : Person →
7 Date; birthday 0 : Person →
7 Date
known = dom birthday; known 0 = dom birthday 0
birthday 0 = birthday; known 0 = known
Finally: Finding a Birthday
Using Ξ-Schemas
FindBirthday
ΞBirthdayBook
person? : Person
date! : Date
person? ∈ known
date! = birthday(person?)
Quick Summary
• use primed variables to signify values after an operation
• use ∆ for operations that change state, Ξ for those that don’t
9
• both contain primed and non-primed variables and constraints
• Ξ additionally forces equality between primed and non-primed variables.
Who’s Birthday is Today?
As a Schema
Remind
ΞBirthdayBook
today?Date
cards! : P Person
∀ p : Person • p ∈ cards! ⇔ birthday(p) = today?
• constraints can be complex first-order formulae
• in Z , people write ∀ x : P • φ for ∀ x ∈ P φ.
Shorthand Notation
The last constraint above can also be written as
cards! = {p : P erson | birthday(p) = today?}
using set comprehension as cards! is of type P P erson.
Schema Equivalence
What’s the difference? What if Ξ is replaced by ∆
FindBirthday
ΞBirthdayBook
person? : Person
date! : Date
person? ∈ known
date! = birthday(name?)
FindBirthday
ΞBirthdayBook
person? : Person
date! : Date
person? ∈ known 0
date! = birthday 0 (person?)
←− note the primes
10
Literature
Today’s Lecture
Based on ‘The Z notation: A reference Manual’, Second Edition, by J.M.
Spivey, Oxford Programming Research Group.
Available at
http://spivey.oriel.ox.ac.uk/mike/zrm/zrm.pdf
Read Chapter 1 (Tutorial Introduction) and get it straight from the
mouth of the horse!
11