Specification of Reactive Hardware/Software Systems - Electronic ...

338 SHE Framework
model of the system environment. Such a model feeds the system model with stimuli
and accepts responses.
An Essential Specification models one or more conceptual solutions that have been selected
to fulfil the needs of the users (the environment) of a system to be developed. The
information in the Initial Requirements Description and the Purpose Description of a
system must match the conceptual solutions. A conceptual solution enables us to find
objects and structures that represent this solution. The level of abstraction of an essential
model must be such that it presents conceptual solutions clearly.
Prescribed technologies and topologies are incorporated into the essential specification.
Of course low level implementation details must be abstracted from. The structure of
an essential model must be designed such that structural constraints that are known
beforehand are respected.
11.2.3 Extended Specification
Milestone 2 indicates the start of the Extended Specification phase. The goal of this phase
is to incorporate decisions for particular implementation technologies in the essential
system requirements. An example can clarify this goal. Messages are passed via ideal
channels in an essential specification. In reality however, channels can be error prone
connections. Appropriate protocols must be selected to implement message passing
via real physical channels. This means that the behaviour of both the sending and the
receiving object must be extended. Instead of the simple behaviour of message passing,
an appropriate protocol behaviour must be implemented. Whether an extension is
required depends in general on the implementation technology that is selected. When
communication between collaborating objects is implemented purely in software, channels
can ’dissolve.’ Communication can be performed by passing references, so that
channels really disappear from the model.
The decision for implementation of system parts in software or hardware and the selection
of communication protocols will in general require substantial extensions and
adjustments of the model. By performing extensions we make the design path from
essence to real implementation passable. The Extended Specification uses the same representation
techniques as the essential specification. Therefore the same techniques can
be used for verification of an essential model as for verification of an extended model.
Similar to the Essential Specification, the Extended Specification contains a behaviour
model (Extended Behaviour Model), and a structure model (Implementation Structure
Model). Again the behaviour model and the structure model must be developed in a
strong interaction. Extended Behaviour and Implementation Structure are formalised
into an Extended Unified formal description in the language POOSL. This description
enables further detailed examination of various system properties via simulation and
verification. The result of these activities must be a correct, rather concrete system
model, so that the step to implementation can be taken with low risk.