Information Technology Reference
In-Depth Information
computational specification, and should therefore always be addressed by the
engineering specifications. A more detailed discussion of transparencies can
be found in chapter 9.
The selection of these transparencies simplifies the computational speci-
fication, hiding the problems and complications of having to deal with the
replication of some components or connectors to increase the overall system
reliability and availability, or with the need to know the location of services
before you can invoke them, for example. In this respect, transparencies pro-
vide a very effective mechanism for achieving a sensible separation of concerns
between the basic functionality of the system and other aspects that can be
specified in a modular way and plugged-in according to particular user re-
quirements.
ODP defines standard functions and structures to realize distribution
transparencies, so that a conforming ODP system can implement those trans-
parencies in accordance with the relevant standards. However, there are per-
formance and cost tradeoffs associated with each transparency and only a
selection of the transparencies will be relevant in many cases. Thus, not all
transparencies are required for every system. It is up to the designer to se-
lect the specific distribution transparencies that need to be applied to each
computational specification.
4.6 Writing Computational Specifications
Apart from relying on a set of well-defined concepts and mechanisms for
expressing computational objects, interfaces and interactions, the designers
also need some guidelines and structuring rules for writing the computational
specifications of their system. This section offers some guidelines on how to
do it.
4.6.1 Division into Components
We normally start by specifying the high-level software architecture of the
application. Such an architecture will provide the big picture of the system,
describing the key computational objects in the system, and how they interact
to achieve the application's goal.
By software architecture we mean the structure and organization of the
system, defined in terms of software elements (components, connectors), the
externally visible properties of those elements, and the relationships among
them [49]. This structure also defines the principles and guidelines governing
how the design is to be allowed to evolve over time [71]. It provides the
basis for satisfying both functional and non-functional requirements on the
system [81, 82].
