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

6.3 Communication 167
can be described as transitions from state to state. The conditions that decide whether
a transition takes place or not, can often be modelled as events. In Section 6.4, about
dynamic behaviour, we describe how we model events and states. The happening of an
event can be communicated with a single message flow symbol.
Another useful notion is command. Some messages can be interpreted as commands. In
general, such messages do not have to carry data. There is not much difference with
an event in this case. A command denotes the notion of an order, a control assignment,
or a decree to the receiver of the message. The sender does not expect an answer, but
simply expects the receiver to perform the requested operation(s). A command may
stop or initiate behaviour of the receiver. A command may be extended with data.
Data can specify which operation(s) must be performed. Data can also be given to be
operated upon. Recall that the sending object does not expect a result, so it can continue
its operations immediately. This is powerful when we want to describe concurrent
behaviour.
Synchronous message passing without reply may be performed by an object that does
expect a reply. The term without reply is based on the fact that the sender does not suspend
its activities during the waiting for a reply. We need two separate communications when
we want to model the true concurrent form of synchronous communication with reply
but without waiting. So we need two flows in opposite direction to model this. The use
of two flows clearly indicates the relative independence of both communications. Both
sender and receiver continue their operations until they change roles for the transmission
of the reply on the initial request.
Notice that the text on the flows is very important for the interpretation of the flow. We
give some guidelines here. A name containing the word give can indicate that a reply
must follow. Commands can be indicated by using the imperative mood, for example
doSomeAction, calculateSum or moveHandle. Events should express that something
happened, for example temperatureExceeded.
Summary
The single message flow symbol is useful for modelling of:
a message with or without data, that does not request a reply;
events;
commands;
a message that requests a separate communication for the reply. This form enables
concurrent behaviour of sender and receiver between the rendezvous.
Guidelines for the naming of the flows can improve the clearness of the model.
The POOSL description consists of a message-send and a message-receive statement
pair.