![[Object Orientation in Z]](ooz2.jpg "[Object Orientation in Z]")
Susan
Stepney, Rosalind Barden, David Cooper, editors.
Copyright © 1992 Logica UK Ltd
Z is one of the more popular formal specification languages [Spivey 1989] , [Hayes 1993] , [Potter et al. 1991] . It makes use of schemas to structure specifications [Woodcock 1989] . But the message coming from many users is that the Z schema is not sufficient for structuring large specifications [Barden et al. 1992] . Many groups of workers are proposing their own extensions to provide various degrees of modularity. Initially, these proposals were based on simple textual devices, such as formal chapters with facilities including import and export statements, generic parameters, and library chapters [Flynn et al. 1990] , [Sampaio & Meira 1990] . These are a start, but something more sophisticated is needed.
Rather than inventing something from scratch, what can be learnt from advances in software structuring techniques? Object orientation is a technology that offers much promise as a means for structuring large, complex software systems [Meyer 1988] , [Cox 1986] , [Booch 1991] . It has overcome the common hype phase to become an approach that is being taken up and used for significant software development.
'Object oriented' means different things to different people. Section 1.2 summarizes some of the more standard definitions, and section 1.3 explains why Z as it stands cannot be described as object oriented.
The papers collected here describe many different proposed approaches for providing Z with an object oriented structuring mechanism. These include attempts to use Z in a more object oriented style, and proposed extensions to Z to allow fully object oriented specifications. The approaches covered here are:
When a new approach is first being described, it is often used to specify examples chosen to highlight its novel and interesting features. But this makes it be difficult to evaluate the alternatives, as there is no common ground for a direct comparison. For this reason, in this collection, each approach has been used to specify the same two problems.
So each chapter follows the same format. First, the particular approach is described. Then it is used to specify a simple example (section 2.2): that of quadrilaterals, with special cases of parallelograms, rhombi, rectangles and squares, along with various operations on them such as 'move' and 'rotate', as might be required by a simple drawing package. Finally, a larger specification is given (section 2.3), to enable a fuller comparison and evaluation. This is a specification of various button icons that could be part of a user interface design, including the specification of how different sorts of buttons react to mouse events.
Z is not the only formal specification language being provided with object oriented extensions. For example, Fresco [Wills 1991] is based on VDM. Chapter 11 has been included to allow a further comparison.
Work has also been done on marrying Z and HOOD (an object-based design notation for Ada) [Giovanni & Iachini 1990] , [Iachini 1991] . This is summarized in appendix A .
In order to explain why Z is not object oriented, we need to define what we mean by 'object oriented'. To do this, we consider Booch's definitions of objects [Booch 1991] , and Wegner's classification scheme [Wegner 1987b] .
Booch provides definitions of 'object' and 'class'. (The page numbers below refer to [Booch 1991] .)
''An object has state, exhibits some well-defined behaviour, and has a unique identity.'' [page 77]
''The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties.'' [page 78]
''Behaviour is how an object acts and reacts, in terms of state changes and message passing.'' [page 80]
''Identity is that property of an object which distinguishes it from all other objects.'' [page 84]
''a message is ... an operation one object performs upon another'' [page 80]
The definition of message is a little different from the conventional one: it is more usual to say that an object's behaviour is defined in terms of its operations (or methods), and that another object sends a message requesting the execution of an operation. In other words, objects are not thought of as performing operations on other objects, rather they perform operations on themselves, in response to requests. This terminology better emphasizes objects' autonomy.
Booch defines a class to be the abstraction mechanism:
''the structure and behaviour of similar objects are defined in their common class'' [page 77]
''A class is a set of objects that share a common structure and a common behaviour.'' [page 93]
''A single object is ... an instance of a class.'' [page 93]
These definitions are a little difficult to reconcile: is a class the set of all its actual instances, or of all its potential instances, or is it a description (abstraction) of the commonality of its instances?
Wegner provides a classification scheme for languages: object based, class based and object oriented. (The page numbers below refer to [Wegner 1987a] .)
''An object has a set of 'operations' and a 'state' that remembers the effect of the operations.'' [page 168]
Wegner, unlike Booch, does not explicitly mention identity.
''A language is object-based if it supports objects as a language feature.'' [page 169]
Although Z can be used to specify state and operations by using schemas, it does not actually 'support objects as a language feature', and so cannot truly be called even object based by this definition. However, if the definition is interpreted sufficiently loosely, the fact that Z supports a 'state and operations' style of specification can be used to say it does in some sense support objects.
''A class is a template ... from which objects may be created by 'create' or 'new' operations. Objects of the same class have common operations and therefore uniform behaviour.'' [page 169]
Since 'operation' hasn't been defined, it is not possible to deduce whether operations are applicable only to objects (that is, whether they are what are usually called 'methods'). If 'new' or 'create' are methods, it implies classes are objects, as is done in Smalltalk [Goldberg & Robson 1983] , with all the associated problems this has. However, the definition certainly implies that a class is not some sort of 'collection of all objects', but is a process that outputs objects. Wegner nowhere uses the conventional phrase 'an object is an instance of a class'.
''A class may inherit operations from 'superclasses' and may have its operations inherited by 'subclasses'. An object of the class C ... has C as its 'base class' and may use operations defined in its base class as well as operations defined in superclasses.'' [page 169]
[Wegner 1987a] , [Wegner 1987b] goes on to identify two kinds of inheritance. With strict inheritance (defined above), descendants are behaviourally compatible with their ancestors. This is also called the is-a relation: a dog is-a mammal, etc. The definition ought also to say an object must be able to use operations of its superclasses, in order that it can be used 'in place of' any object higher up the hierarchy. Non-strict inheritance captures the notion of similarity rather than compatibility, and operations can been modified or removed. This is also called the like relation: an emu is like a bird, but it can't fly, etc.
The fact that the state cannot be hidden in Z is not a problem (as far as Wegner's definitions go); data abstraction is a separate, orthogonal feature:
''A data abstraction is an object whose state is accessible only through its operations.'' [page 170]
Wegner's definition of a fully object oriented language is
''An object-based language is object-oriented if its objects belong to classes and class hierarchies may be incrementally defined by an inheritance mechanism.'' [page 169]
Z can be used to specify a state (via a schema) and behaviour (as operation schemas). However, Z does not support the grouping of operations on a particular state (except possibly textually), the application of these operations to different instances, or inheritance of these properties.
Using Wegner's classification, we can say (in the letter, if not the spirit, of the definitions) that Z is object based (it 'supports' objects), but certainly it is not object oriented .
Objects are physical, concrete things which exist in the 'real' world, the classes they belong to are abstractions we build, and do not have their own existence. You can sit on a particular chair, but you cannot sit on, or even point to, an abstraction common to all chairs: the class of all chairs. (This view is not undisputed. The Platonic view gives a greater reality to an abstract class than to its imperfect instances, because we perceive the 'real' world only through a filter.) Even more abstract are the hierarchies we places these classes in. The class of chairs could occur in a hierarchy along with the class of tables, both below the class of furniture --- but this hierarchy of abstractions also has no concrete existence of its own.
Since it is we who choose the classes and hierarchies, which have no independent existence, it is not surprising, and we should not worry, that sometimes the questions 'which class does this object belong to?' or 'where do these classes fit in the hierarchy?' have poorly defined answers. There is a further point: although objects have their own existence, again it is we who choose where the boundary between object and not-object is drawn; this boundary also has no existence in its own right. So even the question 'is this an object?' can have a poorly defined answer.
We choose how to divide the world into discrete objects, how to group objects we think are alike into classes, and how to arrange classes in hierarchies based on similarities we perceive. In each case we could make a different choice. This should be seen as an opportunity, not as a problem: we can choose the classifications to suit ourselves, in order to simplify the model we are trying to build, to make the problem we are trying to solve easier.
There is 'no one right way' to do the modelling; some choices will be better for some aspects of the problem, other choices better for other aspects, but probably no choice will be best for all aspects. [Peterson 1988] sums up well what we should be looking for in the models we build when he says: The idea is not to paint a realistic portrait but to capture the spirit of the phenomenon with a caricature.