Unit 1 Formal methods in software engineeringstaff · 2000. 9. 26. · 5 Introduction to Formal...

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


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


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


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


Unit 2

Logic and set theory

Unit Objectives


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


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



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


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


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


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


• 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


The following SAQ tests your ability to produce quantified

expressions from ordinary sentences.

Check your answers at this point before proceeding.

SAQ 2.4


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


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


Objective 5

12



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


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


Unit 3

The Z type system

Unit Objectives


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


• 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


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


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


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


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


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


(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


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


Unit 4

Relations, functions and sequences

Unit Objectives


9 construct and evaluate expressions involving relations;

10 construct and evaluate expressions involving functions; and

11 construct and evaluate expressions involving sequences.


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


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


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


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


[ 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


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


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


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


Unit 5

Schemas

Unit Objectives


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


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


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


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


Objective 12

35


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


Objective 13

36


Unit 6

The schema calculus

Unit Objectives


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


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


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


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


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


Objectives 13 and 15

41


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


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


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


Objective 16

44


Unit 7

A complete specification

Unit Objectives


17 read realistic specifications written in the Z notation; and

18 demonstrate how to structure a specification document.


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


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


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


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


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


Unit 8

An introduction to reasoning with specifications

Unit Objectives


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


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


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


Objective 19

52


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


Use the definition of the Library schema on page

176 of Potter in your solution.

Objective 19

53


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


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


Objective 19

55


Unit 9

Reasoning with propositions and predicates


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


(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


(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


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


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


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


(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


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


(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


(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


(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


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


(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


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


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


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


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


(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


(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


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


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


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


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


(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


(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


(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


banned’ = banned

∃∈ ∧

∧

PreDeleteMember

96


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


banned’ = banned

∃⊆

∈ ∧∧

id? dom members

{id?} members ID PERSON

banned P ID

banned dom ({id?} members)

∈ ∧∈ ∧

∈ ∧⊆ ∧

⊆

∉

∉ ∧ ∈

97


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


Unit 1 Formal methods in software engineeringstaff · 2000. 9. 26. · 5 Introduction to Formal...

Documents

Transcript of Unit 1 Formal methods in software engineeringstaff · 2000. 9. 26. · 5 Introduction to Formal...