A set of specifications of an ODP system written in different viewpoint languages should not make mutually contradictory statements (see 4.2.2), i.e., they should be mutually consistent. Thus, a complete specification of a system includes statements of correspondences between terms and language constructs relating one viewpoint specifications to another viewpoint specification, showing that the consistency requirement is met. The minimum requirements for consistency in a set of specifications for an ODP system is that they should exhibit the correspondences defined in this Reference Model and those defined within the set of specifications itself. This Reference Model does not declare generic correspondences between every pair of viewpoint languages. This clause is restricted to the specification of correspondences between a computational specification and an information specification, and between a computational specification and an engineering specification. In each case, the correspondences are expressed as interpretation relationships linking terms in one viewpoint language to terms in the other viewpoint language. A set of specifications based on this Reference Model will, in general, need to relate all the viewpoint specifications.
The key to consistency is the idea of correspondences between specifications, i.e., a statement that some terms or structures in one specification correspond to other terms and specifications in a second specification. Correspondences can be established between two different specifications in a single language or in two different languages. Statements of correspondences between two languages imply equivalent correspondences between any pair of specifications expressed in those languages.
Analysis of consistency depends on the application of a specific consistency techniques. Most of these are based on checks for particular kinds of inconsistency, and thus cannot prove absolute consistency. One form of consistency involves a set of correspondence rules to steer a transformation from one language to another. Thus given a specification S1 in viewpoint language L1 and specification S2 in viewpoint language L2, where S1 and S2 both specify the same system, a transformation T can be applied to S1 resulting in a new specification T(S1) in viewpoint language L2 which can be compared directly to S2 to check, for example, for behavioural compatibility between allegedly equivalent objects or configurations of objects.
10.1 Computational and information specification correspondences
This Reference Model does not prescribe exact correspondences between information objects and computational objects. In particular, not all states of a computational specification need correspond to states of an information specification. There may exist transitional computational states within pieces of computational behaviour which are abstracted as atomic transitions in the information specification.
Where an information object corresponds to a set of computational objects, static and invariant schemata of an information object correspond to possible states of the computational objects. Every change in state of an information object corresponds either to some set of interactions between computational objects or to an internal action of a computational object. The invariant and dynamic schemata of the information object correspond to the behaviour and environment contract of the computational objects.
NOTE - If the concept of information interface is used in an information specification, there is no necessary correspondence between an information interface and any computational interface.
10.2 Engineering and computational specification correspondences
Each computational object which is not a binding object corresponds to a set of one or more basic engineering objects (and any channels which connect them). All the basic engineering objects in the set correspond only to that computational object.
Except where transparencies which replicate objects are involved, each computational interface corresponds exactly to one engineering interface, and that engineering interface corresponds only to that computational interface.
NOTE - The engineering interface is supported by one of the basic engineering objects which corresponds to the computational object supporting the computational interface.
Where transparencies which replicate objects are involved, each computational interface of the objects being replicated correspond to a set of engineering interfaces, one for each of the basic engineering objects resulting from the replication. These engineering interfaces each correspond only to the original computational interface.
Each computational interface is identified by any member of a set of one or more computational interface identifiers. Each engineering interface is identified by any member of a set of one or more engineering interface references. Thus, since a computational interface corresponds to an engineering interface, an identifier for a computational interface can be represented unambiguously by an engineering interface reference from the corresponding set.
Each computational binding (either primitive bindings or compound bindings with associated binding objects) corresponds to either an engineering local binding or an engineering channel. This engineering local binding or channel corresponds only to that computational binding. If the computational binding supports operations, the engineering local binding or channel must support the interchange of at least
-- computational signature names;
-- computational operation names;
-- computational termination names;
-- invocation and termination parameters (including computational interface identifiers and computational interface signatures).
Except where transparencies which replicate objects are involved, each computational binding object control interface has a corresponding engineering interface and there exists a chain of engineering interactions linking that interface to any stubs, binders, protocol objects or interceptors to be controlled in support of the computational binding.
NOTE - The set of control interfaces involved depends on the type of the binding object.
Each computational interaction corresponds to some chain of engineering interactions, starting and ending with an interaction involving one or more of the basic engineering objects corresponding to the interacting computational objects.
Each computational signal corresponds either to an interaction at an engineering local binding or to a chain of engineering interactions which provides the necessary consistent view of the computational interaction.
The transparency prescriptions in 16 specify additional correspondences.
NOTES
1 Basic engineering objects corresponding to different computational objects can be members of the same cluster.
2 In an entirely object-based computational language, data are represented as abstract data types (i.e., interfaces to computational objects).
3 Computational interface parameters (including those for abstract data types) can be passed by reference, such parameters correspond to engineering interface references.
4 Computational interface parameters (including those for abstract data types) can be passed by migrating or replicating the object supporting the interface. In the case of migration such parameters correspond to cluster templates.
5 If the abstract state of a computational object supporting an interface parameter is invariant, the object can be cloned rather than migrated.
6 Cluster templates can be represented as abstract data types, thus strict correspondences between computational parameters and engineering interface references are sufficient. The use of cluster templates or data are important engineering optimizations and therefore not excluded.