Information Technology Reference
In-Depth Information
blocks that modify or filter the stream being carried. One can, for example,
define bindings that link stream interfaces with different properties, so that,
for example, a colour video source is linked to a black and white presentation
object. If the flows are continuous sequences of report data, perhaps in a
telemetry application, we can define bindings between flows of different data
types to select a specific view, merge streams from different sources, or convert
between different data formats. In this way, typed binding objects offer a
powerful technique for structuring and reuse in application design.
4.7 Relationship with Other Viewpoints
As we have seen, the computational viewpoint specification is not normally
designed in isolation, but is typically created after first drafts of the enterprise
and information specifications are available (or, at least, in parallel with them).
For example, a first step in producing the computational specification of
a system consists of deciding the right configuration of computational ob-
jects and the interactions among those objects that guarantee that the system
functionality is fulfilled, as prescribed by the enterprise specification. The de-
scription of these computational objects and interactions should also be done
at the appropriate level of abstraction, and they need to manipulate the infor-
mation handled by the system as prescribed by the information specification.
This is why the elements in the enterprise and the information specifications
can be used effectively for identifying the computational objects and their
interactions.
A different designer could also use a bottom-up approach if there are al-
ready good commercial off-the-shelf (COTS) or legacy components in the or-
ganization that can be used in the new system. Computational objects en-
capsulating the functionality of such legacy or COTS components are perfect
candidates for the specification.
Once identified, computational objects may be grouped into packages fol-
lowing a particular software architecture, such as collecting business-oriented
objects within the same layer, and common functions or UI objects in oth-
ers. Such a structure is what constitutes and defines the software architecture
of the system. For the behaviour, many of the computational interactions
will be derived (using refinement, for instance) from the dynamic schemata in
the information viewpoint specifications. Finally, enterprise policies relating
to the system's business rules, together with information invariant schemata
that control the state changes and integrity constraints on the system data,
can serve as a starting point to specify the environment contracts for the
computational objects and their interactions.
Where a policy is identified in the enterprise viewpoint, the associated
behaviour is expected to be mutable, so the computational structure must
