Information Technology Reference
In-Depth Information
much simpler if they share a common set of primitive types. Fortunately, there
is now a quite broad consensus on the primitive types such as boolean, integer
and string; part 2 of the reference model also provides a uniform foundation
for the object modelling concepts needed.
We then need to express the evolution of the system as a whole by combin-
ing the interpretations of all the corresponding items in the different domain-
specific languages to give a set of rules for the evolution of the complete
system's state.
It is important that the coupling between the viewpoint specifications
should be kept as lightweight as possible. This is why we have stressed the
need to separate the namespaces associated with the different viewpoints. We
need to be able to add elements to a particular viewpoint without incurring
the overheads of ensuring the names being used in the additions are unique
across the whole design, and we need to be able to carry out significant refact-
oring of the design within a viewpoint without requiring matching changes to
be made elsewhere.
All this may sound rather heavyweight, with the potential for more cor-
respondences than model elements in the viewpoints themselves. However,
things are not quite as bad as they may seem. Although there is a need for a
great deal of information in the correspondences, a very high proportion of it
can be inferred from some quite simple rules.
Firstly, despite what was said previously, we can identify certain contexts
in which name equivalence can be taken as implying correspondence. Al-
though, in general, the namespaces of the different viewpoints are unrelated,
and accidental name matches can occur, an organization will often choose to
align parts of these namespaces to aid its own internal communication. In
these situations, stakeholders agree that, as long as there are correspondences
at the type level, names will not be reused for different purposes within the
scope established by the type relations. If this is the case, two elements in
different viewpoints that have the same name can be taken to have an implied
correspondence.
Secondly, we can go even further by asserting correspondence not just
at the type and instance level, but at the level of a complete type system
or subsystem. This may be done by importing a family of type definitions
from one viewpoint into another (or into two viewpoint specifications from an
external library), so that there are automatic correspondences wherever the
shared definitions are used. This kind of sharing is often based on a set of
type definitions from the information viewpoint; these are then used either
directly or via local refinements in other viewpoints.
However, we cannot lose sight of the fact that the correspondences bind
the viewpoints together into a coherent whole, and that the whole, once con-
structed, shows the problems of scale and complexity that led us to opt for
viewpoints in the first place. So what have we gained, after all? Well, the main
design work is carried out in the viewpoints, where life is simpler, and we can
then exploit strong tools to check the consistency of, and derive implementa-
