PREV
| TOP | NEXTa) (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.
NOTES
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.
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.
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).
NOTES
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.
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.
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.
NOTES
1 - A class may have no members.
2 - Whether the size of the set varies with time depends on the definition of the type.
The subtype and supertype relations are reflexive, transitive and anti-symmetric.
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.
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).
NOTES
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.
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.
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.
NOTES
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.
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.
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.
NOTES
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.
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".
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.23 Precondition: A predicate that a specification requires to be true for an action to occur.