Information Technology Reference
In-Depth Information
could not have been expressed in either of the viewpoints being linked on their
own.
Correspondences can, in fact, be established between pairs of specification
elements of any relevant kind. In addition to objects and attributes, we may,
for example, establish correspondences between actions or states, and here
it is more likely that the two viewpoints as a whole will be using different
levels of abstraction. One viewpoint may talk about broad business actions,
while the other expresses fine-grained computational actions. In such a case,
the correspondence will involve a part-of relationship, since we can say that
observing the business action implies that the computational action has oc-
curred, but the computational action just implies that the business action is
in progress, not that it has completed.
Another kind of correspondence is found between viewpoints that deal pri-
marily in specifying types (such as the information viewpoint) and viewpoints
dealing primarily with instances (such as the computational viewpoint). Here
the correspondence can be the familiar type-instance relationship. Examples
can be found in links between the types (or templates) defined in the infor-
mation and technology viewpoints and specific configurations defined in the
technology, computational or enterprise viewpoints.
7.3 Correspondences Required by the ODP Architecture
The ODP reference model defines the concepts and rules that make up
the five viewpoint languages, but it leaves as much flexibility as possible for
designers to use them freely to express the system that best meets their re-
quirements. One consequence of this is that it places very few constraints on
exactly what correspondences there should be; they will be decided primarily
by the properties of the problem domain. However, the reference model does,
itself, lay down a few mandatory correspondences, and these are the result of
areas where there are architectural concepts spanning or linking viewpoints.
These correspondences ensure architectural integrity.
We consider two areas where there are architectural constraints. The first
of the areas where correspondences are stated is between the information and
computational viewpoints. Here there is a requirement that the constraints
of the invariant and dynamic schemata, which represent required information
state transitions, should be traceable in the computational view as either
interactions or internal actions of the corresponding computational objects.
This is necessary to demonstrate that the requirements are being met.
The second area is between the computational and engineering viewpoints,
and deals with a set of constraints to ensure that transparencies can be pro-
vided without introducing unexpected snags or side effects as a result of un-
expected feature interactions. The resulting correspondences are sketched in
