3.5 Attaching and detaching a type

Attaching a type is handled through an operation which adds a new predicate to the set of predicates in the object's state schema. The promoted operation on the system state schema modifies the corresponding value of the function mapping each surrogate to the set of the object's types. Detaching a type is handled similarly by deleting a type from the set of types which is both a component of the object state schema and a value of the correspondong function in the system state schema. However, the template type may not be deleted and must continue to be satisfied.

This introduces the notion of a context (rather close to the Z global property) which is essential for real life specification. Many components in such a specification can be understood, used and reused only within a context. A significant difference between our toolkit and the standard Z mathematical toolkit is the greater importance of the context for the specification and understanding of objects.

To achieve the full generality of type treatment in RM-ODP, we would like to allow objects acquiring and losing types not just to change appropriate property values, but also to acquire and lose properties - attributes with a particular value. Unfortunately, Z does not allow us to use the rather straightforward approach to specifying this in general that we used for names and types. For them we could easily use a set in Z since the elements were all of a consistent Z type: the Cartesian product of NAME and NAMINGCONTEXT for (name,context) pairs and the power set of the class of objects for types (predicates) of objects in the class. The properties which might conceivably belong to a given object are numerous and varied, in general, and could not reasonably be specified as any single Z type. It is possible in Z to effectively add new components to the state schema of an object by defining a new schema which includes a reference to the old schema along with the new components. In general, there is no corresponding ploy for deleting components, although hiding and quantification can some times achieve the desired effect. The idea of assigning a dummy nil value seems more to suggest that the true value is unknown or has not yet been assigned than to indicate that the component in question should not have been there in the first place.

The Z free type construction can be used to build up a Z type which represents a union of several different Z types. As a general approach, especially for business specifications, this seems inadequate. Even for a specific business specification in Z, this approach would require a remarkable degree of clairvoyance to foresee all the properties which might ever belong to the objects specified. Actually, only the Z types of the properties need to be divined at the beginning, not the exact values. A discussion about whether we need to foresee all possible properties is going on (electronically and otherwise) in some OMG groups in which the semantics of ``roles" is being considered.

The free type construction is a considerably more plausible approach for a system specification. With early knowledge of the approximate size and complexity of the system being specified, one could perhaps construct a sufficiently rich Z free type to provide good representations for all of the system objects and their properties. This would likely be based on integers and strings and a few iterations of Cartesian product and power set. The state schema of an object could then be specified to include a set of elements of this free type. To represent the addition and deletion of properties of system objects, elements would be added to or deleted from this set. The only clairvoyance needed is that required to construct a Z free type sufficiently rich to reasonably represent the general nature of properties of objects in the system specification. The exact values would be specified later, for example, as operations are defined. As in the treatment of names and types, there would be the corresponding system state function mapping each surrogate to the corresponding component of the object state, in this case the set of its property representations. Thus, for each new (previously unknown) property type specified in a business specification, a mapping should be produced to (previously known) property types of a system specification.

[ISO95a] does not prohibit an instance from having more than one template type. This may be important, in particular, for specifying viewpoints. These template types should be mutually consistent, so that the conjunction of their invariants should not be false. Moreover, it seems to be possible to change the template type for an instance. These issues have not been explicitly treated in [ISO95a], but their treatment becomes essential as soon as the concepts described semi-formally are to be formalized. This is a very important (and relatively well-known) advantage of formalisms! Satisfaction of the object type is not sufficient: most objects participate in relationships and therefore must satisfy the invariant of these relationships.