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

12.3 The Essential Specification 393
Within the productInfoStored state, a keeper is able to perform three alternative behaviours
(see also Figure 12.6):
First it can be asked whether a certain Service is required or not. If this service is
actually needed, the keeper should reply with a required message and the appropriate
RequiredService stored in the PI should be marked ’pending’. This latter is done
by sending the message markPending(Service) to the product info (see also Figure
12.9). If the service is not required, the keeper should answer with the notRequired
message. After the required or notRequired messages have been sent, the keeper
remains in the productInfoStored state.
Second it can receive the servicePerformed message. In this case the product info
should be sent the markPerformed message (see also Figure 12.9) and the keeper
should return to the productInfoStored state.
Third it can receive the retrieve message. Then the keeper should deliver its product
info by sending the take message, and consequently make a transition to the
noProductInfoStored state 18 .
The productInfoStored method is now straightforwardly specified:
productInfoStored id:PIKeeperId service:Service
(prks?serviceRequired(id,service id=myId);
if productInfo requires(service)
then productInfo markPending(service);
prks!required
else prks!notRequired
fi;
productInfoStored
)
or
(pisa?servicePerformed(id,service id=myId);
productInfo markPerformed(service);
productInfoStored
)
or
(pipo?retrieve(id id=myId);
pipo!take(productInfo);
noProductInfoStored
)
The last process class we will specify in this chapter is Transporter Image class. The first
part of the specification of process class Transporter Image is defined by:
18 One could also decide to first check the absence of any pending services. In case one or more pending
services were still available, one could decide to generate an error. This behaviour should be analysed
within an error handling scenario.