3.6 Non-isolated Objects and Generic Relationships

Despite the (over-)emphasis on isolated objects, their classes and subclasses in traditional, legacy, OO modeling, objects do not exist and cannot even be understood in isolation. This is acknowledged in [ISO95a] and, especially, in [ISO95c]. It is also quite well-known that the ideas of collective state and behavior are not new - consider the remark in [Hal60]: ``...the familiar axiomatic approach to elementary geometry [...] does not offer a definition of points and lines; instead it describes what it is that one can do with these objects." (Thus, we do not offer a definition of an object nor a definition of an entity.)

Following these considerations, we may observe that in most cases an operation, in particular, creation or deletion of an object, refers to other, related, objects. In other words, the pre- and postconditions of such an operation refer to properties of other objects. The same is true with respect to the invariant of this operation.

It seems to be relatively straightforward to define collections of objects in this manner, and Z provides excellent ways for doing so. However, in order to provide a reusable library - like a mathematical toolkit - for generic relationships (like hierarchical ordered composition), we will need to use non-elementary parameters, in the same manner as the mathematical toolkit does. In particular, we will need to explicitly refer to ``structured" formal parameters. That is, firstly, we must specify ``below the line" of a Z schema the properties of these parameters of interest to the user of our toolkit and thus be able to check whether the corresponding actual parameters satisfy these properties. Secondly, we must be able to refer, in the toolkit, both to these parameters and to their components. In other words, we want to specify generic invariants of constructs (such as relationships) of our toolkit. Consider the generic composition relationship, also known as ``aggregation", as an example.