unit 1 formal methods in software engineeringstaff · 2000. 9. 26. · 5 introduction to formal...
TRANSCRIPT
1
Introduction to Formal Methods
Unit 1
Formal methods in software engineering
Unit Objectives
At the end of this unit you should be able to:
1 identify the role of formal methods in software
development; and
2 argue for and against the use of formal methods in software
design.
Reading Material: Potter Chapter 1 and Hall.
Introduction
The early days of computers were dominated by hardware issues;
the production of software was not considered problematic, mainly
because it was impossible to write large programs with the memory
available. However, by the end of the 1960’s, some computer
scientists were expressing concern at the rather ad hoc methods
used by programmers. These early pioneers of the software
engineering discipline began to ask the following question – “can
you prove that the program you have just written does the task
expected of it?”. The answer, in every case but the simplest, was
“no”. Thus began the development of formal methods, a new
branch of computer science, whose aims were – and still are – to
devise sound principles for the construction of software.
Formal methods have a part to play in each stage of the software
engineering process. In system specification, they can be used to
define the meaning of a system before it is implemented, and can
help to resolve ambiguities in a client’s set of requirements. The
specification serves as a starting point for design, where formal
techniques can be applied to prove that the eventual system meets
its specification. Furthermore, formal techniques exist for devising
2
Introduction to Formal Methods
test cases. In this module, you will be using formal methods largely
for systems specification.
Formal methods for system specification have reached maturity in
the last decade, and are now widely taught and used in the more
progressive software companies. Although many different notations
exist, two rather similar specification languages, Z and VDM,
dominate the field. Their similarity means that a knowledge of
either one of these is easily transferred to the other. In this Module
you will meet and use the Z notation.
Z was developed at Oxford University’s Programming Research
Group, the foremost software engineering research institute in the
UK.
The popularity of Z is largely due to its basis in the relatively
straightforward mathematical formalisms of set theory and discrete
mathematics. The early units of this module introduce these
essential topics.
Now read Potter Chapter 1
Potter Chapter 1 compares software engineering with older, well-
established branches of engineering, and suggests that these
disciplines have benefitted by adopting a sound, mathematical
basis in most aspects of product design. By contrast, most software
production has not benefitted from a principled approach.
To further illustrate the effects of this, a recent large-scale survey
(“Falling down is part of growing up: the study of failure and the
software engineering community”, Dalcher, in Software
Engineering Education, Jan. 1994) demonstrates that poor software
production is costing the UK at least £1 billion per annum. The
figures come from a survey of 400 UK firms, reviewing all projects
in excess of £1 million, undertaken in the last 10 years.
3
Introduction to Formal Methods
Of these
20% of all projects were abandoned
60% were late
90% exceeded their budgets
98% changed specification to lower the functionality.
Now read Hall
Hall: Seven Myths of Formal Methods
Hall ’s article is an attempt to answer common criticisms of formal
methods – that they are costly, too difficult and not useful for real
problems. At the same time, he argues against the idea that formal
methods can guarantee perfection (myth 1).
Page 14 of Hall shows a fragment of a Z specification. You are not
expected to understand the notation yet!
SAQ 1.1
Write down the possible consequences of
software errors in each of the following
applications:
* public transport scheduling (e.g., the MRT)
* control of an aircraft
* banking
Objective 1
4
Introduction to Formal Methods
SAQ 1.2
(i) If formal methods cannot guarantee perfection,
what is the point of using them?
(ii) Formal specifications aim to express the
meaning of a system. Some would argue that the
program code does exactly that. Do you agree?
Why might we wish to use a different notation for
system specification?
Objective 2
5
Introduction to Formal Methods
Unit 2
Logic and set theory
Unit Objectives
At the end of this unit you should be able to:
3 understand the key elements of set theory;
4 differentiate between a proposition and a predicate;
5 use propositions and predicates to state properties of
systems;
6 demonstrate the equivalence of propositions using truth
tables.
Reading Material: Potter Chapters 2 and 3.
Introduction
This Unit introduces some of the mathematical basis for formal
specification. It covers sufficient logic and set theory to allow for
the presentation of a first example – the specification of a language
translation system – which is introduced in Chapter 3 of Potter.
Now read Potter Chapter 2, section 2.1
If you have met sets before, perhaps the key difference in their use
within Z is the idea that objects in a set are assumed to be of the
same kind, or type. In fact, every formal object that you will meet
in this Module has a type. Similarly, when we specify operations to
manipulate objects, it is necessary to state what type of objects are
being manipulated, and what type of result is to be produced. For
example, it makes no sense to ask what the square root of a
sequence of characters is! A similar example is given in Potter, at
the top of page 12.
6
Introduction to Formal Methods
The type system of Z is extremely important, and its use is
emphasised throughout the textbook. When you write a formal
expression, you should ensure that you are working within the type
system. You should always check that the operators (for example,
the set union and subset operators) you use have operands of the
correct type. It is important to get into the habit of applying these
checks to your work. Unit 3 has more to say about types in Z.
Formal notations often make use of different symbols for different
kinds of equality. One sort of equality, sometimes called
definitional equality , is denoted by the ‘==’ symbol (shown on page
11 of Potter). This simply means that the name on the left hand side
(LHS) of the ‘==’ symbol is defined to mean the same as the
expression on the right hand side (RHS). Whenever the LHS
appears in a specification, its meaning is understood to be
equivalent to the RHS.
In contrast, page 12 of Potter uses the ordinary equals symbol, ‘=’.
This is because the LHS is an expression, not just a name, which
can be evaluated: its value can be calculated and expressed on the
RHS; nothing new is being defined.
SAQ 2.1
Attempt Potter, exercise 2.1.
Objective 3
7
Introduction to Formal Methods
Now read Potter Chapter 2, section 2.2
The material presented in section 2.2 of Potter is one of the most
important parts of the Module.
You should spend as much time on this part of the Unit as necessary
until you feel confident with reading and writing logical
expressions. The material covered here will be needed in almost
every specification that you write.
Propositions and predicates
It is essential that you understand the difference between a
proposition and a predicate. The following SAQ tests your
understanding of this distinction.
SAQ 2.2
Attempt Potter, exercise 2.5.
Note: Use the letters in sequence to define the
outline of the region. For example, the answer to
the first part might be expressed as AWYZBU.
Objective 3
8
Introduction to Formal Methods
Check your answers. If you had problems with this exercise, you
should ask yourself the following two questions when deciding
whether a statement is a proposition, a predicate, or neither. First,
does it make sense to answer whether the expression is true or
false? If not, then the statement is not likely to be a proposition or a
predicate: it could be a command or a question but it is not a
statement of fact. If it does make sense to ask whether the
expression is true or false, then ask yourself whether you can
determine the answer as definitely true or definitely false. If you can
determine the answer, then you are probably dealing with a
proposition. This approach isn’t guaranteed to work in awkward
cases. For instance, “It rained in Russia on October 22nd, 1917” is
a proposition, but its truth or falsity may not be easily determined.
If the answer depends on the value given to any variables in the
statement (as is the case in part c of SAQ 2.3 above), then you have
a predicate.
SAQ 2.3
Which of the following expressions are
propositions, which are predicates, and which
are neither?
a. Two is an even number.
b. Three is an even number.
c. The number x is even (assume x is a number).
d. This statement is false.
e. It is raining today.
f. Is it raining today?
g. All numbers greater than 3 are even.
h. All numbers greater than x are greater than 3.
i. All numbers greater than x are even.
Objective 4
9
Introduction to Formal Methods
Logical connectives
Although we will use propositions and predicates to describe
aspects of the real world, we have to be a little careful in
interpreting the meaning of logical operators, or connectives. The
problematic connectives are ‘or’ and ‘implies’ ( and ).
Potter’s example of the Instruction Manual (pages 20-22) should
help you to understand why the truth table for implication is
reasonable. However, Potter prefers to ignore the fact that
propositions like the following are true:
2 is an odd number the earth is flat
This is somewhat counter to intuition! However, examination of the
truth table for implication shows that a statement of the form
false false
is indeed a true proposition. This example demonstrates that logical
connectives do not necessarily make sense when applied to the real
world. In the real world, we do not usually draw any implications
from a proposition which is false and we would usually regard any
such implication as meaningless or undecidable. In a logical
system, we still need the ability to reason with false propositions, in
a way which does not deliver meaningless or undecidable results.
Section 2.2.2: quantifiers
There is a subtle relationship between propositions, predicates and
quantified expressions. Some things to remember are:
• a quantified expression involves a quantifier, one or more
variables, and a predicate;
• a quantifier can be used to turn a predicate into a
proposition; and
∨ ⇒
⇒
⇒
10
Introduction to Formal Methods
• the universal ( ) and existential ( ) quantifiers are
related as demonstrated at the top of page 26 of Potter.
Potter’s example in the lower half of page 26 is quite complicated.
Most of the quantified expressions you will write in later Units are
not as complex as this. In other words, if you can follow the
development on pages 26 and 27, you should have little difficulty
in constructing such expressions in system specifications.
On page 28 of Potter, the first sentence in parentheses mentions
variables binding to the operators and more strongly than to
the operator . Potter doesn’t make the point explicit, but he
means that an expression such as
is interpreted as
rather than
There are two mechanisms for deciding which interpretation of an
expression is intended. The first mechanism is to use operator
precedence (which is what Potter means by ‘bind more strongly
than’). A second mechanism is to use brackets, as in the above
example. If in doubt, use brackets, since that does not require the
person reading your specification knowing the operator
precedences.
∀ ∃
∧ ∨⇒
A B C∧⇒
A B C∧( )⇒
A B⇒( ) C∧
11
Introduction to Formal Methods
The following SAQ tests your ability to produce quantified
expressions from ordinary sentences.
Check your answers at this point before proceeding.
SAQ 2.4
Attempt Potter, exercise 2.6.
To do all the parts (i) to (viii) would be very time-
consuming. Do as many parts as you feel
necessary to master the use of truth tables to show
equivalence of propositions.
Objective 6
SAQ 2.5
Attempt Potter, exercise 2.12.
This is quite a difficult question, for which you
will need to look closely at the examples given in
subsection 2.2.2.
Objective 5
SAQ 2.6
Attempt Potter, exercise 2.14.
Objective 5
12
Introduction to Formal Methods
Now read Potter Chapter 2, section 2.3
Section 2.3 explores the link between sets and predicates. Here we
see the useful role that predicates play in system specification –
they enable sets to be specified in a very compact form, without the
need to enumerate all the members of the set.
Section 2.3.2: Tuples
You will be familiar with the notion of record data structures in a
programming language. Records are similar to tuples, with the
additional property that tuples are ordered. The extension to the set
notation is very natural. You will meet the idea of an ordered pair
in Unit 4, where it forms the basis for other data abstractions.
Section 2.3.3: Sets of sets
Potter uses an example demonstrating the need for more complex
structures. We will see how sets of sets can be formally defined in
Unit 4.
Chapter 3
A few comments are worthwhile before you read this chapter of
Potter. Potter’s aim is to demonstrate the relevance of set theory and
the predicate calculus to software specification. He does this by
using the limited amount of notation you have met so far to
describe an example system for translation.
Unfortunately, his approach suffers from the problem of
unnecessary complexity; because you have only seen a limited
amount of notation, the expressions used to define operations are
rather unwieldy. Worse still, they are not in the format of the Z
notation, and you will not see how they can be put into that format
until much later in this Module (in Unit 7).
Chapter 3 does contain some important illustrations, particularly
the naming conventions on page 40. Further, it will give you some
13
Introduction to Formal Methods
idea of how the material covered so far could be used in a system
specification.
My advice is this: read chapter 3, but do not get too engrossed in
the notation used; instead, concentrate on the text. You will need
to re-read chapter 3 when it is turned into a more formal notation
in Unit 7.
Now read Potter, Chapter 3.
14
Introduction to Formal Methods
Unit 3
The Z type system
Unit Objectives
At the end of this unit you should be able to:
7 write well-formed expressions in the Z type system; and
8 read generic definitions, and understand their role in
defining the basic operators of set theory.
Reading Material: Potter Chapter 4.
Introduction
This Unit introduces the Z type system, starting with an explanation
of why the notion of type is not only useful but logically essential.
The key message of this Unit is that complex types can be built from
simpler types. You will meet type constructors which take one or
more simple types and generate objects such as sets, pairs and
triples.
Later in the Unit, you will meet some of the Z notation (although
the bulk of this will not be introduced until Unit 5).
Now read Potter Chapter 4, sections 4.1 and 4.2
You may think initially that having to specify the type of absolutely
everything in a specification is a lot of effort. However, writing
down and determining the type of any object soon becomes fairly
straightforward. Section 4.1 explains some of the benefits of using
a typed specification language.
Three motivations are given in this section, namely:
• the possibility of type-checking
(manually or automatically);
15
Introduction to Formal Methods
• the discipline it imposes on writing specifications; and
• the removal of Russell’s paradox.
Though this last property is both interesting and theoretically
important, it is the first and second properties that really motivate
the use of a type system for specification of real-world systems.
After a little experience with types, you will find definitions like that
of the set Numerous on page 52 of Potter most unappealing – they
simply look wrong, because the lack of a given type for x and y
leaves the reader wondering whether x and y are sets, or elements,
or something else.
One theme which recurs in section 4.2 and elsewhere is the idea
that it is possible, automatically, to determine the type of any
expression. Several of the exercises test your ability to follow the
rules in deriving types. It then becomes possible to type-check any
expression you write down.
Subsection 4.2.1: basic types
The key point about basic types is the idea that we are not
interested in their internal structure. To illustrate what is meant by
internal structure, consider a system which represents a dictionary.
A simple model for a dictionary is a set of words. If all we are
interested in is whether or not a given word is in the dictionary (to
use in a spell-checker, for example), then we need say no more
about the fact that a word is made up of characters. We would have
a basic type, [WORD], and that would be sufficient. Potter does not
stress this point, but it is worth stating that writing specifications is
all about being abstract – not allowing unimportant
implementation details to obscure the specification. The use of
basic types promotes abstraction.
16
Introduction to Formal Methods
Subsection 4.2.2: powersets
In this subsection, the link between the informal ‘set of X’ and the
more formal idea of a powerset is made. The powerset is known as
a constructor because it takes a type and produces another type.
Why do we need the set of all subsets of a given type? Potter does
not really illustrate this point, but an example might help. Potter, at
the top of page 58, refers to a library, modelled as a set of books.
You might argue that the library will only take on some selected
subsets of the set of all books, whereas the powerset contains all
possible subsets. However, a moment’s thought will demonstrate
that the library may indeed take on any possible value from the
powerset. Initially, it is empty, and the empty set is a member of the
powerset. Eventually, it may contain every book known about, so
its value will be the maximal set from the powerset. In the process
of building up the collection, it is clear that it could take on any
intermediate value. Thus, whenever you need to represent a set of
objects, whether they be books, students or galaxies, you need to
cater for that set taking on any value from the powerset.
Do not be confused by the idea, expressed at the top of page 59,
that there are lots of different types of empty set. This is indeed true,
but rather meaningless and can be safely ignored, as suggested in
the text, by using a single empty set symbol rather than a different
symbol for each type. It is hardly ever meaningful to compare an
empty set of books with an empty set of students, for instance!
17
Introduction to Formal Methods
Subsection 4.2.3: the Cartesian product
This subsection formalises the notion of an ordered pair, triple, etc.
of objects. Like the powerset, the Cartesian product is a type
constructor which produces a new type from subtypes. The term
Cartesian comes from the French mathematician and philosopher
Rene Descartes (1596-1650), who introduced the co-ordinate
system that most people are familiar with.
Potter does not stress the important distinction between a set with
two elements and an ordered pair. The following are not the same:
{red, blue}
(red, blue)
The first is a set with two elements, and it could equally well be
written as {blue, red} since order is unimportant in sets. The second
is an ordered pair, not a set. Order is important and the ordered pair
(red, blue) is different from the ordered pair (blue, red).
SAQ 3.1
Attempt Potter, exercises 4.1, 4.3, 4.6 and 4.7.
In this and many later SAQs, you are asked to
attempt several exercises (each with several parts)
as part of a single SAQ. You should expect to
spend more time on these SAQ’s.
Objective 7
18
Introduction to Formal Methods
Subsection 4.2.4: declaration abbreviations
A useful method for declaring variables which obey some
condition such as even-ness is described in this subsection. The
distinction between a type and an abbreviation for finite subsets is
rather subtle and of little importance at this level.
Subsection 4.2.5: simple data types
Potter uses the term ‘simple data types’ to describe what are
generally known as enumerated types in programming languages
such as C and Modula-2. One common use for simple data types is
the enumeration of error messages, as you will see in later units.
Now read Potter Chapter 4, sections 4.3, 4.4 and 4.5
Section 4.3: extending the quantifier notation
No new ideas are presented in this section. At a first (or second!)
reading, you might find the notation a little difficult to commit to
memory. The solution is: don’t! The notational devices are meant
to make things easier for the specifier, but it is always possible to
avoid their use, usually at the expense of clarity. Use section 4.3 as
SAQ 3.2
Attempt Potter, exercises 4.10 (except for parts vi
and vii), 4.11 and 4.12.
Warning: the solution to 4.10 is rather long-
winded!
It is also worth pointing out that you are unlikely
to meet elaborate objects such as powersets of
powersets of powersets in typical specifications!
Objective 7
19
Introduction to Formal Methods
a reference for later units which do employ some of the extended
forms of quantification. Subsection 4.3.2 could be summarised
simply by saying that:
Declarations | Constraint • Predicate
is equivalent to
Declarations • Constraint Predicate
and that
Declarations | Constraint • Predicate
means the same as
Declarations • Constraint Predicate.
Subsection 4.3.3: extended notation for sets
Subsection 4.3.3 on set expressions is much more important than
subsection 4.3.2 on the relationship between constraints and
predicates. There are two aspects to Potter’s description of set
expression.
First, that if you wish a set to have members which are ordered
pairs, triples or other tuples, you can express the fact that its
members have this internal structure in a list of declarations of the
form
{ x: X, y: Y, ... | Predicate }
which yields set members of the form (x,y).
Second, if the members of the set are not tuples, but have some
other internal structure or relationship, you can define other
∀
∀ ⇒
∃
∃ ∧
20
Introduction to Formal Methods
internal structures or relationships with the use of an expression or
term, using the notation
{Decls | Pred • Expr }.
Section 4.4: specification construction units
This important section starts to introduce the features which make
Z something more than an assortment of predicates and type
definitions. Z uses a form of layout which ensures that formal
aspects of a specification document stand out against the
accompanying text. Recall that a specification document is neither
all formal or all informal – the formality ensures clarity and removes
ambiguity, whilst the non-formal text aids comprehensibility.
The main formal paragraphs used in Z are axiomatic descriptions
and schemas. The latter will be introduced in Unit 5, whilst the
former is presented in section 4.4.1. You may wonder why
axiomatic descriptions are so called. Well, the term axiom is
usually taken to mean something assumed or given about a system
(typically, a logical system). Typically, axiomatic descriptions in Z
specify useful definitions (of constants, sets and functions) which
form part of the basis for a specification and which may be used in
other parts of the specification. You may find it helpful to think of
them as you would of functions (as opposed to procedures) in a
programming language such as Pascal (but not C, where functions
may play the role of procedures in Pascal). That is, they do not
modify the state of the system in any way, but produce useful
information. It is tempting to say that they return useful information
SAQ 3.3
Attempt Potter, exercise 4.22
Objective 7
21
Introduction to Formal Methods
(such as the maximum of 2 numbers), but this would be wrong:
nothing is returned in a specification. For example, the maximum
of two numbers would be defined without necessarily saying how
it is to be computed.
A complementary way for you to think about axiomatic
descriptions is as a mechanism for the definition of global variables,
as Potter suggests on page 71.
Incidentally, one reason why axiomatic descriptions are not called
functions in Z is because the term function is reserved for
something else, as we’ll see in Unit 4.
Section 4.4.2 introduces abbreviations using the == symbol. This is
a useful method to hide some of the complexity of set definitions
from the reader.
Section 4.4.3: generic definitions
This Unit has focussed on type definitions, and the point which has
been stressed more than any other is the importance of providing a
type for every object in a Z specification. In particular, operators
can only be applied to objects if the types of those objects are
compatible with the operator. So, for example, if we wished to
compute the square of the largest value in a set, it only makes sense
to do so if the set contains values which can be ordered and
squared. Naturally, we would expect to declare the type of
arguments and results whenever an operator is defined. This seems
reasonable for very specific operations, but what about things
SAQ 3.4
Attempt Potter, exercises 4.24 and 4.25
Objective 7
22
Introduction to Formal Methods
which we take for granted such as the subset relation? Strictly, it
appears that we need to define a different subset relation for each
type to which it is applied. Each of these subset relations would
have a very similar definition. In fact, the only difference would be
the name of the types.
Happily, Z provides a form of definition which allows generic type
parameters, as demonstrated for the subset relation on page 75.
Generic definitions are the key to extensibility in Z. If we wish to
add something to Z – a library of definitions to handle matrices, for
example – we do not need to worry about specific types (for
example, of matrix elements) through the use of generic definitions.
Section 4.4.3 does no more than introduce the generic definition.
However, further examples can be found in sections 5.4.1 and
5.6.2, where this form of definition is employed to define operators
on functions and sequences, two of the abstractions we’ll meet in
the next Unit.
SAQ 3.5
Attempt Potter, exercise 4.30
Objective 8
23
Introduction to Formal Methods
Unit 4
Relations, functions and sequences
Unit Objectives
At the end of this unit you should be able to:
9 construct and evaluate expressions involving relations;
10 construct and evaluate expressions involving functions; and
11 construct and evaluate expressions involving sequences.
Reading Material: Potter Chapter 5.
Introduction
This unit presents the most important facilities for data abstraction
in the Z notation, and demonstrates how they are related to the set
theory you have met in previous units. Armed with this more
powerful collection of objects, you will be able to choose the most
appropriate data model to capture aspects of the software system
being specified.
Each section of the chapter has the following format: first, the
abstraction is introduced informally; then, the Z notation for the
abstraction is presented; and finally, the relevant operations are
defined. There are lots of short SAQs in this Unit to exercise you in
the use of the basic operators introduced.
Now read Potter Chapter 5, sections 5.1 and 5.2
Subsection 5.1.2
Ensure that you understand the difference between source, target,
domain and range. Exercises 5.5 and 5.7 in SAQ 4.1 below tests
this.
24
Introduction to Formal Methods
Section 5.2 Relations
You have seen that a relation is just a set of ordered pairs. This fact
allows us to use set operations on relations. Later in the Unit, you
will see that this principle can be applied to further abstractions
involving functions and sequences. However, it is convenient to
use notation which is specialised to deal with each type of
abstraction. Section 5.2 of Potter defines relational inverse,
restriction, anti-restriction (or subtraction, as it is called here),
composition and relational image. Each of these is straightforward,
but you may find the sheer amount of new notation daunting at
first.
In subsection 5.2.1, note that the relation isriddenby is defined here
for illustration only; we wouldn’t normally give a name to the
inverse relation, but would use the forward relation together with
the inverse symbol.
Subsection 5.2.3: relational composition
The example of relational composition given in this subsection
based on haswheels is rather contrived. To get the full picture, you
should concentrate on the example using relations R1 and R2 on
page 90; better still, look at the formal definition on page 91.
You have almost certainly met something like relational
composition before, when using a programming language.
Consider a (programming language) statement like this:
y := sqr(inc(x));
SAQ 4.1
Attempt Potter, exercises 5.3, 5.5 and 5.7
Objective 9
25
Introduction to Formal Methods
where sqr is the ‘square’ function, and inc adds one to its argument.
If we consider inc and sqr to be relations, then we can regard the
expression sqr(inc(x)) as meaning ‘first compute relation inc, then
compute relation sqr on the result’. In other words, the above is
equivalent to
inc ; sqr
i.e. the composition of inc with sqr. Note that although the order of
application of relations is the same, the order in which they are
written is reversed.
Subsection 5.2.4: relational image
Relational image is rather like the application of a function in a
programming language, except that its argument is not a single
value, but a set, and its result is likewise a set. In fact, the statement
above should be written
inc ; sqr (| { x } |)
Since this returns a set of values (more precisely, defines a set of
values), can we go any further with the translation of the statement
y := sqr(inc(x))
After all, we would like it to be a single value, not a set (recall that
the relational image defines a set of values). As you will see in the
next section on functions, a relation is too general a structure to use
in this case.
26
Introduction to Formal Methods
Section 5.3 Functions
Functions are perhaps the most widely used of all the data models
in formal specification. They capture precisely the relationship
which exists between an entity and at most one other entity (for
example, the age of a person or the amount of free space left on a
storage device), and this is often sufficient. A relation allows a
possible many-to-many mapping, but its flexibility means that we
cannot rely on expressions such as sqr(inc(x)) returning a single
value.
Now read Potter, sections 5.3, 5.4 and 5.5
Subsection 5.3.1: partial and total functions
Potter presents partial functions before total functions because most
functions you will use in practice are partial – it is rare, except in
the definition of arithmetic operators such as the sqr function, to
come across total functions. Most uses of functions involve source
(and target) types which are basic types – that is, the specifier
defines them without enumeration. Since these basic types are ‘big
enough’ to contain as many elements as required, it is very unlikely
that the functions which have them as their source set will be
defined for all such values. To understand this, consider a model of
a telephone directory which can be represented as a function from
names to numbers. Suppose we define a basic type
SAQ 4.2
Attempt Potter, exercises 5.13, 5.14, 5.16, 5.17,
5.21 and 5.22
This is a long list of exercises, but you should find
each one quite straightforward.
Objective 9
27
Introduction to Formal Methods
[ NAME ]
to hold any particular name we might conceivably need. Then the
telephone directory can be defined as
directory: NAME N
At various stages in its use, the telephone directory will contain
some collection of names and their numbers, but at no time will the
set of names it contains be equivalent to the set of all possible
names which the type NAME holds. Hence it will be a partial
function.
Subsections 5.3.3, 5.3.4 and 5.3.5: an exotic collection of
functions
These sections are devoted to functions which are further
constrained in one way or another. Each has its own arrow, and the
whole collection is almost impossible to commit to memory! There
is really no need to memorise them all, as they can all be defined
from first principles by adding predicates to the basic function
definitions. The principal reason for the existence of this function
menagerie is to save having to write excessive predicates – the
function arrow itself embodies the predicate.
Section 5.4: operations on functions
The idea that relational operators can be used with functions is
correct. However, as is pointed out on page 105 of Potter, it is often
safer to use specialised function notation such as the override
operator, to prevent loss of the functional property.
Subsection 5.4.1 demonstrates the role of generic definitions in
formally defining operators such as override. The override
definition looks rather formidable at first, with its 4 arrow symbols
on the declarations line! However, use of brackets helps to make
clear which arrow is part of the override definition (the total
→
28
Introduction to Formal Methods
function arrow) and which arrows are part of the functions passed
in as input or produced as output (the 3 partial function arrows).
Section 5.5: lambda notation
Unless you are familiar with a functional programming language
such as Lisp, you will probably find the idea of a lambda function
rather strange, particularly since Potter does not show why it is
useful at this stage. Read the section once, then return to it when
you have read the next section.
SAQ 4.3
Attempt Potter, exercises 5.26 and 5.31.
Note that in exercise 5.26 where Potter refers to
‘works’, he means the relation ‘worksby’.
Objective 10
SAQ 4.4
Attempt Potter, exercises 5.47, 5.50 and 5.52.
In exercise 5.50, Potter uses the notation
shopprice’ to denote the changed state. You will
see later that ‘priming’ a variable by adding the ‘
symbol to its name is a common convention in Z
to represent the value of a variable after some
operation has been applied.
Objective 10
29
Introduction to Formal Methods
Now read Potter section 5.6
Subsection 5.6.2: operations on sequences
Just as we use function overriding instead of set union to add to or
modify a function, there is even more of a case for using specialised
sequence operators, for the reasons outlined at the bottom of page
114. It is all to easy to take two sequences and apply a perfectly
legitimate operation to them, yet produce a non-sequence!
The definition of the tail operator is a good example of the care that
is required when defining sequences. The tail of a sequence can be
obtained by shifting all the elements down one place. In formal
terms, this can be achieved by constructing the function whose
domain is the contiguous range of natural numbers between 1 and
the new length of the sequence, each of which maps on to the
element which is one place higher up the original sequence. The
lambda function in the definition on page 115 captures this
requirement, and provides the first serious use of such notation.
Recall from the discussion in section 5.5 that an expression such as
n:1..#s-1 • s(n+1)
is just the set { n : 1..#s-1 • n s(n+1) }, which is a well-formed
sequence describing the tail of a sequence. Note that this definition
SAQ 4.5
Sets have no order amongst elements and no
repetitions. Sequences are ordered, yet
sequences can be derived from sets. Is there a
contradiction? Where is the idea of order built in?
Objective 11
λ
→
30
Introduction to Formal Methods
is equivalent to the definition of tail on page 116 of Potter (can you
see why the two construct the same set?).
You can think of a lambda expression as defining an anonymous
function, which we wish to create for the specific purpose at hand
but which we do not wish to go to the trouble of naming.
Summary
This Unit has introduced the main body of discrete mathematical
objects which will be used in further specifications. You may have
reached the end of the Unit feeling overwhelmed by new notation!
The most important lesson of the Unit is the way in which relations,
functions and sequences are linked to sets and to each other. If you
understand that a function is just a special form of relation, and that
this is just a set of ordered pairs, then the notation required to
process becomes more easily assimilated.
This Unit completes the first theme of the Module: discrete
mathematics. Our attention now turns to the notation which is
unique to Z itself.
SAQ 4.6
Attempt Potter, exercises 5.60, 5.65 and 5.67.
Objective 11
31
Introduction to Formal Methods
Unit 5
Schemas
Unit Objectives
At the end of this unit you should be able to:
12 represent the abstract state of a system using schemas; and
13 use schemas to define operations.
Reading Material: Potter Chapter 6, up to and including section
6.4.
Introduction
Z really consists of two languages: the mathematical language and
the schema language. The former consists of standard ideas from
discrete mathematics – sets, relations, functions, sequences and so
on – expressed using the language of the predicate calculus. You
have met most of the mathematical language by this stage. The
other aspect of the Z notation, namely, the schema language, will
be introduced in this Unit and in the next. In fact, the idea that some
form of presentational mechanism is required to separate the formal
aspects of a specification from the textual commentary first
appeared in Unit 3, where axiomatic descriptions and generic
definitions were introduced. This Unit continues in the same way,
showing how both static aspects of a specification (what we might
think of as the system state – the collection of variables which
denote the data abstractions on which the model is built) and
dynamic aspects (the operations or procedures which access and
possibly modify the system state) can be presented using the device
of the schema box.
This is a short Unit, but you will use the notation introduced in all
subsequent specifications.
Now read Potter, Chapter 6, sections 6.1, 6.2
32
Introduction to Formal Methods
Section 6.1: schema notation
Note that the predicate part of a schema (the lower half) typically
contains expressions written over several lines. These are to be
treated as a conjunction of predicates, and convention allows the
‘and’ symbol to be omitted (Potter uses the term ‘elided’).
However, if what you want to say is expressed as anything other
than a conjunction, the relevant logical connective must appear.
For example, if you wish to use a disjunction of predicates, the ‘or’
symbol must be present.
A further point is that there is no implied ordering amongst parts of
the predicate, even though we are used to reading program code
sequentially. The various conjuncts could be written in any order
without changing the meaning. You will see later, however, that it
is sensible to present certain conjuncts – namely, those which
define the precondition of an operation – earlier than others.
You will find Potter’s data abstraction for the library given on page
124. Compare your solution to SAQ 5.1 with his model.
Now read Potter, Chapter 6, sections 6.3 and 6.4
∧
∨
SAQ 5.1
Sketch out some ideas about what data
abstractions might be used to model the library
system, whose requirements are outlined in
section 6.2 of Potter. In your answer, consider the
4 bulleted points at the top of page 122 and think
about how the principal models for data – sets,
relations, functions and sequences – might be
used to cater for the system requirements.
Objective 12
33
Introduction to Formal Methods
Section 6.3: schemas describing abstract states
The first non-trivial specification you write is likely to contain too
much detail. A good specification is posed at just the right level of
abstraction. It should be sufficiently detailed to allow the meaning
of the principal operations to be defined, but no more detailed than
this. When considering whether or not to add new components to
the system, ask yourself whether they materially alter any of the
operations. If not, it is probably best to leave them out. In fact, they
are not really ‘left out’, but can be considered as hidden away in a
basic type definition.
As an example, consider the decision as to whether it is worth not
only recording the names of library books but also their tables of
contents. The decision will rest on the need to access the list of
contents in any of our operations – it is conceivable that such a list
could form the basis for a keyword search procedure, for example.
Since the current list of requirements does not specify such a
procedure, it is safe to use the abstraction ‘book’, and say no more
about what such an entity consists of. Judging the right level of
abstraction can be quite difficult at first.
The Library schema on page 124 of Potter represents one set of
requirements. Others are possible too. For instance, issued could
be a relation from Reader to Copy, although I feel that it is generally
easier to deal with functions rather than relations. Do you agree
with this opinion?
SAQ 5.2(easy)
Express in words the difference in meaning
between the two predicates at the bottom of page
123.
Objective 5
34
Introduction to Formal Methods
The key idea expressed by the predicate part of the Library schema
– its invariant – is a statement of what must remain true throughout
the lifetime of the system. The Library schema is not just a
collection of the four named variables: the variables must obey the
predicate too. This presents us with an obligation: we must ensure
that any changes we make to those variables (adding a new reader,
for instance) maintains the invariant. You will see what this means
in practice later in this Unit when you meet the idea of specifying
operations using schemas.
Section 6.4: using schemas to define operations
The role of the invariant is captured in the Issue schema by making
explicit that the four parts of the predicate must be true both before
and after the operation to issue a book. As the author points out,
there are mechanisms (which you’ll meet in the next Unit) which
allow the specifier to hide details of the invariant (which, after all,
will be the same for all operations on the library state).
Potter discusses the question of what can be safely left out of the
predicate. He provides an informal argument to show that it is
possible to deduce certain information from the components of the
predicate, and that such information can be safely left out. If in
doubt, you should include such information, as it does no harm and
can help to make things clearer for the reader.
In order to formalise arguments or deductions, you will require
further conceptual tools which will be introduced in Units 8 and 9.
With such tools, we can explore other questions, such as: is the
SAQ 5.3
Attempt Potter, exercise 6.2.
Objective 12
35
Introduction to Formal Methods
predicate which accompanies Issue satisfiable? That is, is it possible
to find values of its component variables which make the predicate
true? It is to be hoped that it is, because otherwise the Issue
operation cannot be implemented!
SAQ 5.4
Attempt Potter, exercise 6.6.
Objective 13
36
Introduction to Formal Methods
Unit 6
The schema calculus
Unit Objectives
At the end of this unit you should be able to:
14 understand the role of the schema calculus;
15 use the schema calculus to create robust operations; and
16 calculate an operation’s precondition.
Reading Material: Potter Chapter 6, section 6.5.
Introduction
The previous Unit showed how schemas can be used in the
construction of both the system state and the operations upon that
state. In this Unit, you will discover that schemas can be used as
building blocks for specifications in a much wider sense, through
the use of the schema calculus – a set of notations which allow
schemas to interact with other schemas.
Of the various ideas covered in section 6.5, the most important are
schema inclusion, decoration, disjunction, conjunction and
composition. The other ideas, such as precondition and hiding,
have an enabling role in helping to define aspects of the schema
calculus, but are less often used in the specification process itself.
You should allocate your effort accordingly, ensuring in particular
that you are comfortable with the idea of schema decoration, since
virtually every specification you write from this moment will use
that idea.
Now read Potter, section 6.5
37
Introduction to Formal Methods
Subsection 6.5.1: schema inclusion
Schema inclusion is no more than a mechanism for including both
declarations and predicates of one schema within another.
Declaration parts of the two schemas are merged, whilst predicates
are conjoined. This has several uses in practice. Most frequently, it
is used to include the system state (see section 6.5.2 also), but the
example given on page 129 demonstrates its use in factoring a
multi-component system state into various parts. A word of
warning: if you decide to distribute the state in this way, it is very
easy to omit parts of the invariant.
Subsection 6.5.2: schema decoration
The and conventions introduced on page 131 will be used in
almost every operation schema you write from now on. The
simplest way to work out which is required is to ask yourself
whether any of the variables introduced by schema S are modified
by the operation. If so, you need to include S, otherwise – if you
really just require read access to all of the variables in S – use S.
If you do use the delta convention to introduce more than one
variable and its primed counterpart, you must state what happens
to each of those variables after the operation, even if they do not
change. For instance, in the Issue schema on page 131, it is
necessary to state that the stock and readers components do not
change, even though the schema inclusion is Library.
The symbol is usually pronounced “Xi” (say “kzee”) or “equiv”.
Potter mentions (on page 132) the possibility of using the and
conventions in a different fashion, and suggests that further
constraints can be added. A typical situation where this approach
would be effective is where the data model consists of many
variables, most of which are unchanged by the majority of the
operations. Rather than have to include lots of predicates stating
that the primed versions of these unchanging variables are identical
to the unprimed version in every operation schema, it is more
∆ Ξ
∆Ξ
∆
Ξ
∆ Ξ
38
Introduction to Formal Methods
convenient to place these equalities in the definition of the
schema.
In principle, the could be replaced by another symbol – after all,
use of such ‘decorations’ is only a convention. However, the
convention is almost universally applied, so it would be potentially
confusing to introduce a new symbol.
An alternative approach is illustrated by the StockTransaction
schema at the bottom of page 138. Here, Potter introduces a
schema which makes explicit which components can and cannot
change in the course of a stock transaction. Operations which
involve modification to the stock then utilise this schema. This
appears to be a sensible approach provided that it doe not result in
a proliferation of schema definitions for subsequent inclusion in
operations.
Incidentally, Potter has a habit of putting several predicates on the
same line, separated by a semi-colon. My own preference is to use
one line for each part of the predicate.
Subsections 6.5.3 and 6.5.4: schema disjunction and conjunction
When writing operation definitions in Z you should follow some of
the same guidelines that you would use when writing a procedure
∆
∆
SAQ 6.1
Attempt Potter, exercise 6.11. This is a good
example of a small specification and you should
spend some time thinking through your solution,
taking care to ensure that you have considered all
the relevant pre-conditions.
Objectives 13 and 14
39
Introduction to Formal Methods
or function in a programming language: don’t try to pack too much
into a single routine. If a problem can be sensibly decomposed,
then do so. You will often find that the resulting components can
be put together in different ways to create other functions.
Two of the more useful mechanisms to support this practice in Z are
schema disjunction and conjunction. In particular, schema
conjunction allows the splitting of a predicate amongst several
schema, whilst schema disjunction allows for a case-by-case
analysis. One of the main uses for these two devices is error-
handling, as exemplified by the material on pages 133-140.
Note that the symbols and , when applied to schema
names, are not the same as the logical operators with the same
symbols.
When using these operators, it is important to avoid name clashes.
If two variables have the same name in both schemas A and B, then
they must also have the same type, since in the conjunction
or disjunction they will be merged and hence refer to the
same object. If you need to use two schemas which deliberately use
the same variable name for different purposes, it is possible (as
we’ll see later) to rename one of the variables in order to avoid the
name clash problem.
You may wonder what is meant by the discussion mid-way down
page 138, where Potter justifies using stock rather than Library or
Library in the declaration part of AddCopyReport. His argument
could be made clearer by examining the effect of using Library,
which is what one might naturally consider since the
AddCopyReport operation does not modify the state. However, if
we do that, the AddCopy schema, which is defined as
AddCopy EnterNewCopy AddCopyReport
has an inconsistent (and unsatisfiable) predicate part, because it
contains predicates such as
∨ ∧
A B∧A B∨
∆Ξ
Ξ
≡ ∧
40
Introduction to Formal Methods
shelved ‘ = shelved {c}
and yet the Library decoration signals that
shelved ‘ = shelved.
Thus, it is not possible for us to use the Library convention. What
about the Library convention? This appears to work, because it
introduces no conflicting predicates. However, it might be
necessary to use AddCopyReport as part of the definition of another
schema, in which the Library inclusion is too liberal (that is, it
permits a state change where none was intended). Thus, the safest
approach is to include just the component required (in this case,
the variable stock).
Page 139 introduces the key concept of a total schema. We can
think of schemas which define operations as being total or partial
in the same way that functions are total or partial. A total schema
defines what happens in any possible circumstance, and is often
composed of several smaller schemas in a schema calculus
expression (such as those on page 139). In any complete
specification, all operation schema must be total.
Subsection 6.5.5 : schema negation
This subsection is mainly concerned with some technical
difficulties which arise with schema negation. It is worth reading for
its own sake as it will enrich your understanding of how types are
∪
Ξ
Ξ∆
∆
SAQ 6.2
Attempt Potter, exercise 6.16.
Objectives 13 and 15
41
Introduction to Formal Methods
related to one another, and because of the fine-grained alternative
Library specification on page 143.
Subsection 6.5.6: schema hiding operators
Schema hiding can be a useful mechanism for generating new
schema from old, as in the example given. However, its main
purpose in this Unit is to help in the definition of schema
composition.
Subsection 6.5.7: schema composition
The schema composition operator – or rather, the list of checks
detailed on page 147 – looks a little daunting at first, but the
underlying idea is straightforward. It might be helpful to think of a
sequence of programming language statements
A;
B;
and consider the effect on the program state – that is, its variables
– of executing first statement A, then statement B. After A is
executed, the program reaches some intermediate state, from
which it proceeds to a further state after B is executed. Now,
suppose we packaged these two lines of code into a procedure:
procedure P;
begin
A;
B;
End
Now, when P appears in a program, we don’t even consider the
intermediate state (P may be a library routine for which we have no
access to the source); in a sense, the intermediate state between the
execution of A and B is hidden from the programmer.
42
Introduction to Formal Methods
In a similar fashion, schema composition hides the intermediate
state. More precisely, the primed components of the first schema
become associated with the unprimed components of the second
schema. In order to make this work, there are a number of checks,
and these make up the bulk of page 147. Potter takes you through
an example showing in detail how these steps are applied. In
practice, at least for small and medium-sized specifications, there
are not many occasions where schema composition is applied,
mainly because most operations can be adequately captured
without the need for the sequential decomposition implied by
schema composition. If you find yourself making great use of this
operator, it may be because your specifications are too concrete –
that is, too implementation-oriented.
Subsection 6.5.8: schema preconditions
In the earlier discussion of total schemas, it was assumed that we
could somehow identify those schemas which were partial. To
formalise this, we have to state precisely what the precondition of
a given schema is. Section 5.6.8 describes how to do this. The first
step is easy: we simply existentially quantify all the primed
components and the outputs over the schema predicate.
Unfortunately, it is not always simple to comprehend the resulting
expression, so the next step is to attempt a simplification, which we
hope will reveal the true nature of the precondition. Having done
that, it is usually relatively straightforward to determine whether or
not some collections of schemas together represent a total schema
(a simple example of this process is given in the next Unit).
The example of precondition calculation and simplification for the
Issue operation is quite tricky: you may need to read this several
times before the method becomes clear. Note that we are engaged
in a different form of formal activity here: rather than writing down
– defining – systems, we are attempting to reason with the
specification. This can be a more arduous task, and is the subject
of Units 8 and 9.
43
Introduction to Formal Methods
Potter mentions some textbooks for further study. Whilst these texts
are valuable, some of them are 7 years old: a more recent selection
is given in the Bibliography to this Module.
SAQ 6.3
Attempt Potter, exercise 6.23.
Objective 16
44
Introduction to Formal Methods
Unit 7
A complete specification
Unit Objectives
At the end of this unit you should be able to:
17 read realistic specifications written in the Z notation; and
18 demonstrate how to structure a specification document.
Reading Material: Potter Chapter 7.
Introduction
This Unit develops a relatively complex specification from first
principles. You may feel that Potter introduces rather too much
complexity in section 7.1.2 in defining alphabetic orders. Potter is
really attempting to accomplish two tasks in this chapter. First, he
presents a specification of the word-for-word system (which
consists of two subsystems – one dealing with the ‘dictionary’
aspects, the other with student performance in translation tests).
Second, he shows how useful background theory can be
developed. Typically, the theory will be much more difficult to
write and, sometimes, to read. It is worth remembering that the
theory needs to be written only once, then the specifications which
rely on it can be applied in many different specifications. Further,
it is not necessary to fully understand the intricacies of the theory
in order to apply it. A useful analogy is with the role of modules or
code libraries, which provide re-usable facilities without the user
needing to be aware of implementation details.
For these reasons, I suggest that you omit section 7.1.2 on a first
reading, or read sufficient to get the idea of an alphabetic order so
that the operations in later subsections make sense.
Now read Potter, chapter 7, and re-read Potter, chapter 3
45
Introduction to Formal Methods
Section 7.1: the vocabulary system
Potter introduces the idea of orthographic rules, the purpose of
which is “to eliminate as far as possible the addition to the
vocabulary of words which could not possibly belong to the
respective languages”. My feeling is that these represent an
unnecessary complication for a first specification.
The definition of percent on page 159 demonstrates that whilst it is
possible to define fairly simple arithmetic operators in Z, it is not
always the case that the definition is shorter than an
implementation. Of course, the percent function belongs in a
library of useful functions, although Z is not yet sufficiently mature
for such libraries to have been built and widely applied.
After this introduction, the definition of the abstract state on page
162 is pretty straightforward. In fact, it consists simply of a relation
between native and foreign words: the two named sets are present
simply as a convenience as they could be calculated from the
relation. The other part of the system, the student’s record of
progress, allows for the modelling of a single student. Again, only
two of the three components are strictly required, since
AveragePercent is derived from the other two. The inclusion of
components which could be considered superfluous is a matter of
personal preference. My own taste is for minimal schema,
declaring as few variables as are required. However, if a derived
component is required on several occasions in the rest of the
specification, it is probably worth defining it as a separate state
component as Potter has done here.
The EnterPair schema in subsection 7.1.5 illustrates one advantage
of separating the abstract state into several components (here,
WellFormedVocab and RecordOfProgress). Each schema inclusion
can be given a separate decoration reflecting whether or not its
components are liable to be changed by the operation. Thus,
entering a new pair of words cannot alter the student’s record of
progress, so RecordOfProgress is included with the decoration.Ξ
46
Introduction to Formal Methods
In VocabTestNtoF on page 165, you may be wondering why the
variable Translations is hidden in the schema definition. The
answer is that it is not a state component, and neither is it an input
or output variable. It is a convenient ‘internal’ variable, which we
would normally write by existentially quantifying it in the predicate
part of the schema. However, since the schema definition is split
across three schemas, this is not possible, so it is existentially
quantified outside the three schemas. This is precisely what schema
hiding means (refer back to its definition on page 145).
Potter seemed to be having a bad day when he wrote this chapter -
there are very few mistakes in the book, but there are two errors on
page 165 alone, and some lesser slips of the pen elsewhere in this
chapter. One notational mistake is in the definition of
VocabTestNtoF, where the variable translations is surrounded by
ordinary brackets - these should be set brackets: the expression
should read:
VocabTestNtoF
SelectTestWordN
CheckResponseF
UpdateScoreNtoF
\ { Translation }
The second mistake is in the declaration of Translations in
UpdateScoreNtoF, where it is declared to be of type set of
OrthoNative; it should be of type set of OrthoForeign.
Schema RequestNativeDict on page 166 is defined in terms of the
NativeDict schema, which in turn requires part of the alphabetic
order theory defined in section 7.1.2. If you have not yet read that
section, now might be a good time to glance at it, in order that you
have a reasonable idea of what the SetInForeignWordOrder
function does. Alternatively, skip that section and be content with
the intuitive explanation of this function - which is simply to put the
set of words given as its argument into the correct alphabetic
ordering for the language - in this case, the foreign language.
≡
∧∧
47
Introduction to Formal Methods
Subsections 7.1.6 and 7.1.7 are probably the most useful sections
of this chapter, since they define a procedure which you will want
to follow virtually every time you write a system specification.
Error-handling is extremely important: as was stressed earlier, it is
vital to ensure that every schema operation you produce is total. In
particular, tabulating operations and their preconditions as shown
in Table 7.1 of Potter is common practice. Having determined the
preconditions (which, for more complex examples might require
precondition calculation via formal reasoning, as introduced in the
previous Unit), error schemas can be written in such a way that,
when conjoined with the partial schemas, every possible
eventuality is safely covered.
Section 7.2: the structure of specification documents
This section contains some good advice about the structure of
specification documents. It should be stressed that there is no
definitive ordering of components in a Z specification, except
perhaps for the general rule that objects should be defined before
use.Of course, there may be a difference between the presentation
order and the order in which the parts of the specification are
developed. For example, it is difficult to define the abstract states of
the system without some consideration of what operations are
required, because these operations give an indication of what
degree of abstraction is sufficient. Recall the maxim that a
specification should be as abstract as possible given the constraints
imposed by the operations.
You might disagree with Potter over his ordering of specification
components given on page 171. I would prefer to see step (b) –
presentation of general theory required for the specification –
relegated to an appendix. Such theory is important, but its inclusion
early on in a specification document can disrupt the flow of the
specification, as you will have experienced in the current chapter.
When you have had more practice at writing specifications, you
will no doubt form your own ideas about the relative difficulty of
48
Introduction to Formal Methods
each part of the process. Leaving aside the development of the
underlying theory, my experience has been that part (c) -
description of abstract states - is the most crucial stage of all. With
a suitably chosen state, operations can be relatively straightforward
to specify. If you find that you are struggling to express what you
mean by a given operation, you may wish to reconsider the state
you have chosen.
There is no SAQ for this Unit; you have completed one of the
objectives if you have read and understood the specification. The
second objective will be tested on your assignment, which involves
producing a complete specification.
49
Introduction to Formal Methods
Unit 8
An introduction to reasoning with specifications
Unit Objectives
At the end of this unit you should be able to:
19 state formally the properties of a system as theorems.
Reading Material: Potter Chapter 8, up to and including Section
8.4
Introduction
The material contained in chapter 8 is split over the next two Units
of this module. In Unit 8, your aim is to become familiar with the
concept of proof and how this idea is useful and applicable to
formal specifications. In Unit 9, the bulk of the framework for
reasoning with propositions and predicates is introduced. You will
revisit the specification introduced in the current Unit, but with the
tools of reasoning to make the process of proving properties of that
specification more formal.
The purpose of a formal specification
Some software engineers regard the act of thinking formally about
the meaning of a software system sufficiently useful in itself – and
they are right to do so. The rigour imposed by the language of
predicate calculus means that sloppy thought will often be
discarded at an early stage, and inconsistencies or ambiguities in a
client’s requirements stand a better chance of being uncovered by
the process of translating them into the hard-edged world of logic.
This alone can save much time and anguish later on when the cost
of correcting such mistakes – even assuming they are discovered at
all – is far greater than it would be if they had been found during
system specification.
50
Introduction to Formal Methods
But it is possible to go further with a formal notation based on
predicates. It is possible to reason about the system, to prove that
certain properties hold, or to demonstrate formally that some
unwanted situation will not occur. And of greater importance still
is the potential to continue the design process – all the way to
implementation – without sacrificing formality at any stage. It must
be stressed that this latter idea is still some way from practical
application, but the formal framework is currently being assembled
and pressed into use with larger case studies.
The act of proving that certain properties hold is part of the
validation process – the properties may have been informally stated
in the requirements analysis stage. The act of proving that code
meets its specification is verification. Traditionally, validation and
verification have proceeded without formal specifications, but it is
clear that the existence of such a specification can greatly aid these
important aspects of software engineering.
During this Module, you may have got the impression that you
were learning to use the Z notation to the exclusion of all else.
However, what you have really been doing is picking up a lot of
generally-useful discrete mathematics and logic. In fact, it is
possible to see Z as being no more than a convenient harness for
these ideas. And so it is with chapter 8 of Potter. The material
contained here will be useful well outside the confines of Z itself.
Proof is a key skill in all branches of mathematics and it is rather
unfortunate that all programmers are not more familiar with it!
Now read Potter, Chapter 8, sections 8.1-8.4
In section 8.1 on page 177, you encountered the theorem:
Library shelved = dom stock \ dom issued
which is expanded further down the same page to a form which
includes many statements on the left hand side of the turnstile
symbol.
51
Introduction to Formal Methods
A first impression of such statements is that they represent
something quite formidable. This is not the case! Think of the
expressions on the left hand side as being your weapons in the
proof – the more you have, the better. You may not need to use
them all. If, on the other hand, you find that you have an imbalance
in the other direction – that is, more expressions on the right of the
turnstile symbol – then beware! Your job is to prove all of the
expressions on the right hand side, which is a much harder task.
Having said this, size is no reliable guide to difficulty. You may
recognise the innocent-looking theorem below:
x,y,z,n: N
This famous statement is Fermat’s last conjecture, which has eluded
proof for over 200 years. The recent claim to have proved it turned
out to be false. Needless to say, the proofs you will encounter in
this Module are rather less taxing!
Subsection 8.3.1: the initialisation theorem
The initialisation theorem takes the same form regardless of the
specification: it says ‘there must exist some initial state satisfying
the invariant’. The first step is to ensure that your specification
contains an initialisation schema! Then, it is often a simple matter
to show that such a state exists, since initialisation typically reduces
all components to empty set, sequences, functions and the like.
When expanding a statement of this theorem, do not forget to
include the invariant on the state after components, since the whole
∃¬ n 2> • xn yn+ zn=
SAQ 8.1
Attempt Potter, exercise 8.1.
Objective 19
52
Introduction to Formal Methods
purpose of the initialisation theorem is to ensure that a state
meeting the invariant actually exists.
Subsection 8.3.2: precondition simplification
In earlier Units, you have met the idea that it is sometimes
necessary to calculate preconditions, by existentially quantifying
state after components and outputs. Such existentially-quantified
expressions are often not in their simplest form, and it is usually
easier to decide what other schemas are required to make schemas
total if we can find a simpler expression for the precondition.
Simplification is another role for formal reasoning, as suggested at
the end of subsection 8.3.2.
Subsection 8.3.3: properties of a specification
When you write a specification, various properties which you think
the specification obeys will suggest themselves to you. It is
worthwhile recording such properties and formulating them as
conjectures to be proved. As Potter explains, these properties can
also come from the set of requirements, or from a review process.
Each property could also form the basis for a set of test cases for the
final implementation, in which case it is well worth the effort
attempting a formal proof beforehand.
In methods such as Z, properties are seen as secondary aspects of
a specification – that is, whilst it is important to be able to state and
SAQ 8.2
Attempt Potter, exercise 8.3.
Use the definition of the Library schema on page
176 of Potter in your solution.
Objective 19
53
Introduction to Formal Methods
prove properties, the core of the specification itself is defined by the
schemas. The following subsection briefly introduces an alternative
view of specification in which properties have a more central role.
Model-based and property-oriented approaches to specification
The style of specification embodied in Z is often called a model-
based approach, because there is always a data model on which
the operations act. For example, the Library schema represents
such a model.
There are other approaches to formal specification, one of which is
the property-oriented method. In a property-oriented specification
technique, operations are defined in terms of other operations,
usually via equations. As an example, a property-oriented
definition of a stack would involve operations such as pop and
push, and would be defined by equations such as this:
pop(push(s,el)) = s
where s is a stack and el is an element of the stack. This equation
says that the effect of pushing an element on to a stack s, then
popping the resultant stack, is to produce the original stack s. It may
not be obvious from this example, but such equations serve to
define pop and push (other equations may be necessary to
complete the definition).
Contrast this with the Z approach, which would be to define a
model for a stack, typically as a sequence of elements. Then, a pop
operation would use the tail operator on sequences to define its
results, whilst a push operation would use sequence
concatenation. There is a completely different style in the two
approaches. The property-oriented method is characterised by the
absence of a data model – the model is defined totally by the
operations.
54
Introduction to Formal Methods
The reason for this aside is to suggest that one mechanism for
deriving properties of a specification is to attempt a property-
oriented approach, then use the resulting properties as conjectures
to be proved. In other words, property and model based
approaches can be seen as complementary in the quest for reliable
software.
OBJ and Clear are two examples of property-oriented languages for
specification.
SAQ 8.3
Attempt Potter, exercise 8.6.
Objective 19
55
Introduction to Formal Methods
Unit 9
Reasoning with propositions and predicates
At the end of this unit you should be able to:
20 construct proofs involving propositions and predicates; and
21 prove properties of a specification.
Reading Material: Potter Chapter 8, sections 8.5, 8.6 and 8.7
Introduction
This Unit introduces a great many laws for rewriting and
simplifying propositions and predicates. You do not have to
remember all of these laws! The purpose of the Unit is to give you
experience in real proofs. Some of the proofs are quite difficult to
generate at first. After all, at every step in the proof there are a great
many possibilities for the next step. We can view proof as a search
process in which you are guided only by your intuitions. These
intuitions will be strengthened through practice.
Now read Potter, Chapter 8, section 8.5
You have already met the method of truth tables. This is a very basic
form of proof, but, as Potter explains, it is more efficient to use a
collection of equivalences directly (the basic equivalences
themselves would be demonstrated using truth tables, but others
would be derived from these without recourse to truth tables).
One important distinction, drawn on page 189, is between an
equivalence and a deduction. Whilst an equivalence between two
expressions allows them to be used interchangeably, a deduction
works in one direction only. Make sure you understand this
distinction before attempting the exercises.
The collection of propositional laws gathered together in
subsection 8.5.1 are mainly ‘statements of the obvious’, but,
56
Introduction to Formal Methods
because they are expressed in terms of variables p and q, you may
find them difficult to interpret at first. If you are having difficulty
seeing why one of the laws is true, try substituting some real-world
expressions for the propositional quantities p, q etc. For example,
the truth of the law for elimination of implication,
E
can be more easily seen by replacing p by the statement “logic is
easy” and q by the statement “formal methods is easy”. Then, if we
know that the implication “logic is easy formal methods is
easy” is true, and we also know that “logic is easy” is true, we can
deduce that “formal methods is easy” is also true. I leave it up to
you to judge whether these propositions are indeed true!
Incidentally, Potter does not really stress that the names of the laws
are meant to be meaningful: thus, a law such as E1 is meant to
be read as the “first ‘and’ elimination law”, whilst I2 is the
“second ‘or’ introduction law”. This naming convention is not
universal amongst mathematicians, but it, or something quite close
to the convention, is gaining popularity amongst computer
scientists.
By the time you reach the example proofs on page 193, you could
be forgiven for thinking that there is really no limit to the number
of laws. This is true! However, most of the laws, or equivalences,
are of little use (one could argue similarly that there are infinitely
many syntactically-valid programs, most of which are of no
conceivable value).
Proof number 4 on page 194 is an interesting derivation, and
illustrates the I law which Potter comments upon in the last
paragraph of page 191. This differs from previous proofs in the
chapter in that it uses an assumption (in step 2) which serves only
as a mechanism for introducing the implication in step 5. The
reasoning is this: if we assume p and can show that q is true based
on this assumption, then we can clearly assert that p q, since
p q⇒ p,q
⇒
⇒
∧∨
⇒
⇒
57
Introduction to Formal Methods
this is the same as saying “if p, then q”. Note that p need not be true
for this line of reasoning to be valid; in this sense, introducing p in
step 2 is quite different from valid deductions introduced
elsewhere, and it is for this reason that it is clearly marked as an
assumption.
Example proof 5 on the same page illustrates a different challenge.
Here, we are asked to simplify an expression, but we do not know
if there is a simplification. This, as Potter points out, is akin to the
situation we find ourselves in with precondition calculation, where
we wish to simplify an expression. Examples of this kind
demonstrate the seemingly large number of different paths that a
proof can take. A partial answer to this problem is to use an
automatic proof generator, although, as we will see later in this
Unit, there are problems with that approach too.
Check your solutions to SAQ 9.1 before proceeding. You may have
found the exercises in this SAQ getting progressively more difficult,
but at the same time you will no doubt have gained confidence and
intuition into the way a proof can be constructed.
All of the examples so far have involved propositions. In this Unit,
there has been no mention yet of predicates, nor indeed of the
discrete mathematical abstractions such as set and functions of
SAQ 9.1
Attempt Potter, exercises 8.8, 8.10, 8.12 and
8.14. You may find that it takes you some time to
find solutions to these questions. My advice is to
be persistent – once you discover a teachnique
that works for one example, you will probably
find that it works for the others too.
Objective 20
58
Introduction to Formal Methods
which we construct our specifications. Can we reason formally
with these too? The next section answers this question.
Now read Potter, Chapter 8, section 8.6
Potter explains why reasoning with predicates is more difficult than
the propositional arguments you met in the previous section. The
key statement is “when we use quantifiers, there is no universally
applicable method of determining whether a theorem can be
proved or disproved”. In other words, when you set out on a task
of formal reasoning with predicates, you cannot be sure that it is
possible to reach your target, regardless of your own abilities. This
explains why we cannot build automatic proof-generators which
are guaranteed to terminate for predicates.
This seems like bad news. But, like many theoretical results, it says
little about the sorts of proofs we need to carry out in practice. Very
often, you set out to prove something which you firmly believe to
be true, and hence feel that it is worth the effort finding the proof.
Very rarely would you attempt to prove a theorem which you felt
to be false (unless you could demonstrate its falsity fairly easily
using the method of proof-by-contradiction).
There are two technicalities – variable binding and substitution –
which Potter covers prior to explaining the predicate laws. It is
worth spending some time grasping the need for these
technicalities, because virtually all the laws for predicates from
page 200 onwards use substitution and binding in their definitions.
Since these are tricky ideas the first time you meet them, it is worth
considering some of these laws in more detail, starting with the
specialisation law, SP:
SP
Recall that the notation means that all free occurrences of
x in predicate p are replaced by t. The specialisation law states that,
if a predicate p holds for all x (of type T), and we are told that t is of
x:T p•∀( ) t T∈,p t x⁄[ ]
p t x⁄[ ]
59
Introduction to Formal Methods
type T, then we can state that the predicate holds when x is
replaced by t. This seems entirely reasonable.
The other law worth considering further is the ‘One Point Rule’:
(x\t)
Don’t confuse the (x\t) notation, which means x is not free in t, with
the substitution notation p[t/x] , which means that x is replaced by t
in predicate p.
The One Point Rule, which is immensely useful in simplifying
existentially-bound expressions, allows us to remove the
quantification of a variable if that variable has a value associated
with it in the bound predicate. For example, if we had a statement
of the form “there exists some variable x which has the value 21
and satisfies some predicate p”, then we could equivalently say that
“the value 21 satisfies some predicate p”.
There appears to be a mistake in example 1 in subsection 8.6.4.
Potter claims to be proving an equivalence (denoted by the double
horizontal line). However, his proof is a derivation, not an
equivalence. For example, step 3 uses quantifier law Q7, which is
not an equivalence.
Now read Potter, Chapter 8, sections 8.7 and 8.8
Several laws are introduced in section 8.7. They will be required for
the practical proofs in section 8.8. I would advise you to do no
x:S p x=t∧( )•∃t S∈ p t x⁄[ ]∧
SAQ 9.2
Attempt Potter, exercises 8.15, 8.19.
Objective 20
60
Introduction to Formal Methods
more than convince yourself that each law is reasonable. You
should certainly not attempt to memorise all these laws, as I have
stressed elsewhere! [Note the textual error midway down page 206,
where the phrase “L9 to laws!L12” should, I imagine, read “laws L9
to L12”].
The proof of L12, which occupies roughly a page, demonstrates a
fully-formal proof, such as would be accepted by an automatic
proof-checking program, which requires every detailed step to be
justified.
Page 210 demonstrates the usefulness of the One Point Rule in
practical situations, such as proving an initialisation theorem. The
same rule is also applied later in precondition simplification. These
examples should convince you that it is worth fully understanding
this rule. If necessary, you should go back to study its definition on
page 200 until you are confident of the law.
Subsection 8.8.3 gives an example of a common property which
arises in specifications, namely, that when an operation exists to
add some entity to the state, and another operation exists to remove
an entity from the state, then performing these operations in
sequence leaves the state unchanged. It is worth looking out for this
property in any specifications you write, and then attempting the
proof. You will almost certainly pick up any errors in your
specification in this manner.
Note, at the top of page 215, that if we are to interpret a schema
name on the RHS of a theorem as a predicate, all of the variables it
declares must be in scope. This requires a check that all such
variables are declared on the LHS of the theorem.
On page 215, mid-way down the page, there is a slight error. The
function definition in the second line of the theorem should use ID,
not Id.
61
Introduction to Formal Methods
SAQ 9.3
Attempt Potter, exercises 8.21 and 8.23. This is
quite difficult, but is the last SAQ in the whole
Module, so if you have reached here, well done!
Objective 21
62
Introduction to Formal Methods
Bibliography
Note that these texts are for background reading only and do not
cover any new areas which will be examined.
I.Hayes (ed.), Specification case studies, Prentice Hall International
Series in Computer Science, 1987. (2nd ed., 1993)
J.M.Spivey, Understanding Z: a specification language and its
formal semantics, Cambridge University Press, 1988.
D.Ince, An introduction to discrete mathematics and formal system
specification, Oxford University Press, 1988.
J.C.P.Woodcock & M.Loomes, Software engineering mathematics,
Pitman, 1988.
J.M.Spivey, The Z notation: a reference manual, Prentice Hall
International Series in Computer Science, 1989. (2nd ed., 1992).
This is the de facto standard for the Z notation.
A.Diller, Z: an introduction to formal methods, Wiley, 1990.
D.Lightfoot, Formal specification using Z, MacMillan, 1991.
A.Norcliffe & G.Slater, Mathematics for software construction, Ellis
Horwood, 1991.
M.Imperato, An introduction to Z , Chartwell-Bratt, 1991.
J.B.Wordsworth, Software development with Z, Addison-Wesley,
1992.
M.McMorran & S.Powell, Z guide for beginners, Blackwell
Scientific, 1993.
63
Introduction to Formal Methods
Biographical Notes: Martin Cooke
Currently a Reader in Computer Science at the University of
Sheffield, I teach courses on formal methods, software engineering
and computer speech & hearing. Following my BSc in Computer
Science and Mathematics from the University of Manchester, I
spend several years at the National Physical Laboratory as a
research scientist studying automatic speech recognition. I joined
the Department of Computer Science at Sheffield in 1986,
completing a PhD in auditory scene analysis in 1991. I have
published in both computational hearing and software engineering,
and am the author of Modelling Auditory Processing and
Organisation (Cambridge, 1993), and co-editor of Visual
Representations of Speech Signals (Wiley, 1993).
64
Introduction to Formal Methods
Solutions to self assessment questions
(question numbers in italics refer to Potter)
SAQ 1.1
There are likely to be at least four main sources of error in any
system which is poorly specified:
• errors in the way data is represented by the system;• errors in the operation or functioning of the system;• errors in the control of access to the system; and• errors in the way the system handles exceptional conditions.
In each case, identification and rectification of faults is a costly
process.
Some potential consequences of errors for the three types of system
are listed in the table. You will no doubt be able to think of many
more. Most textbooks on formal methods include a selection of
actual consequences of such errors. For example, a period instead
of a comma in a loop statement was responsible for sending a
Venus space probe on to the wrong course – it was never seen
again.
65
Introduction to Formal Methods
SAQ 1.2
(i) Whilst it is true that formal methods cannot guarantee perfection,
it is claimed that they enable errors to be spotted earlier in the
development cycle, thereby reducing the cost of fixing them. There
is something of a tradeoff between errors made in applying formal
techniques and the possibility of uncovering errors through their
use. The advent of automatic theorem proving tools is helping to
take the tedium out of carrying out proofs.
system possible consequences
public transport scheduling sys-tem
disruption to a public service;disruption to traffic flows, particularly in congested areas; andloss of revenue to the transport companies, either as a result of loss of custom or errors in customer charging.
aircraft control system
a serious threat to the life of aircraft passen-gers and crew, resulting from erroneous sys-tem readings – leading crew to misinterpret flying conditions – or an erroneous physical response in the aircraft – leading to loss of control;an increase in the stress placed on the air-craft as a result of flight behaviour which does not match flying conditions; andan increase in the cost of aircraft mainte-nance.
banking system inappropriate access to funds and accounts by unauthorised users and users who have exceeded credit limits;an impaired ability to detect evidence of fraud or theft from the bank; andinaccuracy of data regarding account bal-ances and transactions, which may lead to erroneous management decisions, customer bankruptcy and loss of revenue to the bank.
66
Introduction to Formal Methods
Formal methods enable the systems analyst or software engineer to
describe the requirements of a system in a notation which is both
concise and unambiguous. The use of such a notation demands
clarity of thought and attention to detail which may be overlooked
in structured methods.
Formal methods allow the construction of a specification which is
internally consistent, has logical properties that can be rigorously
tested and subjected to informal or formal proof. Analysts and
system users can reason with formally produced specifications,
thereby demonstrating that a system has the properties required of
it before the system is actually built.
(ii) It is true that the program code expresses precisely the meaning
of a system. In fact, programming language semantics is a well-
researched area. However, the semantics of a piece of code
developed in an arbitrary (that is, non-formal) fashion are usually
much more complex than the formal specification, or any code
developed formally from that specification. At first meeting formal
notations, many software engineers imagine that they are more
complicated than code, but this is not the case. Code is a much
more cumbersome formal language than logic, for instance, which
is one explanation why it is difficult to reason with code.
Despite the fact that code does express meaning, it is not sufficient
on its own as a specification of a system, because, in order to say
whether a piece of code is correct, we have to possess some
external reference so that we can argue that the code is correct with
respect to that reference. A formal specification is a suitable
reference. Think about it this way: trivially, code is always correct
with respect to itself, so we need something else to measure
correctness by.
67
Introduction to Formal Methods
SAQ 2.1
ex. 2.1
(i) { Finland, Sweden }
(ii) { Belgium, France, West Germany, Italy, Luxembourg,
Holland, Denmark, Greece, Ireland, UK, Spain, Portugal }
(since all the Benelux countries are in the EEC, the answer is
equal to EEC).
(iii) { France, West Germany, Italy, Denmark, Greece, Ireland,
UK, Spain, Portugal }
(iv)
(v) { Denmark, Norway, Iceland }
(vi)
(vii) { Denmark }
(viii) { Denmark }
(ix) { Belgium, France, West Germany, Italy, Luxembourg,
Holland, Denmark, Greece, Ireland, UK, Spain, Portugal,
Finland, Norway, Sweden, Iceland, Canada, US, Turkey }
(x) same as (ix)
SAQ 2.2
ex. 2.5
(i) AWYZBU
(ii) UVYX
(iii) AWYVU
(iv) BZYXU
(v) WVUXY
(vi) WVUXY
(vii) AWVXZBU
(viii) AWVXZBU
SAQ 2.3
a. proposition
b. proposition (even though it is false)
∅
∅
68
Introduction to Formal Methods
c. predicate (the answer depends on the value of x)
d. this is a paradox! (see the discussion on
pages 53-54 of Potter).
e. proposition
f. neither – it is a question.
g. proposition (a false one)
h. predicate (the answer depends on x)
i. proposition (this one is tricky - the statement
is false regardless of the value of x)
SAQ 2.4
ex 2.6; just part (i) is shown below – the others are very similar.
Use truth tables to show that the value of the LHS is equivalent to
the RHS for all combinations of and . For example,
p q
T T T T
T F F F
F T T T
F F T T
p q
p q⇒ p¬ q∨
69
Introduction to Formal Methods
SAQ 2.5
ex. 2.12
(i) g: girl • g is nice g loves a sailor.
(ii) ( o: object • o glisters o is gold)
or, equivalently,
o: object • o glisters o is gold
(you will meet a law stating this equivalence in Unit 9)
(iii) c: capital •Paris is more romantic than c
(iv) r: region • r in Asia c: country •
c in Europe 5*rainfall in c > rainfall in r
(v) c1: country •c1 in South America c2: country •
c2 in EEC inflation in c2 > inflation in c1
(vi) oldest, youngest: person •oldest attends Spanishyoungest attends Spanishage of youngest < 4 * age of oldest
p: person •p attends Spanishage of p < age of oldest age of p > age of youngest
SAQ 2.6
ex 2.14
The first proposition can be stated as “every child has at least one
parent”, whilst the second means “there is a person who is the
parent of every child”. The second is clearly ludicrous!
∀ ⇒
¬ ∀ ⇒
∃ ∧ ¬
∀c Paris≠ ⇒
∃∧ ¬ ∃
∧
∀⇒ ¬ ∃
∧
∃∧
∧∧
∀⇒
∧
70
Introduction to Formal Methods
The stronger is the second proposition, because if there is a person
who is the parent of every child, then it clearly is the case that every
child has at least one parent.
Generally, we can reverse the order of two quantifications if neither
is stronger than the other. Can you think of an example?
SAQ 3.1
ex. 4.1
(i) { , {0} , {1} , {0,1} }
(ii) { }
(iii) { , { } }
(iv) { , { } , {{1}} , { , {1} } }
ex. 4.3
The powerset of a set containing n members has members
(hence the name powerset).
ex. 4.6
(i) P Z
(ii) Z
(iii) P P Z
(iv) This has no type which can be constructed using powersets.
ex. 4.7
(i) Not correctly typed, because the first element is a set containing
a set, whilst the second element is a simple set.
∅
∅
∅ ∅
∅ ∅ ∅
2n
71
Introduction to Formal Methods
(ii) This is fine, and expresses the truth that “for all integers, it is
always possible to find at least one larger integer”.
(iii) This is incorrectly typed, because the expression y = x - 1
involves a left hand side whose type is OUTPUT, and a right hand
side expression whose type is integer.
SAQ 3.2
ex. 4.10
(i) (red, red) (red, blue) (blue, red) (blue, blue)
(ii) ( {round}, {round} )
(iii) (red,{round}) (blue,{round})
(iv) ({round}, red) ({round}, blue)
(v) P X is { , {red}, {blue} , {red,blue} }P Y is { , {{round}} }so (P X) x (P Y) is
{ ( , ) , ( , {{round}} ) ( {red}, ) , ( {red}, {{round}} ) ( {blue}, ) , ( {blue}, {{round}} ) ( {red,blue}, ) , ( {red,blue}, {{round}} ) }
(vi) Using the answer to part (iii) above, P ( X x Y ) is{ ,
{ (red, {round}) } , { (blue , {round}) } , { (red, {round}), (blue, {round}) } }
∅∅
∅ ∅ ∅∅
∅∅
∅
72
Introduction to Formal Methods
(vii) P Y is { , {{round}} }; hence
P P Y is
{ , { }, {{{round}}}, { , {{round}} } }
so (P P Y) x X is
{ ( , red), ( , blue )( { } , red) , ( { }, blue )( {{{round}}} , red ) , ( {{{round}}} , blue )( { , {{round}} } , red) , ( { , {{round}} } , blue) }
ex. 4.11
The answer - which should be painfully obvious if you have
managed to answer the previous question - is n x m.
ex. 4.12
(i) Z x P Z
(ii) (Z x Z) x Z
(iii) P Z x (Z x Z)
(iv) The first element is of type P ? x P Z, where the question mark
indicates that we do not know what type of empty set is required.
The 2nd element is of type (P (Z x Z)) x P Z
Thus, the overall type is P ( (P (Z x Z)) x P Z), since we can assume
that the empty set in the first element is of type Z x Z. If we do not
make this assumption, the expression is incorrectly typed.
∅
∅ ∅ ∅
∅ ∅∅ ∅
∅ ∅
73
Introduction to Formal Methods
SAQ 3.3
ex. 4.22
(i) { | }
(ii) { | }
(iii) { | }
(iv) { • }
SAQ 3.4
ex. 4.24
(i)
(ii)
[COLOUR]
| green : COLOUR
(iii)
i: Z 1 i 5≤ ≤ i{ }•
i j: S, i j≠ i j,( )•
i j:Z, 1 j 8≤ ≤ i j 9=+∧ i j,( )•
i: N i 3×
evensize: P Z
m: N • #evensize = 2m∃
notgreen: COLOUR
notgreen green≠
relatedpair : Z x P Z
first relatedpair second relatedpair∈
74
Introduction to Formal Methods
ex. 4.25
(i) origin == (0,0)
(ii) bignumbers == { x: Z | x > 1000000 }
(iii) incpair == { x: Z • (x,x+1) }
(iv) [WIDGET]
| widget1, widget2: WIDGET
notwidget == { x : WIDGET | x { widget1, widget2 } }
SAQ 3.5
ex. 4.30
(i) (-1,0)
(ii) ( {-1}, 0 )
(iii) ( (-1,1), 0 )
∉
zeropair : P (X x Z)
x: X x 0,( ) zeropair∈•∀
[X]
75
Introduction to Formal Methods
SAQ 4.1
ex. 5.3
(i) Since == P ( A x B ), then it is
P ( { (0,blue), (0,green), (1,blue), (1,green) } )
which, as you will know by now, has 16 members. I won't write it
out in full, but some of these members are:
{}{ (0,blue) }{ (0,blue), (1,green) }
In other words, when we define a variable to be of type , we
are allowing it to take on any of the 16 values (in this case) in the
powerset.
(ii) Recall that [A] is the empty set of type A, so
[A] <-> [A] == P ( [A] x [A] ) == P ( [A] ) == { [A] }
(iii)
ex. 5.5
(i) dom plays = { Askenazy,Williams, David, Huw , Alice, Kate }dom worksby =
{ piano, guitar, harpsichord, trumpet, flute, violin }
ran plays = { piano, guitar, violin, trumpet, flute }ran worksby =
{ hammering, plucking, blowing, bowing, scraping }
A B↔
A B↔
∅
∅ ∅∅ ∅∅
∅
Z Z Z×( )↔
76
Introduction to Formal Methods
(ii) dom plays is of type Peopledom worskby is of type Instrumentran plays is of type Instrumentran worksby is of type Actions
ex. 5.7
(i) Recall that the set notation {n,m: N | .... } produces a set of
ordered pairs. So the domain is found by existentially quantifying
m, that is
dom { | } = { | } A similar approach works for the range
ran { | } = { | }
however, this simplifies to the set .
(ii) Here, the notation explicitly produces a set of ordered pairs. The
domain and range here are the whole of the set X.
(iii) Here, there are no elements in the set of pairs, so the domain
and range are both equal to the empty set.
(iv) Using the sets defined in the text for Potters, WheeledVehicles,
and the relation rides, the domain is
{ {Alice, Ben, Huw }, {Ben} }
and the range is
{ Bicycle, Unicycle }
n m: N, n 2 m×= n: N m: N n•∃ 2 m×=
n m: N, n 2 m×= m: N n: N n•∃ 2 m×=
N
77
Introduction to Formal Methods
SAQ 4.2
ex. 5.13
(i) { (piano, hammering), (harpsichord, plucking) }
(ii) { (Askenazy, paino), (Alice, piano),
(Kate, piano), (David, Violin) }
(iii) { (Williams, guitar), (David, violin),
(Huw, trumpet), (Alice, flute) }
(iv) { (piano, hammering), (guitar, plucking),
(harpischord, plucking), (trumpet, blowing),
(flute, blowing) }
ex. 5.14
(i) ran ({Kate} rides)
(ii) dom (rides { bicycle, tricycle})
(iii) ({Huw, Ben} rides) {bicycle}
ex. 5.16
(i) { (Alice, 2) }
(ii) { (Alice, 2) } - ie, the same
ex. 5.17
(i) { (2,4), (3,3), (3,4), (4,2) }
(ii) { (1,3), (2,2), (2,3), (3,1) }
(iii) { (1,1), (2,2), (2,3), (3,2), (3,3), (4,4) }
78
Introduction to Formal Methods
(iv) { (1,4), (2,2), (2,3), (3,3), (3,2), (4,1) }
ex. 5.21
(i) { bicycle}
(ii) { Ben }
ex. 5.22
(i) { 2, 3 }
(ii)
(iii) { 1, 2, 3, 4 }
(iv) { 3, 4 }
(v)
(vi)
(vii)
SAQ 4.3
ex. 5.26
(i) No, because Alice plays more than instrument.
(ii) Potter must mean worksby here rather than works. Worksby is
not a function because a violin has more than one method of
working.
(iii) Yes.
∅
∅
∅
∅
79
Introduction to Formal Methods
(iv) Yes. Note that neither haswheels nor its inverse need be a
function in general, since we can imagine vehicles (such as cars)
with 3 wheels, 4 wheels, ....
ex. 5.31
(i)
domain is Z
range is Z \ { 0, 1 }
(ii)
domain is Z
range is { 0 }
(iii)
domain is { }
range is Z
plus2: Z Z
• plus2(x) = x + 2x: Z∀
tozero: Z Z
• tozero(x) = 0x: Z∀
squareroot: Z Z
• squareroot(x) x squareroot(x) = xx: Z∀
x: Z x2•
80
Introduction to Formal Methods
(iv)
domain is
range is
(v)
domain is Z
range is { }
(vi)
There is a possible ambiguity in Potter’s question. Does he mean
that the function is only defined for positive numbers (whose sign
is changed), or is it also defined for negative numbers (whose sign
is presumably left unchanged)? I have adopted the wider
interpretation and defined flip to be a total function.
emp: Z Z
emp = ∅
∅∅
temp: Z Z
•
•
x: Z∀m: N∃temp x( ) m 10×=( ) m 1−( ) 10 x m 10×≤<×∧
n: Z 10 nו
81
Introduction to Formal Methods
domain is Z
range is Z \ N
SAQ 4.4
ex. 5.47
(i) { 0 1, 1 1, 0 2, 2 1 } Not a function. This illustrates that the union of two functions can yield a relation.
(ii) { 1 0, 1 1 } Not a function. This illustrates that an inverse of a function can yield a relation.
(iii) { 1 2, 2 0 } This IS a function.
(iv) { 1 2 } This IS a function.
(v) { 0 1, 1 1 } This IS a function.
(vi) { 0 1, 2 1, 1 1} This IS a function (as it is guaranteed to be through the use of functional overriding)
ex. 5.50
(i) shopprice' = shopprice { i p }
(ii) shopprice' = shopprice { i shopprice(i) x 2 }
flip: Z Z
•
flip x = x
flip x = -x
x: Z∀x 0≤ ⇒x 0> ⇒
⊕
⊕
82
Introduction to Formal Methods
(iii) shopprice' = shopprice { i shopprice(j), j shopprice(i) }
(iv) shopprice' = shopprice priceupdate
(v) shopprice' = s shopprice
ex. 5.52
SAQ 4.5
There is no real contradiction between the definitions of a set and
a sequence.
We have seen that a sequence is a function, and that a function is
a relation, and that a relation is a set of ordered pairs. So a sequence
is certainly a set.
The notion of order is built in at two levels. First, the ordering is
given by our interpretation of the first elements of the ordered pairs
as locations in a sequence. Of course, we would not be able to
express the link between locations and contents at that location
without the ability to relate pairs of objects. So the other point at
which ordering is built in is in the definition of a relation as
comprising of ordered pairs.
⊕
⊕
revpair : (X x Y) (Y x X)
revpair ( (x,y) ) = (y,x)x: X y: Y; •∀
[X,Y]
83
Introduction to Formal Methods
SAQ 4.6
ex. 5.60
All but (ii) and (vi) are sequences. (ii) has an element indexed by 0,
whilst sequences must start at 1. (vi) is not a function but a relation,
so it cannot be a sequence.
ex. 5.65
(i) < Alice , Huw , Ben >
(ii) < Huw, Kate , Alice >
(iii) < Kate , Alice >
(iv) This is not a sequence because it removes the first element yet
does not ensure that the indexes are shifted down by one. It is the
relation:
{ (2, Alice), (3, Huw) }
ex. 5.67
An alternative definition would be
rev : seq X seq X
s: seq X • rev ( rev s ) = s∀
[X]
84
Introduction to Formal Methods
SAQ 5.1
Look at Potter's model on page 124 and compare it with your own.
There is no single correct data model, so it is quite possible for you
to have a data abstraction which is different from Potter's and yet
expresses the requirements adequately.
SAQ 5.2
The first predicate means that there is a maximum number of books
that a reader can borrow, but has the potential of each reader
having a different maximum number. The second predicate
proposes the existence of a 'global' maximum which all readers
must conform to.
SAQ 5.3
See exercise 6.6 on page 128.
rev : seq X seq X
s: seq X •
s = <> rev <> = <>
s <> rev s = rev (tail s) < head s >
∀⇒
≠ ⇒
[X]
85
Introduction to Formal Methods
SAQ 5.4
ex. 6.6
(i)
(ii)
To demonstrate that
active’ regd’ = dom password’
for the Registration schema, consider the two parts separately and
argue as follows:
logSysOpDecs
u? : User
p? : Word
u? regd
password(u?) = p?
u? active
active’ = active
regd’ = regd \ { u? }
password’ = { u? } password
∈
∉
deRegister
logSysOpDecs
u? : User
p? : Word
u? regd
password(u?) = p?
u? active
active’ = active { u? }
regd’ = regd
password’ = password
∈
∉∪
BecomeActive
⊆
86
Introduction to Formal Methods
active’ regd’ is true because active does not change whilst
regd gets larger during the Registration schema; and
regd’ = dom password’ is true because a single new element, u?, is
added to both LHS and RHS during the Registration schema.
SAQ 6.1
ex 6.11
(i)
(ii)
⊆
LogSys
u? : User
oldp?, newp?: Word
∆
u? regd
password(u?) = oldp?
active’ = active
regd’ = regd
password’ = password { u? newp?}
∈
⊕
ChangePassword
LogSys
u? : User
∆
u? active
active’ = active \ { u? }
regd’ = regd
password’ = password
∈
LogOff
87
Introduction to Formal Methods
(iii)
Note: It is not clear whether Potter requires a sequence of active
users in part (iii) above. If so, the declaration becomes
activeUsers! : seq User
and the predicate is
ran activeUsers! = active
SAQ 6.2
ex 6.16
(i) normalIssue = Issue success
Using the definition of Issue from page 131 of Potter (which has a
slight error in the last line: reader should be readers)
normalIssue =
LogSys
activeUsers! : F User
Ξ
activeUsers! = active
ActiveUsers
∧
Library
c? : Copy; r? : Reader
rep! : Report
∆
c? shelved
r? readers
# (issued {r?}) < maxloans
issued’ = issued { c? r?}
stock’ = stock
readers’ = readers
rep! = ok
∈∈
⊕
88
Introduction to Formal Methods
(ii) IssueError = Library
(HasMaxLoans
NotRegistered
AlreadyIssued)
IssueError =
SAQ 6.3
ex. 6.23
move s? out of the quantified expression and expand ClassRecord’
Ξ ∧∨∨
Library
c? : Copy; r? : Reader
rep! : Report
Ξ
(r? readers
# (issued {r?}) = maxloans
rep! = ReaderHasMaxLoans)
(r? readers
rep! = ReaderNotRegistered)
(c? dom issued
rep! = CopyAlreadyIssued)
∈ ∧∧
∨∉ ∧
∨∈ ∧
ClassRecord
s?: student
ClassRecord’ •
s? regd
regd’ = regd {s?}
done’ = done
∃∉ ∧
∪ ∧
PreNewRegistration
89
Introduction to Formal Methods
which simplifies to
#regd {s?} < maxclass
that is
#regd < maxclass - 1
so the precondition is
s? regd #regd < maxclass-1
SAQ 8.1
ex. 8.1
(i) x: N • y:N • y > x
or
x: N y: N • y > x
(ii) S: P N • S T: P N • T S T
(iii) n: N • n > 0
s? regd
regd’, done’: F student |
#regd’ < maxclass
done’ regd’ •
regd’ = regd {s?}
done’ = done
∉ ∧∃
∧⊆
∪ ∧
∪
∉ ∧
∀ ∃
∃
φ≠ ∃ ⊆ ∧ φ≠
∃
90
Introduction to Formal Methods
SAQ 8.2
ex. 8.3
Initialisation theorem
stock’: Copy Bookissued’: Copy Readershelved’: F Copyreaders’: F Reader |
shelved’ dom issued’ = dom stock’
shelved’ dom issued’ =
ran issued’ readers’
r: readers’ • # (issued’ {r}) maxloans •
stock’ = issued’ =
shelved’ = readers’ =
To prove the theorem, we note that substituting the components
into the invariant leaves the trivial statements:
=
=
Library’
stock’ =
issued’ =
shelved’ =
readers’ =
∅∅
∅∅
InitLibrary
∃
∪ ∧
∩ ∅ ∧
⊂ ∧
∀ ≤
∅ ∧ ∅ ∧
∅ ∧ ∅
∅ ∪ ∅ ∅ ∧
∅ ∩ ∅ ∅ ∧
∅ ⊂ ∅ ∧
91
Introduction to Formal Methods
r: • # ( {r}) maxloans
SAQ 8.3
See page 213 of Potter for a solution.
SAQ 9.1
ex. 8.8
The absorption laws are given on page 192 of Potter and are called
Abs1 and Abs2. Here is the solution to Abs1; you should find that
the proof for Abs2 is very similar.
ex. 8.10
(i)TF4
(ii)TF2
(iii)TF3
(iv)Equiv
T Equiv
(v)Equiv
TF3
p q p q p (p q)
T T T T
T F T T
F T T F
F F F F
∀ ∅ ∅ ≤
∨ ∧ ∨
true false∨true≡
true false∧false≡
false anything∨( ) true∨true≡
p p⇒p p∨¬≡ ⇒
true≡
false p⇒true p∨≡ ⇒true≡
92
Introduction to Formal Methods
ex. 8.12
idempotence of
EquivId
DN
commutativity of
EquivC
Equiv
associativity of
EquivEquiv
DNA
EquivEquiv
ex. 8.14
(i)
1. H2. E13. I2
∨
p p∨p¬ p¬∧( )¬≡ ∨
p¬¬≡ ∧p≡
∨
p q∨p¬ q¬∧( )¬≡ ∨q¬ p¬∧( )¬≡ ∧
q p∨≡ ∨
∨
p q r∨( )∨p¬ q r∨( )¬∧( )¬≡ ∨p¬ q¬ r¬∧( )¬( )¬∧( )¬≡ ∨p¬ q¬ r¬∧( )∧( )¬≡
p¬ q¬∧( ) r¬∧( )¬≡ ∧p¬ q¬∧( )¬ r∨≡ ∨
p q∨( ) r∨≡ ∨
p q∧p ∧p q∨ ∨
93
Introduction to Formal Methods
(ii)
1. H2. Equiv3. Equiv, twice4. E15. Equiv
(iii)
HIdAC
A, twice
(iv)
HEquiv
IdC, A
Equiv, twice
(v)
1. H2. Dist 23. Id4. Abs 1
Actually, this example can be shown in a single step using Abs2 (since an equivalence can be used to show an implication – what we have done above is to prove abs2!).
p q⇔p q⇒( ) q p⇒( )∧ ⇔
p¬ q∨( ) q¬ p∨( )∧ ⇒p q¬∨ ∧
p¬ q¬⇒ ⇒
p q r∧( )∧p p q r∧( )∧ ∧≡ ∧p≡ p q∧( ) r∧ ∧ ∧p≡ q p∧( ) r∧ ∧ ∧
p q∧( )≡ p r∧( )∧ ∧
p q r∨( )⇒p¬ q r∨( )∨≡ ⇒p¬ p¬ q r∨( )∨ ∨≡ ∨
p¬ q∨( ) p¬ r∨( )∨≡ ∨ ∨p q⇒( ) p r⇒( )∨≡ ⇒
q p q∧( )∨q p∨( ) q q∨( )∧q p∨( ) q∧ ∨
q
94
Introduction to Formal Methods
(vi)
1. H2. I13. Equiv
SAQ 9.2
ex. 8.15
Bound variables are marked thus
(i)
(ii) [both variables are free]
(iii)
(iv)
ex. 8.19
(i)Q2S
(ii)DefDM1Equiv
Q4EquivDM2
DNDef
Note that de Morgan’s laws are in fact equivalences - Potter, on
page 196, exercise 8.13, gives the impression that they are not.
pp q∨ ∨
p¬ q¬∧( )¬ ∨
x
y:N y 2>•∃( ) x:N x 1 x>+•∀( )∧
x 2 y×=
y:N y 2>•∃( ) x:N x y>•∀( )∧
x:N y:N y x>•∃( ) x 2 y×=∧( )•∀
x:T p q∨•∃x:T p•∃ x:T q•∃∨≡
p x:T q•∃∨≡ ∃
x:T p q∧•∃x: T p q∧( )¬•∀¬≡ ∃x:T p¬ q¬∨( )•∀¬≡x:T p q¬⇒( )•∀¬≡ ⇒p x:T q¬•∀⇒( )¬≡
p¬ x:T q¬•∀∨( )¬≡ ⇒p¬¬ x:T q¬•∀¬∧≡
p x:T q¬•∀¬∧≡p x:T q•∃∧≡ ∃
95
Introduction to Formal Methods
(iii)
HQ3S
Note that this last step requires T to be non-empty. However, the
hypothesis states that there is some x of type T with some property,
so this assumption is valid.
SAQ 9.3
ex. 8.21
You have to write DeleteMember first – although page 214
provides a big hint! Here is my definition:
x:T p q⇒•∃x:T p•∀≡ x:T q•∃⇒
p≡ x:T q•∃⇒ ∀
Fid
id?: ID
∆
id? dom members
members’ = {id?} members
banned’ = banned
∈
DeleteMember
Fid
id?: ID
Fid’•
id? dom members
members’ = {id?} members
banned’ = banned
∃∈ ∧
∧
PreDeleteMember
96
Introduction to Formal Methods
Expanding the predicate Fid’ we get
id? can be moved outside the quantifier and the one point rule can
be applied twice to obtain:
The first line cannot be simplified further.
The second line is satisfied because removal of a pair from an
injective function leaves an injection.
The third line is satisfied from the definition of Fid.
The last line can be simplified because, from Fid,
banned dom members
so the last line is simply id? banned.
Thus the precondition as a whole simplifies to
id? banned id? dom members
or, more succinctly
members’ : ID PERSON, banned: P ID |
banned’ dom members’ •
id? dom members
members’ = {id?} members
banned’ = banned
∃⊆
∈ ∧∧
id? dom members
{id?} members ID PERSON
banned P ID
banned dom ({id?} members)
∈ ∧∈ ∧
∈ ∧⊆ ∧
⊆
∉
∉ ∧ ∈
97
Introduction to Formal Methods
id? dom members \ banned
ex. 8.23
No, this hypothesis is not true, because there is no constraint which
ensures that we add the same member previously deleted. Instead,
the statement
DeleteMember; AddMember applicant! = applicant? Fid
is true.
∈
Ξ
98
Introduction to Formal Methods