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

152 Modelling of Concurrent Reactive Behaviour
rency instead of asynchronous concurrency is Statemate [Har92]. Dynamic behaviour
in Statemate is described in the Statecharts formalism. Statecharts are based on the socalled
synchrony hypothesis. Models in Statecharts run in so-called lockstep, which means
that they all synchronise after each computation step. The approach is based on the
assumption that the system is much faster than its environment. The results of all operations
in all modules that start on the reception of events or messages are supposed to
be ready before a new synchronous step of all operations is started. The execution-time
of the services is abstracted from and therefore put to zero. These assumptions make
this method less suitable for complex reactive distributed systems.
In general software modules do not run in lockstep. The relative speeds of operations
may differ substantially. Many software systems are implemented as pseudo concurrent
systems by using multiprogramming. A model based on the synchrony hypothesis is
inadequate to model this type of behaviour.
The object-oriented method OMT [R 91] bases its dynamic model on the Statecharts
formalism from Statemate [Har92]. In our point of view this formalism is not suitable
for straightforward implementation in an object-oriented method. We come back to this
subject in Paragraph 6.3.3.4 about messages, sharing and distribution.
6.2.2.7 Design Decisions for Concurrency
We defined process objects as asynchronous concurrent entities. Process objects have
sequential internal behaviour. An alternative would have been to make their internal
behaviour concurrent too. In Subsection 9.7.1, (The Grain of Concurrency) this decision
is motivated from a semantical point of view. From an analysis point of view we
also prefer asynchronous concurrency and internal sequential behaviour. It enables an
elegant coupling of the grain of concurrency, the grain of abstraction (the shell of process
objects), and the grain of modules (process objects or clusters). Internal parallelism can
be modelled by clusters. Their internal behaviour is in this case modelled by a parallel
composition of process objects and/or other clusters.
Besides concurrency we must be able to express sequential behaviour. We can express
this straightforwardly because process objects are internally sequential. In addition we
want to be able to describe that a collection of collaborating objects behaves sequentially
as a whole. This can be specified by drawing a concurrency boundary (see Paragraph
5.8.2.4). Another very important reason to make processes the grain of concurrency is
that it constrains coding of classes to sequential programming. Humans think preferably
in terms of sequences of actions. Of course, the problem of designing a system with
multiple threads that must synchronise remains. However, it is limited to the communication
and synchronisation of single threaded processes instead of multiple threaded
processes. In the latter case we would require communication and synchronisation
between threads in the processes as well.
The implementations we aim at are implementations in synchronous digital circuits
and/or software. Hardware can consist of various concurrent processes which can be