Formal Specification and Documentation Using Zk-2

8/6/2019 Formal Specification and Documentation Using Zk-2

1/158

Formal Speci cation and


2/158

formal speci cation 1. A speci cation written and approved in accordance with

A speci cation written in a formal notation, such as VDM or Z.

A formal notation based on set algebra and predicate calculus for the speci ca- Oxford University. Z speci cations have a modular structure. .. .


3/158

1 Formal Speci cation using Z

1.2 Formal Speci cation 4

4.3 Service Speci cation 69

7.2 Type De nitions 120


4/158

12.5 Simpli cations and Assumptions 192

13 .4 S imp li c at ion s, A ss um pt io ns an d C om me nts 2 02

14.4 Simpli cations and Assumptions 213

15 Formal Speci cation of Existing Systems


5/158

for system speci cation, committed a number of serious errors. The main one is to staff topics such as structuring and modelling. Too many books have given up the ght

which have given the impression that formal speci cation is merely the writing downof somesimple mathematical statements which de ne the behaviour ofa system. Whatsmall examples dois to hide one of the mostdif cult tasks of speci cation: the process

They range from the speci cation of the Transputer instruction set to that of a tool for Z: its ability to structure large speci cations into chunks which can be read, validated


6/158

good, ef cient, or even feasible design. For that, the designer needs experience,insight, air, judgement, invention. Formal methods can only stimulate, guide, and

to its speci cation. Sometimes the latter method is known as rigorous to differentiate

invalid. The speci cation must be obviously right. There is no way that this can beformally veri ed to be what is wanted. It must be simple enough to be understandable

than that held by some academics: that is that formal speci cation alone can still be bene cial (and is much more cost effective in general) than attempting proofs in manycases. While the cost of proving a system correct may be justi ed in safety-criticalsystems where lives are at risk, many systems are less critical, but could still bene t

assumptions made are correct and will not invalidate any formally veri ed design. It is

the Z notation (pronounced zed), intended for the speci cation of such systems. The

speci cation of a number of digital systems in a variety of areas to help demonstratethe scope of the notation. Most of the speci cations are of real systems that have been

In Part I, the rst two chapters give an introduction to formal speci cation, using Z

In Part III, Chapter 6 details the speci cation of a text formatting tool designed for les is discussed inthis context. A speci cation of a mouse-based input system for

hardware. In Part IV, a number of aspects important in the speci cation of machineinstruction sets are discussed. Chapter 8 formally de nes some concepts which areuseful in the speci cation of any microprocessor. Building of this, a part of a speci c

useful for specifying pixel maps and window systems. Chapter 11 de nes the raster-


7/158

that are of special interest. F inally an index, particularly of names of de nitions inthe speci cations presented in the book, will aid the reader in navigating the text,

It is hoped that the speci cations presented here will help students and industrial practitioners alike to produce better speci cations of their designs, be they large or small. Even if no proofs or re nement of a system are attempted, mere formalization plemented, and therefore much more dif cult and expensive to rectify.

In Chapter 1, the use of the Z notation for the formal speci cation of computer-based


8/158

speci cation mal speci cation, a brief introduction to some example applications as presented otherwise for the use of Z for system speci cation. The chapter is informal in na-

ough documentation. This book presents a general speci cation language, Z (zed),

thus the formal notation always provides the de nitive description in the case of any

This chapter is split into two main parts. The rst half deals with the nature of for-mal speci cationand why it should be used. Additionally, a brief introduction to Z and


9/158

1.2 Formal Speci cation

A formal speci cation is simply a description of a system using a mathematical no-

biguous natural language and diagrams which are often used for speci cations. The than mathematics. The speci cation language must rst be learned, and then experi-ence in its use needs to be gained before its full bene ts can be attained.

A speci cation language may be used as a design tool and, if the notation is read- design team. Once the design has been nished, it can then form the basis for a manual

interface speci cation of the system with the outside world and the implementation re nement

376, 381]. It is a typed language based on set theory and rst order predicate logic.

The problem with using mathematics alone is that large speci cations very quickly to aid the structuring of speci cations. This

As well as the formal text, a Z speci cation should contain English (or some other document. However, if there is a con ict between the two descriptions, the mathemat-ics is the nal arbiter since it provides a more precise speci cation.

The idea of an abstract Z speci cation is to describe it does it. Imperative programming languages are speci cations, but these con- more like speci cation languages since these describe it is possible (and sometimes desirable) to write non-deterministic speci cations inZ. This means the exact execution of the speci cation cannot be determined. The

Some speci cation languages designed to be executable (although very inef -ciently) so that rapid prototyping of the system is possible. However in such speci -cations, the designers often have to think about making the speci cation executable in

speci cation is not in general executable by computer, by passing it round members equivalent informal speci cation.

Note that Z is a formal speci cation

1.2.2 Why use formal speci cation?

As previously mentioned, a formal speci cation is precise. This means that even if such a speci cation is wrong (i.e., not what the customer wanted), it is easier to tellwhere it is wrong and correct it. Since an informal speci cation is often ambiguous, itis more dif cult to detect errors and subsequently put them right.

Missing parts of an incomplete speci cation become more obvious. The remaining parts of a design can be identi ed and alternativepossibilities considered. In particular,

left out. The nal document should include a prose description relating the formal text

A Z speci cation may be written in a variety of styles (e.g., a functional style, as


10/158

First some basic sets (e.g., le identi ers) may be introduced. At this stage, it is

implementation rather than the abstract speci cation may be left till later. It may also be useful to introduce some extra operators for a particular speci cation to make itmore readable. These may be de ned as the design progresses.

is de ned in terms of sets, relations, functions, sequences, etc.This should not be in uenced by implementation considerations, but rather should bedesigned to make the speci cation as understandable as possible to the reader. Thismay well be modi ed during the design to make the speci cation of operations on speci cation. The aim is not necessarily to make the formal description as short as

up, or whatever) should be speci ed. This is de ned in terms of the abstract state andsome extra predicates de ning the initial conditions of the system.

all operations ont he system. Thesemay be included as predicates in a schema de ning

affect a particular part of the state. It is convenient to de ne schemas which partiallyspecify such cases. This information may then be included in subsequent de nitions

can be added if this is convenient to aid the clarity of the speci cation. An operation the operation. For example, the system could provide a le identi er from a pool of available identi ers. The designer may not care which identi er is chosen. In such

another is in progress). At the outermost level of the speci cation, the system is con- tor to ensure that the operation can only be executed when these are satis ed. If the

we could check that the creation followed by the deletion of a le leaves the state

Finally it is possible to re ne an tation by a series of state and operation re nement steps. For example, a set in anabstract state may not be immediately, or ef ciently, implementable in a particular

or other convenient data structure. Each re nement step is related to the previous governing valid re nement steps. This re nement process will also make any non-determinism in the abstract speci cation deterministic in the nal implementation by

programming language will be used for the nal implementation. As well as the User Signi cant effort was expended in the presentation of the manuals to make them as

been tidied up and improved for the nal version of the manual, thus greatly reducing


11/158

De nition section formally de nes the speci c errors which may

de ned in a single tariff schema. Finally all the operations and the tariff schema are desired to produce a complete speci cation of the service.

have been de ned to allow descriptions of iteration, etc.

design to a programmer, rather than to aid a proof of correctness by de ning its rela-

each speci c service.

bined to produce a speci cation of the complete system. Network attributes, includingauthentication, and client attributes (e.g., identi cation) are also covered. Finally a

investigation were speci ed in Z to gain a greater understanding of their operation.

[37] le system was used as one of the earliest examples of the speci cation that is provided as part of Z to enable large speci cations to be tackled [298]. Part III text in a le [44]. A matching the reader. Chapter 7 gives a speci cation for a library of C routines that implement

Z is not necessarily restricted to the speci cation of software-based systems. Any sys- be performed can be conveniently speci ed in Z. For example, Z has proved partic- instruction set has been completely speci ed as an exercise [39, 38]. Additionally,

16/32-bit microprocessor instruction sets have also been speci ed in Z [45, 149, 350].

Part IV of the book gives an introduction to the formal speci cation of instruction


12/158

processor words, consisting of xed length sequences of bits. Next, Chapter 9 gives a

speci cation for three window systems. The speci cations could be used to contrast

such speci cations, it would be a simple matter to update existing documentation, or

speci cations of existing systems, and for detecting errors and anomalies in the docu-

ideas in Z. Chapter 10 de nes the basic graphical concepts and Chapter 11 uses theseto de ne raster-op functions, useful for manipulating pixel maps. Part VI builds on

Z is one of a number of speci cation languages which are being developed aroundthe world. It is a general purpose speci cation language. For example, Z could bespeci ed using itself [376, 79]. It could also be used to specify a more special pur- i cation than if CSP is used. Hence it is more convenient to use a language like CSP

advanced toolset is available for VDM, although the situation is being recti ed for notation of Z which is so useful for aiding the structuring and readability of speci -

Another approach to formal speci cation is that of algebraic speci cation (e.g.,

operators on types are speci ed rather than the types themselves. This approach istheoretically very attractive but problems can occur in scaling up speci cations for

Z may be used to produce readable speci cations. It has been designed to be read by

Large speci cations are manageable in Z, using the schema notation for structur-ing. It is possible to produce hierarchical speci cations. A part of a system may bespeci ed in isolation, and then this may be put into a global context.

attemptingto improve ef ciency. Fromthefeedback which has beenobtained,it seemsthat the use of Zis one of the few speci cation techniques which has not been received

page 241). This has produced about 2000 pages of Z speci cations and designs from i ed and around 11,000 lines (4%) which were partially speci ed with an estimated


13/158

In general formal techniques require a signi cantamou nt of trainingeffort and prac-

widely used. In general Z is still used for speci cation rather than proof in industry

project to have have used Z. Z has also been used successfully in initial speci cationfor the development of the microcode for the oating-point unit of the Inmos Trans-

Z can also help in re nement towardsan implementation by mathematically relating Z speci cations [326]. Such tools will make the use of formal methods more feasiblein an industrial environment. Formal re nement is not normally cost effective (or even

and categorized list of references onZ, including other examples of signi cant systemsspeci ed in the Z notation which help to demonstrate that it can be advantageously

Formal techniques such as Z are now suf ciently well established and supported for

the software industry to gain signi cant bene ts from their use. In pra ctice this has


14/158

where formal methods may be engaged usefully to the bene t of all. This chap-

the speci cation and design of the software is increased, this is a small part of the


15/158

arguably, have the most potential bene t to gain from the use of formal methods [26].

not have the familiarity to make full bene t of them. entrusting peoples lives to that system because by de nition you dont understand

Advocates of formal methods must preserve, re ne and teach the valuable knowl-

example, the following two alternative de nitions for formal speci cation

1. A speci cation written and approved in accordance with established standards.

2. A speci cation written in a formal notation, often for use in proof of correctness.

proof of correctness is de ned in general terms.

design. While the data structures are often well de ned (and easily formalized), therelationships between these structures are often left more hazy and are only de ned

these new techniques for the rst time, the cost of failure could be prohibitive and the bene cially (although many have the ability).

tioned in [73], particularly those where a quantitative indication of the bene ts gained

At a basic level, formal methods may simply be used for a high-level speci cation


16/158

of rules or a design calculus that allows stepwise re nement of the operations anddata structures in the speci cation to an ef ciently executable program. At the most

been used to verify signi cant implementations, but need to be operated by peoplewith skills that very few engineers possess today. Such tools are dif cult to use, even

existence of such a formalism is not suf cient; the relevant technology must also be

are still possible because of the fallibility of humans and, for mechanical veri cation,

(depending on market growth rates) are development speed and nal product cost. Is

comparing some signi cant projects which have made serious use of such techniques.

speci cation alone. (i.e., formal speci cation with adequateaccompanying informal explanation) of key components may provide signi cant ben-e ts to the development of many industrial software-based systems without excessive

process from requirements capture, through to speci cation, design, coding, compi-

ing errors by a signi cant factor, in both safety-critical and non-critical applications. fore they are certi ed (rather than tested). If too many errors are found, the process are too large to be formally proved correct, so they mustbe written correctly in the rst


17/158

less ambiguity and thus less likelyhood of errors [41]. Formal speci cation alone has proved bene cial in practice in many cases [22]. Such use allows the possibility of

ner is a dif cult task, but progress is being made in categorizing features of interfaces

extremely dif cult to obtain hard information on such projects because of the nature of application and experience of formal methods inthis eld, with a few exceptions (e.g.,

Up until relatively recently there have been few standards concerned speci cally with

on the software supplier that their methods achieve the required level of con dence.

frequently to re ect the latest available techniques and best practice. For example,

in charge. There is a maximum penalty of three months in j ail or a large ne [306].

De nitions in such standards could affect court rulings in the future.

2.4.3 E ducation and certi cation

are now including a signi cant portion of basic relevant mathematical training (e.g.,

through negligence rather than genuine error. Safety-critical software is identi ed asan area of utmost importance where such ideas should be applied rst because of the


18/158

projects. There are suggestions that some sort of certi cation of developers should be as well as bene ts byintroducing such a closed shop since suitably able and quali ed

Technology transfer is often fraught with dif culties and is inevitably and rightly a critical applications where safety is paramount. Awareness of the bene ts of formal

has meantthat time is not onour side. However, formal techniquesare now suf ciently skills shortage in this area for the foreseeable future and signi cant dif culties remain

These are brie y presented here:

to undertake proofs to gain bene t from the use of formal meth-

being designed since this process alone can expose aws, and in a much more cost- extra cost can be justi ed.

Only highly critical systems bene t from their use. on the level of criticality, which is ultimately a case of engineering and nancial

The mathematic required (and desired!) for formal speci cation is of a level thatcould be taught at school. Af ter all, a major goal of a speci cation is to be easily

speci cations

The mathematics may not be readable by an untrained client, but a formal speci -

strably bene cial results [213]. Two recommended examples which used Z, and

speci cation


19/158

There are now some signi cant tools supporting formal methods, many of which

logic) [178], LP (the Larch Prover, for algebraic speci cations [183]), Nqthm (a [176] and PVS (a more recent Prototype Veri cation System from SRI in Califor-nia, based on higher order logic), have been used for signi cant proofs. Some can

ifying this dif cult area [217].

courses, etc. For pointers speci cally concerned with Z, see Appendix A. A num-

Z is appropriate if you wish to undertake formal speci cation as part of a design

portant in a speci cation. This will affect its readability, the ease with which proofs

This is perhaps one of the most dif cult things to do for any software product, of the solution is very dif cult to estimate before it has been undertaken. Longexperience can help to give some insight, but estimates are still dif cult. Formal

nal implementation may be dif cult to determine from the formal speci cation.

require signi cant mathematical ability and training. These are


20/158

Thou shalt document suf ciently.

mal notationlike Z can be used ina bene cial way for system documentation. Evenif the formal speci cation is omitted from the nal documentation, its production

canbe veri edwith a goodlevel of certainty, but these models mightnot correspond

Formal speci cations can be written in a reusable manner, with some thought. Asan example, Z includes a toolkit of de nitions, de ned in Z itself, which have proved to be useful for many different speci cations. The core of the toolkit isaccepted as standard by most people who use Z for speci cation. In this book, theCommon Service Framework mentioned in Part II, the machine word de nitions inChapter 8, and the graphics de nitions in Part V, could all be reused indeed, been reused for other speci cations.

Taking an engineering approach to formal speci cation and veri cation.

and raising capital to invest in serious production quality tools may be dif cult.Raising commercial venture capital is likely to be dif cult because the banks will

is atime consuming and costly business. The effectsand bene ts of formal methods

Uni cation and harmonization of engineering practices involved in building high

A number of signi - case of dif cultly. It remains to be seen if formal methods can be successfully ap- some time to lter through in practice.

measure the aspect that is of real interest. It is also dif cult to extract such com-


21/158

here, it is only possible to present a avour of the notation. Rather than give a

involved before tackling the speci c notation of Z. One that is widely used for Z

In summary, Z [381] is a typed formal speci cation notation based on rst order pred- allows a certain amount of staticmachine checking of speci cations toavoid obvious (

The formal basis for Z is rst order predicate logic extended with type set theory. Herewe introduce logic only very brie y, since in practice many Z speci cations actually which mean that the reader can concentrate on the speci cation rather than the logic.


22/158

third unde ned value, which helps considerably in minimizing the complexity of the example, because of an unde ned expression within the predicate), then the predicate

mine. This contrasts with some other logics which sometimes add a third unde ned

There are a number of standard in x binary connectives: is de ned to be the same as

3.2.2 Quanti cation

Full predicate logic augments propositional logic with quanti cation over a list of

Universal quanti cation Existential quanti cation possible values, as required for universal quanti cation, would still be valid.Unique existential quanti cation general existential quanti cation which only allows

proofs about speci cations. A good selection of these is presented in [297]. Only a

. In this section we rst discuss why the use of typesis important in speci cations. We then introduce the notion of

ity to a speci cation. However this proves to be well worthwhile for the following

1. It helps to structure speci cations.

2. We wish to re ne the speci cation into code.Eventually, each variable ina speci cation will need to be implemented using some the speci cation. This means more errors are likely to be ironed out at this early

3. It helps avoid nonsense speci cations.

The use of types means the speci cation can more easily be checked for consis-


23/158

Consider the introduction of predicates in speci cations (using a

The rst part of this is a before the colons, much like de nitions in a programming language such as Pascal.

be speci ed in any order, and repeated elements simply map on top of one another.

upwards. Note that this set contains an in nite number of elements. The .. . inthis de nition is Z speci cations, it is normally denoted

is probably something wrong with the speci cation. To avoid confusion, the notation

empty set; there are no elements in it by de nition. In fact, for any often in speci cations.

So far, we have discovered how to denote ( nite) sets as a number of elements and


24/158

de ned in terms of the

So far we have de ned sets in terms of individual members of that set. This is a rather restrictive (although often useful)method of de ningsets. For any set containing more in nite sets, it fails completely since we would require an in nitely long document to

. This comprehensive form of set de nition takes

This de nes the set of all prime numbers (provided is de ned appropri-ately). This is, of course, an in nite set.


25/158

This will de ne the set of all methods which (It is unlikely to be an in nite set, but may be large if, for instance, the number of

in Z to clarify in x operators like

How could we write a de nition for

re exive


26/158

rst

rst

rst t

The latter would give a tuple in the opposite order from the rst.Sometimes it is desirable to extract only parts of the signature to de ne a set using

squares of primes may be de ned as:

acts as the de ning term for the set.

The signature declares any variables required for the set comprehension de nition, the

When de ning a variable which is itself a set, its type will be a set of sets. Since manyvariables in Z speci cations are sets, we use a special notation for this. If

This is the set of all possible sets of natural numbers. This is in nite of

required in the de nition of power sets.

abbreviation de nition

Given the de nition above, we can say is an in x operator here of type

A power set can include in nite subsets. For example, . If we are speci -cally interested in nite subsets, then Z has a special notation for this. If nite . We will explore exactly what nite means


27/158

(non-empty set of nite subsets):

to indicate that it is an in x


28/158

is de ned

abbreviation de nition:

are identi ers which repre- the de nition. is an in x symbol, and here from the context and clutter the speci cation unnecessarily.

. I.e., if a function is de ned as

if a function is de ned as respectively. Here, if a function is de ned as with a function de ned as also range which can never be larger than the domain for a function) must be nite.

Finite partial injections, which as well as being nite are also one-to-one.This is the same as the intersection of nite functions and partial injections on

All these different types of function are formally de ned on pages 105 and 112 of

ical toolkit of Z. A widely accepted set of such de nitions are presented in full in of the generally accepted main operators are brie y presented informally here:

the rst relation and the domain of the second relation are joined together to form a of the rst original relation and the range is a subset of the range of the second

of that set as the rst element in each tuple.

, de ned


29/158


30/158

. The successor function is often useful in speci cations. Some-times the inverse predecessor function is also useful. If this is so, we could de ne

as a speci c example, we can consider the following cases:

of a ( nite) set is the number of elements in that set, or the size of the (the set of all nite subsets of

For a set to be nite, it must be possible to map from a natural number in the range

set. This mapping can be done with a suitable nite partial injective function. For

) are de ned as a

[411], although these are not de ned in Spiveys Z toolkit [381]. They may be de ned not involve real numbers. As well as numbers, we can also de ne our own types.


31/158

If one particular place is of interest, we could de ne

de nition. For example, could be de ned as

types are possible. For example, we could de ne

This is equivalent to de ning

often not needed for many speci cations. You are referred to Section 3.10 starting on de nitions.

Lists, arrays, les, sequences, trace histories are all different names for a single im-

re nement. A sequence has a is a set, we de ne the set of ( nite) sequences with

whose domain is a nitesegment denotes a number range as de ned previously:

must have a nite (although arbitrary) length. If


32/158

Also, the order is signi cant:

More formally, we could de ne concatenation as

For another equivalent de nition, see page 116 of [381].

Pre x

to a pair of sequences effectively checks that the left hand sequence is a pre x of the

is always a pre x of any sequence. A sequence is always a pre x of itself.

If one sequence is the pre x of another and vice versa, the two sequences are identical:

If a sequence is the pre x of a sequence which is the pre x of yet another sequence,then the rst sequence is also a pre x of this other sequence:

If two sequences are a pre x of another sequence, then one of the two sequences must be a pre x of the other. Note that these laws also apply to sets:

pre x , de ned in the Z toolkit (page 119 of [381]) can also be

used to check for a sequence pre x.

It is often useful to be able to extract the rst or last element from a sequence inspeci cations. The rest of the sequence may also be of interest. Four functions are

rst element of sequence sequence without rst element

is unde ned.

application, allowing the length of sequence required to be speci ed, using


33/158

For example, these could be useful in extracting portions of les considered as a se-

satis es

For the actual formal de nition of

Other distributed operators can also be de ned for sequences if required for a particu-lar speci cation. For example, a session of updating a database results in a sequenceof partial functions. We could de ne a distributed overriding operator in terms of the example, a de nition on page 172. Informally:

Write a formal de nition for this. Can you think of an application for this operator ina speci cation?


34/158

partial order, which is re exive, antisymmetric,and transitive, may be a useful conceptin some speci cations:

This can be extended to de ne a total order, in which all elements are related:

For example, it may be useful to model time as a total order in a particular speci ca-

We have brie y covered numbers and then used these to de ne the notion of se-quences, an important data structure in many speci cations and data re nement. We

onwards in [381]. As you gain con dence in writing Z speci cations, you should

Using mathematics for speci cation is all very well for small examples, but for notation to aid the structuring and modularization of speci ca- shall see how to combine such schemas to produce larger speci cations.

A boxed notation called schemas is used for structuring Z speci cations. This has been found to be necessary to handle the information in a speci cation of any size.

This de nes a single

schema box de nes a number of named variables with (see the de nition of

can be a useful aid in understanding a speci cation.

Even more space can be saved using a horizontal formal of schema de nition, whichis typically used if the entire de nition can conveniently t on a single line. E.g.:


35/158

This schema speci es a instead to other occurrences of these variables already in scope (e.g., globally de ned

must be de ned here. (A common mistake by initial users of Z is to de ne interdepen-

3.6.1 Example speci cation

of the Birthday Book is speci ed by:

Z makes use of identi er decorations to encode intended interpretations. A state

is speci ed by:

speci cations. If required, there is a convention for constraining a number of state

As a more speci c example of a operation schema, consider the adding of a birthday

be written much more conciselyt han abovein a real speci cation, reducing six lines toa single included schema in the speci cation above in Spiveys original speci cation


36/158

speci cation is the predicate

which speci es that in the state after the operation

Z schemascan be speci edusing otherschemaswiththe

ponents in the speci cation. The use of schema inclusion allows detailed declarationsof state components to be hidden in subsequent parts of a speci cation once they have

can be speci ed


37/158

can be speci ed using

, as well as quanti cation using rst normalized. For the binary connectives to be used, there must be no con icting

convention may be de ned as follows:

One or more components of a schema may be hidden (i.e., existentially quanti ed) Conversely, schema components can be projected using components de ned by

in a speci cation for some reason.

existentially quanti es all after state and output components.


38/158

are combined and existentially quanti ed as a new intermediate state

operator in Z which matches the outputs of the rst

property that, if proved, provides an extra level of con dence that a speci cation iscorrect, since it con rms our intuitions about the properties of the speci cations that a aw in the speci cation, which can then be recti ed at an early stage before any

Note that Z as de ned by Spivey [381] includes no standard way to write theo- is sometimes used to include universally quanti ed declarations


39/158

The Z notation includes set-theoretic de nitions in the form of an extensive mathe- used is de ned using itself in this toolkit, and it is forming the main basis for the

rst order not legal in Z. In fact there is no prede ned Boolean type in Z since it is normallyunnecessary. It is pos sible to de ne a binary valued type in Z if required, but oftenthere is a better way of approaching the speci cation if a developer nds him/herself Chapter 8). A Z type-checker will quickly discover any attempt by a speci er to bend However, unfortunately there are some untype-checked Z speci cations are incorrect

Z has been a relatively uid language during its lifetime. The

Subsequent the chapters present a number of case studies of speci cations in Z, nearly

is given, using a simple service as an example. A manual for a more substantial le


40/158

The Z notation has been applied to the formal speci cation of resource managers is suf ciently readable for the speci cation to be used for documentation purposes.

First an introduction to the style of speci cation is presented. It considers how aservice can be modelled in the Z speci cation language, and the way in which suchspeci cations can be used in documenting both the users and the implementors viewof a service. Next an example of a service speci cation is given. This example de- implementation-oriented speci cation in the form of an Implementor Manual for the


41/158

user have any expectation of being able to make proper use of the nished product.

the system. This is necessary to ensure that the nished product does indeed have thecharacteristics that the designer speci ed.

signer, user and implementor which can be achieved by the use of formal speci cation

4.2.1 Formal speci cation

Satisfactory communication relies rstly on the production of an unambiguous de-scription. If a description is suf ciently precise, it can act as a contract between the

to make use of mathematical techniques for program speci cation to assist the design,

and practical system. As a result of this, the project was in uential in the development speci cation.

The use of formal speci cation techniques, because of their rigour, tends to guide ment ef ciently, since the simplest ideas do not necessarily have the most straightfor-

tion between designer and user. In o rder that the rigour of the speci cations should ensure that, as for any documentation, readability and accessibility were not sacri ced

A signi cant amount of effort has therefore been spent on developing a manual

4.3 Service Speci cation

will change the state in a well-de ned way. Consider a service with a state

Two small but signi cant differences can exist in a distributed system, as comparedto a centralized system. The rst is that the individual services will usually be at least to work after others have failed, so that the error noti cation and handling provided by

service. In the case of a le storage service, for instance, a user will be concerned with

les, le names and le contents, but will not be interested in details of how these implementation speci c) service state and corresponding abstract operations.

In order for the state of the service to be de ned at all times, the initial state of the


42/158

will speci cally be interested in the internal behaviour of the service. In the case of a

le storage service for instance, the implementor will have to deal with items such as

must be well-de ned.

more homogeneous to the user and therefore easier to use. Also, the speci cation and

These common aspects of services have been collected together into a set of de -nitions known as the Common Service Framework. When required, these de nitionscan be incorporated into speci cations of individual services in a standard way.

These arguments depend on giving a formal de nition of how the concrete and

The initial concrete service state must speci cally represent the initial abstract service

Note that in this book it is assumed that the initial state (de ned in

and which will produce a result that satis es the abstract speci cation. In other words

) are existentially quanti ed.

The concrete state is thus considered as a data re nement of the abstract state, and

presented implementation into nal code. Note that an Implementor Manual presentsonly one possible implementation, re ecting a particular set of design decisions. A programmer could choose to implement a service differently, provided it still satis edthe speci cation given in the user manual.

theory and rst order predicate calculus (upon which Z is based) is assumed. Reading


43/158

The manuals make use of some de nitions from the Common Service Framework.

a speci ed period. Subsequently the reservation may be cancelled by the holder by

reservations are threatened by the shutdown time, the manager will be noti ed, and

abbreviation de nition , using a nite partial function from

textually collecting together pieces of mathematics to aid structuring of speci cations.)

signi es outputs and signi es inputs. used here to indicate an incomplete speci cation.)

is de ned as a schema de nition here.


44/158

components. He re the de nition could be omitted since this is the default de nitionassumed by a Z speci cation if no explicit de nition is made.)

Operations can return nite sets of users, the following de nition is made for theconvenience of subsequent speci cations:

The service has nite capacity for recording reservations; the report

De nition

De nition section mathematically de nes the successful behaviour of the op-


45/158

operation. This gives the de nition of the total operation including the behaviour in

Only the de nition of the

De nition

De nition

de ned as after state and output components have been existentially quanti ed. In practice this means that the error


46/158

ti er de ned in terms of natural numbers.

There is a xed cost for each different successful operation. All clients who make a

If an error occurs, a xed amount may still be charged.

The de nition of the Reservation Service is completed by combining the de nitions operation, or of a network error are speci ed.

The additional components needed to de ne the complete service are omitted in this

In the Implementor Manual, the abstract speci cation of the User Manual is re ned speci cation of a possible implementation of the service. First the con-crete state of the service is de ned and then the concrete error and operation schemas

are de ned in terms of the concrete state components. Optimizations are includedwhere desirable. The justi cation that the given concrete speci cation is a correctimplementation of the abstract speci cation is discussed.

The speci cationgivenin the Implementor Manual isstill notdirectlyimplementable. speci cation, but the Implementor Manual presents a more concrete internal view of and then this design must be re ned into that language. Even with the advent of theuse of formal speci cation in the design of computer based systems, it is anticipated

quirements speci cation at a later date couldnecessitate a signi cant redesign. Design


47/158

This completes the speci cation of the concrete state, its initialization. and its change

The four service operations are rede ned in this manual in terms of the re ned con- De nition

Each schema de nition may be conveniently implemented as a procedure in thenal program. Again, only the de nition of the


48/158

De nition optimized into a combined available de nition.

ply human readable le names or any le organization. If this is needed, a Directory

conditions have been more exactly speci ed in the Reports section for each operation, ) to de ne an order of checking for error

speci cation.

At the end of each manual, the operations speci c to the service are combined speci cation of the operations available in the service.

implementors view of a service, showing how the abstract users view can be re ned

A signi cant amount of effort has been spent on the presentation of these manuals,

The ultimate goal of such speci cations is to consider the re nement of the imple- guage. Re nement, though better understood in theory [208, 230, 299], still requires nipulations in practice [295]. There has been much work on operation re nement


49/158

using Z [171, 246, 248, 308, 400, 423, 429, 431, 440, 441] and also data re nement[208, 238, 294]. Parallel re nement, linked with CSP [215], has also been consid- programming languages, such as Ada, with respect to a Z speci cation is also

speci cation that the deadlines be met [271, 272].

Work at Oxford and elsewhere has considered the step from speci cation into pro- been systematically re ned into Dijkstras language of weakest preconditions [296].

can be de ned in Z as a set, sequence or other more complicated structure.

The issue of how such types will be represented in a speci c programming language

programming language, there would need to be a clear speci cation of the representa-

Parameter re nement is an important topic which has received relatively little at- would therefore form a second, orthogonal, dimension of re nement to that of the im- at interfaces since this is the point at which many problems that are dif cult to detect

allows a number of de nitions the speci cations of individual services can be made that much simpler.

The speci cation of the common service framework has illustrated how separatesubsystems can be de ned, with their own state and operations, and then incorporatedinto the de nition of a complete service. It has addressed, at the speci cation level,

There are two kinds of errors speci ed in the common framework which are non-

until they achieved a de nite result (i.e success, or a speci c error report).

The speci cation of these non-deterministic errors is a problem. When a serviceerror occurs, the state of the service is speci ed to remain unchanged. This may be speci cation, it would be obligedto return a service error for any subsequent operation

When a network error occurs, it is speci ed that either the state of the service re- duce unwanted side-effects. A stricter speci cation might eliminate the second case,

One area which isof concern in manyZ speci cations involves dealing witht he partial

work. These operators are de ned to be total in the abstract speci cation to avoid

Since these sets are to be implemented they must be nite. Hence over ow or under ow (i.e., the required result lies outside the de ned range) could occur when


50/158

The Reservation Service was one of the rst services to be implemented, and its origi- stage. This has led to a small revision in the speci cation of one of the error schemas

The speci cation in the User Manual was examined to see how this state of affairs

tion was cleared as an indication that the printer had nished its current job; but the

against the use of an additional operation. A rst solution involves adding an extra

be programmed in Dijkstras guarded command language to meet the speci cations in

It is possible to use a formal speci cation language successfully both to guide thedesign of system components and also to document the resultant design. The speci -

The initial desire to present the formal speci cations as part of the manuals for the


51/158

along the lines described in Chapter 4. The service provides le storage facilities to in the Z speci cation provided here.

The le storage service stores les on behalf of its clients. A client may submit some

The service will store this data within a le:

As well as containing the clients data, the le records as its update. Whenever a le is created, an time until which the service is obliged to store the le. After this time, a le is said , and can be discarded by the service without noti cation of the client.


52/158

de nes a total order on A le identi er will be issued by the service when the le is created, chosen from a

set of such identi ers:

This becomes the clients reference to the le. Any subsequent operations on the lewill require this identi er. Operations which update the le contents will return a newname. Hence les are in the sense that a known valid le identi er willeither access a single xed le or return an error if it has been destroyed.

The service contains a mapping from le identi ers to les; it also contains a nite le identi ers which have not yet been issued. When a new identi er is

les les

can be used by clients applications to indicate no le (similarly to the use

Initially there are no les, and all identi ers except the

les Each le storage service operation can only be performed by an authentic client:

Finally, any identi er issued by an operation is removed from the set of new ids, and

les

These general aspects of operations on the le storage service are gathered together in

les

Sometimes the state of the le storage service is left unaffected by an operation, par-

Many le storage service operations require an existing le details are then available to the operation. A partially speci ed schema

lesid

All operations which create a new le return a new le then available to the operation. Guest users cannot create les. The client owns thenew le which has been updated . The le is added to the set of les stored by produce a le

les les

Some of the le operations access sections of the le contents. Three functions areuseful for these de nitions:


53/158

of a le of a le by a speci ed offset.

to be created in a les previously set to any value if data is written to a le at a position after its currentlength or the le length is set to be greater than the current length. A

Note that a le size ranges from zero up to a maximum size.

de nition. If it returns the value , it must satisfy its de ning schema. If it

les

This report is given if there is no le stored under the le expired and has been scavenged.

A new le cannot be created when the services storage capacity is exhausted. The le

A client operations which destroys a le must be performed by the owner of the le.

This is de ned in the de nes:


54/158

create a new le of zero length. write data to a stored le. read data from a stored le. remove a stored le from the service. obtain the complete status of a stored le. set the expiry time of a stored le. set the length of a stored le.

The following pages contain descriptions of each of the service speci c operations.The descriptions have three sections, entitled Abstract, De nition and Reports.

De nition section mathematically de nes the operation, by giving a schema

section given the de nition of the values in more detail by giving a mathematical de nition of each of their occurrences.

schema de nitions for operations taking into account all possible le storageservice errors. These sections use some generally available schema de nitions whichare de ned in the

A le is formed with a speci ed expiry time, and is stored by the service under thenew le . The new le contains no data.

De nition

The owner of the le is the client. Guest users cannot create new les.

If an expiry time in the past is given, then the expiry time of the le is set to

A new identi er is chosen which has never before been issued, and the new empty le


55/158

An existing le with the given at the speci ed in the le to produce a new le with a new . The original le is unaffected.

De nition

The creation and expiry times of the updated le are the same as the original le.

Any client apart from the guest user may write to a le. The owner of the new le is

A new identi er is chosen which has never previously been issued, and the new le is

The new le will contain holes if the offset given is past the end of the existing le.

Data at the speci ed in the le called

De nition

Any client, including the guest user, may read a le if they know its le id.

of the le. In this case the data returned will simply have a length of less than the


56/158

The le stored under

De nition

les les

A le may be destroyed only by its owner.

The status of the le stored under

De nition


57/158


58/158

enable le storage service.

disable le storage service.

Some operations are needed because of the implementation of the le storage service.

remove an expired le.

The le stored under is removed from the service; only expired les may be scav-

A scavenge may be invoked by the le service at any time; it can never be invoked by

De nition

les les

le is destroyed before its expiry time.The expense of storing data ina le is determined by applying a

the les update and expiry times. Similar tariff functions apply to reading data andobtaining le identi ers. There are various constants involved with this.

The tariff schema in Figure 5.1 de nes the costs involved when a client performs le

This section provides a full de nition of all the total operations which clients mayrequest the le storage service to perform. This de nition uses schemas which arede ned in this document as well as those which check authentication etc., as de ned

The set of operations implemented by the le storage service for clients is given in

A client may not access a le unless he knows its id, and le ids are hard to guess.The identi er of any le is initially known only to its creator; the service will never tell any client the identi er of a le he does not own.


59/158

Combined le system operations.

Files may be destroyed only by their owners, and user identi ers are hard to guess.Files may be updated, but this creates a new le with a new le id. The original le


60/158

ter 6 a text justi cation tool is formalized. An event-based input system designed for


61/158

justi cation of lines within an text le is formalized in Z. Implementation

ling system has been speci ed in Z elsewhere (see [298]). Here we context les which consist of

Characters are organized as lines in a text le. A complete text le, or document,

The Z speci cation language may be extended, as done in its mathematical toolkitfor many operators, by de ning a generic function to do this.


62/158

This de nition will prove useful in the subsequent speci cation in this chapter. A

Corresponding functions which clip the line rst may also be de ned.

Operations will be applied to a particular text le document, de ned as a named

de ne which operation is required.


63/158

This de nes an operation which takes as input (actually as command arguments right justi cation), and a column position to be used for the justi cation of the text.

The tab character introduces additional complication into the speci cation of manip-ulation of text les. We shall now consider some functions useful for specifying such


64/158

The column width of a line can be de ned.

le is implemented as a sequence of characters [298], possibly containing

On input, a number of such les are to be converted into a single document without


65/158

These schemas may be combined to produce a new speci cation for the behaviour of

This speci cation is based on a simple text processing tool which was written in the

Of course, normally a formal speci cation should be written

ts in producing a speci cation. This can be useful if a product is to be

done with more con dence. Software developed from formal speci cations is likely

have con rmed this view [247]. For these reasons, it is hoped that formal speci ca-tion will become more widely used in the eld of practical software engineering in the

The speci cation was previous published as an article [44]; it is included by kind

tool on which this speci cation is based isincluded here to allow the reader to compare the Z speci cation with a more familiar English style description. Note however that the speci cation given and the UNIX it would have undoubtedly been more like the speci cation given in this chapter. The

allows the positioning to be optionally determined by the position of the rstline in each input le.

in the rst column.

It would be a relatively mundane matter to update the speci cation presented here exercise for the interested reader. For this reason, the speci cation and the program do since modi cations would affect usersunduly; the studywas undertaken as an exercisein clear speci cation rather than re-engineering.


66/158

] [ column ] [ le ... ]

is a simple text formatter which reads the concatenation of input les (or stan- of the text is positioned at the speci ed column. If it is signed positive, then the positioning is calculated from the rst line ineach le. The default value for

interface is speci ed which allows a client to select events to be queued from the set

ush the input queue, and connect a set of polled events to a queued event. The of systems and has also been formally speci ed using the Z speci cation language.

process) may access. The event queue provides a set of logical devices with xed which may possibly implement it. The event queue system was rst implemented

tem [357, 358, 359]) in uenced this design.


67/158

7.2 Type De nitions

The types used in the Z speci cation in this chapter are all ranges of integers and have

represented by a device identi er (an unsigned 16-bit short word) and an associated

as small as possible and still be suf cient to contain the value for

The conceptual state of the system is introduced brie y here. Each component is

The state of the system includes a nite number of devices. Each of these has a

Initially, much of the state is zero or empty. A number of devices are con gured in


68/158

change asynchronously but this does not affect the abstract speci cation.)

are useful in the de nition of subsequent operations, by specifying that all but one of

. We can de ne

and so on. Using these de nitions,


69/158

Each device has an associated identi er. It is possible to determine the type of the

A partially speci ed schema may be used to capture the general features of these

operations. Then each operation may be de ned in terms of this schema.

type of device and perhaps the detailed device identi er. The semantics of the value

7.6.3 Event ltering


70/158

returns the device identi er, and places the value associated with

Foref ciency we areofteninterestedin readinga numbero feventsin one procedure

returns the deviceassociated with the rst event and returns an array of


71/158

returns the device identi er associated with the rst input event in the queue,


72/158

software nite state machine running on top of an array of buttons (the buttons of the identi er should be placed (de ned) in the system le ( the system de ned events would be passed through to the higher level queue as usual.

has beenimplemented as a signed shortinteger. A more exible We could de ne as a labelled disjoint union and update the speci cation given

In practice, this could consist of Boolean ag (in the sign bit) followed by a 15-bit


73/158

Hardware as well as software can be speci ed using the Z notation. The basic con- de nitions are used in Chapter 9 to specify part of the instruction set for the Inmos


74/158

in the speci cation of microprocessors at the instruction set level and below. Thesede nitions are used for the speci cation of part of an instruction set in Chapter 9.

least signi cant bit most signi cant bit

value of a word may be de ned by:


75/158

However if attention is restricted to words of a xed size, the restricted function is

It is convenient to de ne a function to generate words containing a particular value.

it will t.

Note that thisde nition of together withthe de nition of lier mean that the machine is little-endian; for words of any size the least signi cant

Sometimes the highest (most signi cant) bit set in a word is of interest:

unde ned here.

Bytes and Transputer words may be de ned by:


76/158

These de nitions are easily upgraded to bitwise logical operations on words. The

Addition and subtraction may be de ned in terms of repeated incrementing or decre-


77/158

since the word size of the result is determined by the size of the rst work to be added:

However if attention is restricted to words of a xed size the commutativity property

Multiplication may be de ned inductively in terms of addition.

of a word is de ned by:

Integer division is de ned by:

function is de ned in terms of division.

Hence the standard signed arithmetic operators can be de ned on


78/158

For convenience the following post x function is used to distinguish hexadecimal and

In Chapter 9, the formal de nitions provided in this chapter are used as a basis for de ning some of the instructions in the Inmos Transputer instruction set.

building on the basic de nitions given in Chapter 8. The Transputer is a com- SGS-Thomson Microelectronics) [224]. This speci cation is based on a partial speci cation of the Transputer instruction set in Z [149]. This itself is based on a Z speci cation of the Motorola 6800 microprocessor [38, 39] and a description of

pre x value. negative pre x value.


79/158

set error ag true.

test error ag and clear it.

stop if error ag is set.

4. Error ag

. The byte selector occupies the least signi cant end of the word.

can be de ned:

Using these de nitions may be de ned:


80/158

A consequence of this de nition is that if

It is convenient to de ne a similar function with the second parameter a word instead

Again the same function may be de ned with the second parameter a word instead of

mal de nition. C learly these two de nitions must be linked. The link is established

A nal point to note about memory is that the address space will be divided into

unde ned values.


81/158

Inclusion of a clock is not strictly necessary in the speci cation but it allows rea-

error ag

The error ag may take the values

provides a simpli ed description of the Transputer.

The change of state is de ned as:

Many instructions leave the memory and error ag and status unaffected:

as required. Forthe Transputer instructionset de ned here, the following are speci ed:


82/158

Each instruction and operation is allocated some unique op-code, here de ned using

All Transputer instructions are single bytes. The most signi cant 4 bits of the byte and the least signi cant 4 bits form an

It is now possible to de ne partial schema de nitions for instructions and operations.

instructions are classi ed as those which increment

to de ne general partially speci ed schemas for inclusion in subsequent de nitions.


83/158

is not constrained by the predicate and is therefore unde ned.


84/158

Arithmetic operations may lead to over ows. Many of the instructions in this sectioncheck for over ow and set the dyadic arithmetic operators de ned earlier:

checks for arithmetic over ow:

This is used to set the error ag appropriately after arithmetic instructions.


85/158


86/158


87/158

is de ned.

jumps to an address speci ed as a byte offset from the instruction following the


88/158

reads a sequence of bytes into memory starting at the address speci ed by speci es the length of the sequence. de nes the channel address being used.

are unde ned.

writes a sequence of bytesfrom memory starting at the address speci edb y speci es the length of the sequence. de nes the channel address being used.


89/158

the instruc

Formal Specification and Documentation Using Zk-2

Documents

Transcript of Formal Specification and Documentation Using Zk-2