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

2.6 Activity Frameworks for Specification Development 29
using different models. In the stepwise refinement approach described above the architectural
view and the refined behavioural view are developed simultaneously, but they
are represented by a single model. This yields the problem that the architectural view
is not explicitly developed. It is the implicit result of behaviour decomposition. This is
due to the classical confusion between implementation dependence and level of detail
[WM85]. High level details of a system are regarded to belong to the requirements
definition, whereas low level details are thought to belong to, and lead towards, the
implementation.
An activity framework must allow different modelling views as
well as the unified model to be developed in a simultaneous, evolutionary
fashion. To avoid confusion between different views,
they must be explicitly represented.
Determining System Behaviour
The external behaviour of a reactive system is so complex that it is quite impossible
to specify it or even understand it in its entirety. Behaviour partitioning by identifying
autonomous objects (that each perform a cohesive part of it) makes complexity
manageable. The LotoSphere method [Pir92] states that it is rather straightforward to
derive a behaviour model, refraining from any internal structure, from the initial requirements.
This may be true for simple telecommunication systems 9 , but it is certainly not
the case for systems with complex observable behaviour. The observable behaviour of
complex systems is unknown in advance, but ’arises’ while designing the objects (and
their behaviour) that constitute the system. Therefore it is important that the activity
framework of a specification method allows the determination of observable behaviour
by considering the internals of a system.
An activity framework must allow the determination of observable
behaviour by considering the internals of a system.
Object Structure and Behaviour
Most object-oriented specification methods do not suffer from the problems related to
pure stepwise refinement. Exceptions are HOOD [Rob92] and HRT-HOOD [BW95],
which use a top-down decomposition approach to find objects. Other methods [R
CY91a, CY91b, SM88, Mor94, Boo91] start by creating conceptual views (often called
object models). These views consist of classes of objects and the conceptual relations
that exist between these classes. Classes are found by studying entities that exist in
the real world. These entities can either be located inside or outside the system to
develop. The Behaviour modelling is postponed until object models become stable.
The reason that most object-oriented specification methods develop a conceptual view
first, is that behaviour is expected to change frequently during the lifetime of a system.
Object structures, on the other hand, are more stable in the long run [Boo86]. We
agree with this point of view, but deny that object structures should therefore be found
9 Sometimes these systems behave externally as simple buffers.
91,