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

172 Modelling of Concurrent Reactive Behaviour
also on the state of the buffer. An empty buffer cannot perform a rendezvous with the
receiver.
Buffered communication requires special attention for a situation where a buffer is full.
We have to decide whether or not we accept loss of information. If there are one or more
messages in a buffer, we can identify various situations.
1. The buffer stores an infinite number of messages, and keeps them available for the
receiver.
2. The buffer stores a finite number of messages, and keeps them available for the
receiver. So the buffer may become full. We can discard either:
a) the new message arriving at the full buffer, or
b) the oldest message in the buffer.
3. A special case of a finite buffer is a one place buffer. It has the same discard options
as in case 2.
We can specify the sort of buffered communication by adding symbols to a buffer. The
symbols ¥ n¥ 1 model respectively cases 1,2 and 3, as is shown in Figure 6.8. All sorts can
be modelled straightforward in POOSL. A buffer object with the appropriate behaviour
must be defined. We can also specify the possible forms of discard messages graphically.
Figure 6.9 shows the use of an additional curved arrow to visualise the discarding of
messages. In case a) a new message arriving at the full buffer will be discarded, and in
case b) the oldest message in the buffer will be discarded at the arrival of a new message.
A guideline for modelling the behaviour of buffers is that the buffer should be active
together with the sender. A buffer can be modelled as a separate process object in the
POOSL description. We must guarantee that the buffer can always respond to a message
from the sender, so that the rendezvous is finished always. We recommend to cluster a
buffer object at the sender side. The receiver may or may not wish to communicate with
the buffer.
So far we modelled an asynchronous flow with the premise that the sender can always
perform its rendezvous. Consequently we needed a discard mechanism when the
n-place buffer is full. An alternative approach is that the buffer does not finish the
rendezvous when it is full. Both alternatives can be used as an approximation for an
infinite buffer. The designer is responsible to make the buffer large enough. In general
we recommend to define a warning to notify that a buffer is full or that a message has
been discarded.
From our modelling experience so far we have the impression that we do not need
asynchronous communication so often in a specification on system level. We can model
a lot of situations with asynchronous concurrent process objects that communicate synchronously.
On the lower levels of abstraction (the extended behaviour modelling) we
will need asynchronous forms of communication, such as a handshake protocols, more
often.