Information Technology Reference
In-Depth Information
reflect this fact. One possible technique is to introduce an explicit indirection,
which invokes a policy value object that interprets the policy. The behaviour
defined as part of the policy (see the description of the policy envelope in
chapter 10) can then modify or replace this object without affecting the rest
of the design. For example, a policy may be identified, based on marketing
decisions, that varies the charge for repairs when the work is completed late.
If there is a change in this policy from offering an immediate discount to giving
credit for future repairs, the object that calculates the charge will need to be
modified; this will be easier to do if the object is clearly separated from other
parts of the billing process.
Of course, the three viewpoint specifications considered so far have con-
straints on each other, and usually each viewpoint specification is revised and
refined as the others are developed.
Finally, not all elements in the computational specification need to corre-
spond to elements in either of the other two viewpoints, and not all objects
in the other specifications have computational equivalents. Each viewpoint
focuses on a different aspect of the system, and is expressed using a different
language. Therefore, their elements are different. However, they are all views
of the same system, and therefore many of their elements represent views of
the same system entities. This means that the view should be consistent and
no views can impose contradictory requirements on the system. For example,
the enterprise policies should be consistent with the invariant schemata of the
information viewpoint, and with the computational environment contracts. In
ODP, correspondences (see chapter 7) are used to specify in an explicit way
the relationships between the elements of two different viewpoint specifica-
tions. Therefore, correspondences become essential elements for checking the
consistency between the views.
