The schema

The mathematical language of Z is powerful enough to describe most aspects of system behaviour. However, the unstructured application of mathematics soon results in descriptions that are difficult to understand. To avoid this, we

must present mathematical descriptions in a sympathetic fashion, explaining small parts in the simplest possible context, and then showing how to fit the pieces together to make the whole.

One of the most basic things that we can do to help the reader—or indeed the writer—of a specification is to identify commonly used concepts and fac-tor them out from the mathematical description of a system. In this way, we can encapsulate an important concept and give it a name, thus increasing our vocabulary—and our mental power.

In formal specifications, we see a pattern occurring over and over again: a piece of mathematical text which is astructuredescribing some variables whose values are constrained in some way. We call this introduction of variables under some constraint aschema.

Example 11.1 The set comprehension term, lambda expression, and quantified predicates below each exhibit this pattern of introduction and constraint:

{m,n:N|n=2×m•m,n}

( λs: seqX |s≠hi •(tail s) _hhead si)

∀x,y :N|x≠y•x>y∨y>x

∃z:N|z≠1•z<2

Example 11.2 A concert hall uses a software system to keep track of bookings for performances. Inside the hall is a certain amount of seating, some or all of which may be made available to customers for a given performance. At this level of abstraction, we have no need to consider the representation of seats and customers, so we introduce them as given sets:

[Seat,Customer]

The box office maintains a record of which seats have been sold, and to whom.

This relationship should be functional: that is, no seat can be sold to two dif-ferent customers:

sold∈Seat

7→

To allow for the possibility that seats may be added to or removed from the hall, we introduce a setseating, a subset ofSeat, to represent the seating allocated for the performance.

11.1/The schema 149 It should not be possible to book seating that has not been allocated; the following predicate should be true at all times

domsold⊆seating

That is, the domain of sold should be a subset ofseating. This property, to-gether with the declarations ofsoldandseating, forms a schema which we shall callBoxOffice.

A schema consists of two parts: adeclarationof variables; and apredicate constraining their values. We can write the text of a schema in one of two forms:

horizontally

[declaration|predicate]

or vertically declaration predicate

In the horizontal form, the declaration and predicate are separated by a vertical bar, and the schema text is delimited by brackets. In the vertical form, the declaration and predicate are separated by a horizontal bar, and the schema text is delimited by a broken box.

Example 11.3 We can write the box office schema in horizontal form, as [seating:PSeat; sold:Seat

7→

|domsold⊆seating]

or in vertical form, as

seating:PSeat; sold:Seat

7→

domsold⊆seating

In the declaration part of a schema, the order in which variables are intro-duced is unimportant. In the above example, it would make no difference if sold were to be declared beforeseating.

The schema language includes a special operator for associating names with schemas. We may name a schema by writing

Name =b [declaration|predicate]

or by embedding the name in the top line of the schema box Name

declaration predicate

In either case, we are introducing a syntactic equivalence between Nameand the schema text. We may useNameto refer to this text in the remainder of a formal description.

Example 11.4 We can name the box office schema text by writing BoxOffice =b [seating:PSeat; sold:Seat

7→

domsold⊆seating]

or by writing BoxOffice

seating:PSeat; sold:Seat

7→

domsold⊆seating

Two schemas are equivalent if they introduce the same variables, and place the same constraints upon them. When considering equivalence, remember that some constraints may be hidden in the declaration part.

Example 11.5 The declaration part of the box office schema includes the con-straint that the relation sold betweenSeat andCustomer must be functional.

The following schema, in which this constraint appears as part of the predicate, is entirely equivalent:

seating:PSeat; sold:Seat

↔

domsold⊆seating∧sold∈Seat

7→

11.1/The schema 151 To make a schema more readable, we may put each declaration on a new line, and leave out the semicolons. Similarly, we may put each conjunct on a new line, and leave out the conjunction symbols. For example, the predicate

a⇒b c∨d

is another way of writing(a ⇒ b)∧ (c ∨ d). Of course, this is not the case where the line is broken with another operator: for example, the predicate

∃y :T • x<y ∨ y<x

means∃y:T •x<y ∨y <x.

Example 11.6 The schema ofExample 11.5 could be written in the following form:

seating:PSeat

sold:Seat

↔

domsold⊆seating sold∈Seat

7→

If the schema text introduces components, but places no constraints upon them, then we may omit the predicate part.

Example 11.7 The following schema text has a single component, a set of seats calledstalls, with no constraints:

stalls:PSeat

This is equivalent to the text

stalls:PSeat true