3.7 Composite objects

In order to express such an invariant for a generic composition relationship, we will have to recall that the specification of a generic composition refers to a composite type and a finite non-empty set of component types, and to a composite instance and a possibly empty set of component instances of each of these component types. (More detailed information is provided for various subtypes of the generic composition, see [ISO95c,KR94].) In some cases, particularly those in which the different components play quite different roles in the composite object, it may be clearer to consider an ordered tuple of components rather than a set (``ordered composition" is a subtype of a composition). We will also state that, for each instance of a composition relationship, the set of types of the composite instance is not equal to the set of types of any of its component instances.

Specifying these properties in Z is rather straightforward. To begin with, we will use the same approach to specifying the set of known instances of a particular composite object as we used to specify the set of known instances of isolated objects: these sets are represented, through the objects' surrogates, by the domains of appropriate functions. As mentioned earlier, creating a new instance of an isolated object adds a new pair to the ``surrogate-object" function for a new surrogate value; deleting an instance of an object deletes the corresponding pair. Similarly, in the simple case, creating a new composition instance adds a new pair to the ``composite instance-sets of its component instances" relation; and deleting an instance of a composition deletes the corresponding pair. In the more complex situation, we modify the Z relation representing the relationship between the composite object and its components by adding, changing, or deleting elements of the component set.

When a new composite object is to be created, some extra care must be taken. A number of conditions must be checked and each of the possible errors handled in some appropriate way. First, each of the component object instances must exist and satisfy its individual invariant. Secondly, the would generally be an additional precondition concerning the collective state of the whole set of component objects. Only when all of these conditions are satisfied could the composite object be created with its own invariant.

It is substantially more complicated to specify in Z that there exist two kinds of properties of the composite instance: those independent of any components, and those determined by properties of these components and therefore having values changeable as a result of adding/deleting a component, or changing a component's properties. A composite instance should have at least one property of each of these kinds. As a simple example, consider a document, such as the proceedings of a conference, as a composition of chapters: the title and author of the document are properties of the first kind, while the number of pages and the abstract - properties of the second kind (observe that there is no automated way to calculate the value of the abstract!).

This approach is very close to the one used in the mathematical toolkit: indeed, both (formal parameter) sets and their elements are referred to in the specification of injection; and it is quite possible to imagine ``structured" elements (eg pairs of an injection!) used either as actual parameters, or even as formal parameters to define an injection for which both the source and target are injections.