3.3 Types

An object can have several types ([ISO95a, Clause 9.7] states that a type is a predicate characterizing a collection of instances), and thus several subtyping hierarchies. Moreover, a type can be attached to or detached from an object. This approach, although often absent in popular implementation mechanisms, is convenient and natural; not only has it been successfully used in specifications [ISO95a,KR94,KMS96], but it has been supported by such implementation mechanisms as subjects [HKOS96]. Out of multiple types of an object, the template type [ISO95a, Clauses 9.11 and 9.19] is the only essential one because a template of an object specifies the common features of a collection of objects in sufficient detail that an object can be instantiated using it. (For example, a person - template type - can also be a homeowner, an employee, a policyholder of an insurance policy, a Republican, a Manchester United supporter, a conference participant (for a particular conference), an author, and so on. Observe also that not all of these non-template types are subtypes of a person: for example, a homeowner or a policyholder is not necessarily a person.) Non-template types are used to separate specification concerns, for example, in specifying viewpoints. They can be attached to or detached from an instance of a template type; however, information (predicates) presented by the non-template types is not sufficient to instantiate an object.

An object state schema will include the set of its types and the set of its (name,context) pairs. The first of these set will always be non-empty, since it will always contain at least the template type of the object, essential for instantiating the object. The latter set is also non-empty since we want to be able to designate an object instance, and identifier usage seems to be the only clear way of doing so shown in RM-ODP. This is also obvious in practice.

The state of the system will include two, possibly three, functions, each having the given Z type [SURROGATE] as the Z type of its domain. The actual domain of each of these functions is the set of surrogates of existing objects. One of the functions maps each surrogate to the set of (name,context) pairs for the object. The second function maps each surrogate to the set of types of the object. If desired, we could also have a function in the system state mapping a surrogate to the set of identifiers of the object. Since the identifiers form a subset of the names, this third function is redundant but this may be useful nevertheless.