9 Specification concepts

9.1 Composition:

a) (of objects) A combination of two or more objects yielding a new object, at a different level of abstraction. The characteristics of the new object are determined by the objects being combined and by the way they are combined. The behaviour of a composite object is the corresponding composition of the behaviour of the component objects.

b) (of behaviours) A combination of two or more behaviours yielding a new behaviour. The characteristics of the resulting behaviour are determined by the behaviours being combined and the way they are combined.


1 - Examples of combination techniques are sequential composition, concurrent composition, interleaving, choice, and hiding or concealment of actions. These general definitions will always be used in a particular sense, identifying a particular means of combination.

2 - In some cases, the composition of behaviours may yield a degenerate behaviour, e.g. deadlock, due to the constraints on the original behaviours.

9.2 Composite object: An object expressed as a composition.

9.3 Decomposition:

a) (of an object) The specification of a given object as a composition.

b) (of a behaviour) The specification of a given behaviour as a composition.

Composition and decomposition are dual terms and dual specification activities.

9.4 Behavioural compatibility: An object is behaviourally compatible with a second object with respect to a set of criteria (see notes) if the first object can replace the second object without the environment being able to notice the difference in the objects' behaviour on the basis of the set of criteria.

Typically, the criteria impose constraints on the allowed behaviour of the environment. If the criteria are such that the environment behaves as a tester for the original object, i.e. the environment defines the smallest behaviour that does not constrain the behaviour of the original object, the resulting behavioural compatibility relation is called extension.

The criteria may allow the replacement object to be derived by modification of an otherwise incompatible object in order that it should be an acceptable replacement. An example of such a modification might be hiding of additional parameters on certain interactions. In this way, an interaction of the new object can be made to look like an interaction of the original object. In such cases behavioural compatibility is called coerced behavioural compatibility. If no modification is necessary, behavioural compatibility is called natural behavioural compatibility.

The concept of behavioural compatibility defined above on objects applies equally well to the behavioural compatibility of templates and of template types.

Behavioural compatibility is reflexive, but not necessarily symmetric or transitive (though it may be either or both).


1 - The set of criteria depends on the language in use and the testing theory applied.

2 - Behavioural compatibility (with respect to a set of criteria) can be defined on template (see 9.11) and template types (see 9.19) thus:

a) if S and T are object templates, S is said to be behaviourally compatible with T if and only if any S-instantiation is behaviourally compatible with some T-instantiation (see 9.13);

b) if U and V are object template types, U and V are said to be behaviourally compatible if their corresponding templates are behaviourally compatible.

9.5 Refinement: The process of transforming one specification into a more detailed specification. The new specification can be referred to as a refinement of the original one. Specifications and their refinements typically do not coexist in the same system description. Precisely what is meant by a more detailed specification will depend on the chosen specification language.

For each meaning of behavioural compatibility determined by some set of criteria (see 9.4), a specification technique will permit the definition of a refinement relationship. If template X refines a template Y, it will be possible to replace an object instantiated from Y by one instantiated from X in the set of environments determined by the selected definition of behavioural compatibility. Refinement relationships are not necessarily either symmetric or transitive.

9.6 Trace: A record of an object's interactions, from its initial state to some other state.

A trace of an object is thus a finite sequence of interactions. The behaviour uniquely determines the set of all possible traces, but not vice versa. A trace contains no record of an object's internal actions.

9.7 Type (of an <X>): A predicate characterizing a collection of <X>s. An <X> is of the type, or satisfies the type, if the predicate holds for that <X>. A specification defines which of the terms it uses have types, i.e. are <X>s. In RM-ODP, types are needed for, at least, objects, interfaces and actions.

The notion of type classifies the entities into categories, some of which may be of interest to the specifier (see the concept of class in 9.8).

9.8 Class (of <X>s): The set of all <X>s satisfying a type (see 9.7). The elements of the set are referred to as members of the class.


1 - A class may have no members.

2 - Whether the size of the set varies with time depends on the definition of the type.

9.9 Subtype/supertype: A type A is a subtype of a type B, and B is a supertype of A, if every <X> which satisfies A also satisfies B.

The subtype and supertype relations are reflexive, transitive and anti-symmetric.

9.10 Subclass/superclass: One class A is a subclass of another class B, and B is a superclass of A, precisely when the type associated with A is a subtype of the type associated with B.

NOTE - A subclass is by definition a subset of any of its superclasses.

9.11 <X> Template: The specification of the common features of a collection of <X>s in sufficient detail that an <X> can be instantiated using it. <X> can be anything that has a type (see 9.7).

An <X> template is an abstraction of a collection of <X>s.

A template may specify parameters to be bound at instantiation time.

The definition given here is generic; the precise form of a template will depend on the specification technique used. The parameter types (where applicable) will also depend on the specification technique used.

Templates may be combined according to some calculus. The precise form of template combination will depend on the specification language used.

9.12 Interface signature: The set of action templates associated with the interactions of an interface.

An object may have many interfaces with the same signature.

9.13 Instantiation (of an <X> template): An <X> produced from a given <X> template and other necessary information. This <X> exhibits the features specified in the <X> template. <X> can be anything that has a type (see 9.7).

The definition given here is generic: how to instantiate an <X> template depends on the specification language used. Instantiating an <X> template may involve actualization of parameters, which may in turn involve instantiating other <X> templates or binding of existing interfaces (see 12.4).


1 - Instantiating an action template just results in an action occurring. The phrase "instantiation of an action template" is deprecated. "Occurrence of an action" is preferred.

2 - If <X> is an object, it is instantiated in its initial state. An object can participate in interactions immediately after its instantiation.

3 - Instantiations from different templates may satisfy the same type. Instantiations from the same template may satisfy different types.

9.14 Role: Identifier for a behaviour, which may appear as a parameter in a template for a composite object, and which is associated with one of the component objects of the composite object.

Specification of a template as a composition of roles enables the instantiation process to be explained as the association of a specific component of the resultant composite object with each role. The association of a component object with a role may result from the actualization of a parameter.

9.15 Creation (of an <X>): Instantiating an <X>, when it is achieved by an action of objects in the model. <X> can be anything that can be instantiated, in particular objects and interfaces.

If <X> is an interface, it is either created as part of the creation of a given object, or as an additional interface to the creating object. As a result, any given interface must be part of an object.

9.16 Introduction (of an <X>): Instantiating an <X> when it is not achieved by an action of objects in the model.


1 - An <X> can be instantiated either by creation or introduction but not both .

2 - Introduction does not apply to interfaces and actions since these are always supported by objects.

9.17 Deletion (of an <X>): The action of destroying an instantiated <X>. <X> can be anything that can be instantiated, in particular objects and interfaces.

If <X> is an interface, it can only be deleted by the object to which it is associated.

NOTE - Deletion of an action is not meaningful: an action just happens.

9.18 Instance (of a type): An <X> that satisfies the type.

9.19 Template type (of an <X>): A predicate defined in a template that holds for all the instantiations of the template and that expresses the requirements the instantiations of the template are intended to fulfill.

The object template subtype/supertype relation does not necessarily coincide with behavioural compatibility. Instances of a template type need not be behaviourally compatible with instantiations of the associated template. They do coincide if

a) a transitive behavioural compatibility relation is considered, and

b) template subtypes are behaviourally compatible with their template supertypes.


1 - This concept captures the notion of substitubility by design.

2 - The form of the predicate that expresses the template type depends on the specification language used.

3 - As a shorthand, "instances of a template T" are defined to be "instances of the template type associated with template T".

4 - Figure 1 illustrates the relationships between some of the concepts: template type, template class, etc. The set of instances of t contains both the set of instantiations of t and the sets of all instantiations of subtypes of t. The sets of instantiations of different templates are always disjoint.

Figure 1 - Relationship between templates, instantiations and instances.

9.20 Template class (of an <X>): The set of all <X>s satisfying an <X> template type, i.e. the set of <X>s which are instances of the <X> template. <X> can be anything that has a type (see 9.7).

Each template defines a single template class, so we may refer to instances of the template as instances of the template-class.

The notion of class is used to refer to a general classification of <X>s. Template class is a more restrictive notion where the members of a template class are limited to those instantiated from the template (or any of its subtypes), i.e. those <X>s which satisfy the <X> template type.

NOTE - Given a template type, we may shorten statements of the form "the template class associated with template A is a subclass of the template class associated with template B" to "template A is a subclass of template B" or "template A is a subtype of template B".

9.21 Derived class/base class: If a template A is an incremental modification of a template B, then the template class CA of instances of A is a derived class of the template class CB of instances of B, and the CB is a base class of CA.

The criteria for considering an arbitrary change to be an incremental modification would depend on metrics and conventions outside of this Recommendation | International Standard. If the criteria allow, a derived class may have several base classes.

The incremental modification relating templates must ensure that self-reference or recursion in the template of the base class becomes self-reference or recursion in the template of the derived class.

The incremental modification may, in general, involve adding to or altering the properties of the base template to obtain the derived template.

Classes can be arranged in an inheritance hierarchy according to derived class/base class relationships. This is the interpretation of inheritance in the ODP Reference Model. If classes can have several base classes, inheritance is said to be multiple. If the criteria prohibit suppression of properties from the base class, inheritance is said to be strict.

It is possible for one class to be a subclass of a second class without being a derived class, and to be a derived class without being a subclass. The inheritance hierarchy (where arcs denote the derived class relation) and the type hierarchy (where arcs denote the subtype or subclass relation) are therefore logically distinct, though they may coincide in whole or in part.

9.22 Invariant: A predicate that a specification requires to be true for the entire life time of a set of objects.

9.23 Precondition: A predicate that a specification requires to be true for an action to occur.

9.24 Postcondition: A predicate that a specification requires to be true immediately after the occurrence of an action.