Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Z
This material was covered during lectures on April 11, 1997.
Z is a formal specification language. It has discrete mathematics as its basis - notably, sets, relations, and functions, as well as propositional and first-order logic. Therefore material covered in Math 271 and Phil 279 will be helpful background for this material.
It's now becoming quite easy to find material on Z. Pressman's and Sommerville's texts on software engineering both include chapters on Z; note, though, that Pressman doesn't use the notation that's a standard part of Z (although it isn't really standard for anything else), so that Pressman's chapter won't be consistent with what is presented here. There are also minor differences in the way Z is used from reference to reference (although it's hoped that this won't be noticeable for the material presented in these notes).
A brief, and readable, tutorial introduction to Z can be found in
J. M. Spivey
``An Introduction to Z and Formal Specifications''
Software Engineering Journal 4 (1989), pp. 40-50
This article is reprinted in the collection Software Engineering: A European Perspective cited in the introduction to formal methods.
Quite a bit more information can be found in the following book, which is available in the library on reserve for CPSC 333
J. B. Wordsworth
Software Engineering with Z: A Practical Approach to Formal Methods in Software Engineering
Addison-Wesley, 1992
Finally, another book has recently appeared (but, as far as I know, is not in the library); this might be a better reference after having taken (the rest of) CPSC 333, because it uses examples that have are also described using some of the ``informal'' techniques that have already been discussed in this course:
J. Jacky
The Way of Z: Practical Programming with Formal Methods Cambridge University Press, 1997
Of course, it's hoped that the remaining brief notes are self-contained, so that you shouldn't need to check these other references in case you're interested in seeing additional material about Z. (That is, you shouldn't need to look at this other material in order to complete CPSC 333.)
First note: Z is a specification languaged developed by the Programming Research Group at Oxford University, in the United Kingdom.
Second note: CPSC 333 is a course offered in the Department of Computer Science at the University of Calgary, in Calgary, Alberta, Canada.
Conclusion: The name of the specification language discussed in these notes is pronounced ``Zed.'' To the best of my knowledge, there is no formal specification language whose name is pronounced ``Zee.''
Finally, it should be noted that specifications written using Z typically use symbols that aren't easily produced except by typesetting them, or using graphics programs. These symbols will be used correctly (whenever possible) in these online notes, so that they won't generally display correctly using lynx; please review these notes using Netscape or another powerful web browser, if at all possible.
In these notes, a specification will be developed for a simple integer counter.
This counter will be initialized to have value 0. The specification will use two integer constants, min_value and max_value, which represent minimum and maximum values for the counter that are allowed; all values that fall between (or include) these values will be allowed for the counter, and no others will.
These notes will include specifications for two functions that access or modify the state of the counter (or both): A function that sets the counter value, and another function that just reports it, will both be specified.
This example will be extended in a related lab exercise, in which additional functions will also be specified.
We'll begin by introducing the pair of ``integer constants'' mentioned above. An axiomatic description will be used to introduce each, as shown below.
The picture shown above is a reasonably ``typical'' axiomatic description. A vertical line runs down the left side , and a vertical line starts near the middle of this line and extends across the picture.
Text above this horizontal line introduces one or more constants (in this case, just one), using a line that includes the name of the constant (``min_value'', a colon, followed by the type of the constant. In this case, the constant is defined to be an integer. As shown in the above, the symbol for (the type) ``integer'' is an upper case Z, written in a ``blackboard bold'' font (with the diagonal bar in the symbol duplicated) - just as it often is in mathematics texts.
Text below the horizontal line includes one or more assertions or predicates (in this case, just one of them) specifying conditions that the variable(s) introduced above the horizontal line are required to satisfy. In the axiomatic description given above, this includes a requirement that the value of the (unknown) constant min_value must be less than or equal to zero.
A similar axiomatic description that introduces the constant max_value is as follows. This is also defined to be an integer; in this case, its value is required to be greater than or equal to zero.
Finally, it should be noted that ``axiomatic descriptions'' can be used to introduce more than simple constants: Functions and other more complex kinds of ``global values'' can be introduced in a similar way.
A ``truncated'' form of an axiomatic description can also sometimes be used. In particular, if you're defining a constant in which the only information you wish to give is the constant's name and type - so that there's no information to include below the horizontal line - then you can leave the horizontal line out. In this case, all you'd show some text introducing one or more constants, along with their types, with a vertical line running down the left hand side of this text.
Note that there's nothing in the above definitions that explicitly identify the values introduced as being ``constants.'' This isn't necessary because, in Z, all values that are used are ``constants.''
Here is another way to put this: The word ``variable'' has a different meaning in mathematics than it (generally) has in computer science - or, at least, in computer programming.
In mathematics, a ``variable'' is an unknown value (usually, required to be of some fixed type); the value of this might not be known, but you can rely on the fact that value won't ever change. For example, if you begin an argument with a statement like, ``Let x be an integer,'' you know that the specific value of x isn't generally known to you, but this value won't be changed during the argument that you give.
On the other hand, in computer programming, a ``variable'' generally stands for a ``register'' or some ``memory location.'' The value that is placed inside this register or memory location might change as a program is executed.
``Variables'' that appear in schemas written using Z have the properties of variable is mathematics - not in computer programming. That is, these values might not be known, but they never change.
Next, we'll give a schema that defines an object (or class) called Counter. This schema shows that the class has a single attribute, value, which is defined to be an integer. It also shows that this attribute's value must be greater than or equal to min_value, and less than or equal to max_value:
This defines an object, Counter with max_value - min_value +1 possible ``states,'' corresponding to each of the possible values for the attribute value.
As you can see, schemas resemble axiomatic descriptions. However, horizontal lines now run across the top and bottom of the picture (with each connected to the vertical bar, so that they form the three sides of an open-ended rectangle), and the name of the schema, Counter, appears on (and overwrites a part of) the top horizontal line, near its left edge.
Now, we'll define schemas that specify functions that access and modify a Counter object.
First, we need to deal with the fact that variable in Z are like ``variables in mathematics,'' while we'd also to specify functions that ``change'' the Counter's state.
In order specify such functions, we'll write schemas that include two variables that correspond to the attribute value of the object. One of these will stand for the value of the attribute before the function begins, and the other will stand for the value of the attribute after the function ends.
There is a ``naming convention'' used in Z that applies here. In general, if x is (the name of) an attribute for an object, and you're writing a schema that operates on the object, then you should define and use the following variables in this schema:
That is, in the schema for the function, you use the variable that stands for the attribute in a schema for the (static) object, to denote the attribute's value before the function begins, and you add a ``dash'' to the end of this variable's name, to obtain a second variable that will stand for the attribute's value after the function ends.
Thus, in schemas that operate on the Counter, we'll use a variable with name value to denote the attribute's value before the function begins, and will use another variable with name value' to denote the attribute's value on function termination.
It is useful to have versions of ``schemas for classes'' in which the schema's name, and the names of all the variables that stand for attributes, have dashes added to them. (We'll see precisely why this is useful, shortly.
Here's another convention in Z: If you've defined a schema ``s'' that stands for an object, then it's understood that if you add a dash to the name of this schema (to obtain the name ``s'''), then this ``decorated schema'' has precisely the form mentioned in the previous paragraph: That is, it's the same as s except that a dash has been added to each appearance of the name for any attribute.
For example, it's understood that the schema Counter' is as follows, if the schema Counter was defined as shown above.
Note that the variables min_value and max_value have not been ``dashed'': Only the variable(s) standing for the object's attributes have been changed in this way.
Now, here's (part of) the reason why it's useful to have the ``dashed schemas'' that have just been described: It is possible to ``import'' (or ``include'') the variables and predicates that are given in one schema into another. To do so, all you need to do is list the first schema's name in the ``declaration part'' (that is, between the top two horizontal lines) of the second schema.
Here's another useful kind of ``schema decoration.'' If s is the name of a schema defining an object, then the schema ``Delta s'' is the schema one would obtain by including both of the schemas s and s', and including no additional declarations or predicated. In the previous sentence, Delta should actually be replace by the symbol for the Greek letter Delta, in upper case. This looks like an equilateral triangle.
For example, the schema ``Delta Counter'' is understood to include the declarations and predicates shown below, if Counter is defined as above.
We'll save time, and space, by including ``Delta'' schemas in schemas that specify functions operating on objects. Before we show any of these, one more kind of ``decorated'' schema will be described.
If s is the name of a schema defining an object, then the schema ``Xi s'' is understood to be the schema obtained by importing schemas s and s', a predicate
x' = x
for each attribute x of the object defined in s, and including nothing else. In the previous paragraph (and in the following ones, in the names of schemas), ``Xi'' should be replaced by the (upper case) Greek letter Xi. This will appear at the beginning of the name of the next schema that is shown.
Note that in the above predicate, the symbol ``='' stands for a kind of comparison operator - a Boolean function mapping a pair of integers to either true or false. It does not represent an ``assignment statement,'' and the predicate
x = x'
is completely equivalent to (that is, has the same truth value as) the predicate given above.
For example, the schema ``Xi Counter'' is understood to be as follows, if Counter is defined as above.
Note that this is the same as Delta Counter, except that the additional predicate value' = value has been added.
``Xi schemas'' are useful because they can (and should) be included in schemas defining functions that inspect the state of an object without changing it.
Now, here is a final ``naming convention'' used in Z that makes things easier to identify: By convention, the name of a variable that stands for an input for a function should end with a question mark, ``?'', and the name of a variable that stands for an output for a function should end with an exclamation mark, ``!''.
Now, here is a schema that specifies requirements for a function, Set_Counter. This function receives an integer input, value_received?, and returns an integer output, value_used!. If the input is a legal value for the counter then the counter's value is set to be this input value; otherwise, the counter's value is unchanged. The output value is the same as the new value for the counter.
Remember that ``='' stands for a Boolean function, and not an assignment statement, so that the last predicate shown here is equivalent to the predicate
value_used! = value'
which you might have expected instead (given the above informal description of the requirements).
As an exercise (or review of Math 271, or Phil 279, or both), you should confirm that the predicates shown in the schema agree with the English description that appears before it.
Finally, here is a schema specifying a function, Report_Counter, that reports the counter's value without changing it. In particular, it sets the value of its output, value_returned!, to be the counter's value.
As a review of what's been given above, you should convince yourself that an equivalent schema could be obtained by replacing the predicate included in it by the predicate
value' = value_returned!
which replaces value with value'.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Z