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

6.6 Dynamic Behaviour 209
6.6.4 Separation of Data and Control
Traditionally the world of hardware analysis and design strongly emphasises dividing a
system into a data path part and a control part . The data path performs transformations
of data or the transformation of physical objects. The control part switches channels and
controls the activation and deactivation of modules. Channels and controlled modules
form a so-called data path. Traditional methods such as [HP88], [WM85] and Statemate
[Har87] use this approach of separation of data transformation and control. Data is
modelled in stores. Data in stores is shared among data transformations. Sharing
requires accurate modelling of arbitration or protection using semaphores.
Theoretically the state of a system is determined by data in the stores and the state of
the control processes. In practice state is interpreted in these methods as control state.
This state is only determined by the state of the controllers. Controllers (sometimes
called control transformations, control processes or control activities) are modelled using
a finite state machine model. Because controllers do not store any data except the
state variable, state becomes a simple and nameable notion. Complex systems can be
modelled transparently by creating a hierarchy of controllers. The upper level controllers
control the system behaviour mode, lower level controllers enable and disable various data
transforming processes 9 .
This approach makes the methods described above very different from traditional objectoriented
methods. Wegner words this observation (with the focus on languages) as
follows: ’In contrast to the shared-memory model of procedure-oriented programming, objectoriented
programming partitions the state into encapsulated pieces each associated with an
autonomous, potentially concurrent machine’ [Weg90]. This means that the object-oriented
approach distributes system state over many (possibly dynamically created) parallel
objects. This makes the object-oriented concept of state opaque. An implementation in
an object-oriented way makes the system state dispersed. Many autonomous objects
perform a lot of communication, with dynamic creation of objects. Some objects can be
processing while others are waiting for results. The collective state of all the actively operating
objects represents the state of the system. In contrast the traditional control/data
partitioning together with the concept of hierarchical controllers enabled a clear vision
on what a system is actually doing during system operation. We want to keep the merits
of this approach without violation of the essence of object-orientedness.
Named states implemented as (named) behaviour state or variables partial state enable
system design with various views in mind, such as design for testability. Clear models
can be achieved by careful design of the role of objects. Some can play the role of
controllers. Reactive systems tend to have a substantial control part. However, an
emphasis on control leads quickly to a traditional functional mental model of the design.
We must be aware that this is dangerous. Object-oriented methods are not yet accepted
in the main stream of product development laboratories. The step from the functional to
object-oriented approach is recognised as quite difficult, mainly because of the different
9Such structures are described in Subsection 4.8.8 about collaborating supervisors and servants and
hierarchically supervised composites.