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

210 Modelling of Concurrent Reactive Behaviour
ways of thinking. Instead of functions we must look for autonomous entities that
encapsulate data and operations. It appears to be difficult to see that conceptual things
in the problem domain must be modelled as objects too. We tend to see them as values
of data. In fact we have to make this data autonomous, by joining the operations to it,
and by encapsulation of the whole.
It will require mature judgement and careful design to separate data and control in
an object-oriented model soundly. Much depends on the specification style used for
the specification model. Clear control design requires explicit determination and clear
naming of states. It depends on the level of abstraction that is used in the specification
whether this is possible or not. An example can clarify what we mean by specification
style and level of abstraction. Consider two behaviour descriptions that seem to perform
the same behaviour:
1. for i:=1 to 3 do a!m 10
2. a!m;a!m;a!m
Case 2 describes very concrete what the sequential steps are in the behaviour. We can
identify in what behaviour state we are. Case 2 is a static description of behaviour. There
is a sequence of three communication statements. An interpretation of this sequence as
three separate behaviour states is possible. We could give these states names such as
sending first packet, sending second packet, etcetera. Case 1 is a powerful abstract and
more flexible mechanism to describe the same behaviour. In case 1 we cannot directly
recognise the sequence. We cannot simply point to a place in the code to demonstrate in
what state we are. The atomicity of the statements is different, although the descriptions
perform equivalent behaviour.
An analogous naming problem happens when object identifiers are communicated between
objects. The list of acquaintances of an object determines the possible communications
with other objects. This leads to complex dynamic behaviour. In general this
behaviour cannot be grasped easily in explicit nameable states. State information is
distributed over the various objects in the form of dynamic links. In general dynamic
links must be considered as data. State information that is hidden in data limits the
possibilities for verification of a model.
The previous examples show that controllers (supervisors, see Subsection 4.8.8) must
be designed using a relative fine grain of behaviour. A supervisor should preferably
have no other task than controlling the servants that perform a part of the behaviour of
a (sub-)system. A controller is an object whose most important property is its state. This
subsection showed that the hardware implementation design heuristic of separation of
data path and controller can be used in an object-oriented approach.
od.
10 POOSL does not have a for statement. The equivalent POOSL construct is i:=1;do i 3 then a!m;i:=i+1