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

11.5 Extended Specification Modelling 367
implementation choices. All these activities have the goal of minimising iterations in
the overall system development process. It is still important, however, that the emphasis
of the modelling is on an exploration of the essence of the system to be designed.
The models must be kept simple, abstract. The models should also be kept relatively
shallow, which implies a small number of hierarchical levels. The main purpose is to
get feedback of users, managers and various other experts that do in general not have
the skills to design an information processing system.
When the essence of the system is modelled, it is time to take various more detailed
design decisions. The evaluation of these decisions and the further development of the
model towards implementation requires peer to peer communication among system
design specialists. So the milestone between the specification phases is determined
by the need to go to a level of detail that is not understandable anymore for users,
marketing experts, etcetera. During the extended modelling phases, the models will
become substantially more complex and therefore less accessible for a broader public.
The step from ’finished’ Essential Specification to the modelling of an Extended Specification
means that the Essential Specification is retained, and copied for use in the
extended modelling phase. Of course we can find new aspects during the extended
modelling phase that can force us to iterate to the Essential Specification. In such a case
we also need discussion with the partners that participated in the first modelling phase
to get their approval for the new points of view.
The amount of design decisions that are left for the extended modelling phase, depends
on the part of the implementation decisions that have been taken in the essential modelling
phase. For complex systems we expect a substantial growth of complexity of the
model after adding the consequences of implementation decisions. In general a lot of
new objects must be introduced in the extension phase. These objects introduce new
behaviour and can make the interaction in the system substantially more complex. This
behaviour must be simulated and validated. All diagrams can need extensions on all
existing levels, and can need extension with additional lower hierarchical levels as well.
In general, the following activities are needed:
Implementation Structure Diagrams are created based on Architecture Structure
Diagrams. This means that channels are marked with chosen protocols and that
the implementation technologies for the various modules are denoted in the diagrams.
These choices include hardware/software partitioning, selection of processors,
mapping of modules on processors, mapping of modules on ASICs, etcetera.
Design decisions are motivated in an Implementation Decisions Statement.
Message Flow Diagrams are extended and changed consistently with Implementation
Structure Diagrams. Objects that model buffers, channels and additional functions
are added. Objects that implement the behaviour of protocols on channels
are introduced. Further various forms of implementations can require additional
behaviour that is typically related to technology. Implementation boundaries and
concurrency boundaries are denoted on clusters.