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

356 SHE Framework
accept(PI)
Product_
Input_
Handler
currentPosition
(InitialPosition)
productArrived
productArrived
Transporter_
Image
move(Speed)
Transporter
schedule
(PIKeeperId,
InitialPosition)
wakeAt(Position,Id)/
wakeup(Id)
encoderPuls
free(PIKeeperId)
store(PIKeeperId,PI)
Service_
Scheduler
Product_
Info_
Keeper
feed(PIKeeperId,InitialPosition)
giveStatus/
notMounted,
mounted(Service)
wakeAt(Position,Id)/
wakeup(Id)
wakeAt(Position,Id)/
wakeup(Id)
stop,start
serviceRequired
(PIKeeperId,
Service)/
required,
notRequired
handOver(PIKeeperId,InitialPosition)
Feeding_Unit_
Image
mounted, feed
notMounted
misFed,
doubleFed
Feeding_
Unit
retrieve(PIKeeperId)/take(PI)
servicePerformed
(PIKeeperId,Service)
feedReady
(ProductInfoKeeperId,
Service)
Service_
Administrator
Images_Of_
Other_Functional_
Units
Other_Functional_
Units
Figure 11.14: Feeder Station: Scenario Assembly
parameters, defined by their data object classes;
Feeder_Station
Feeder_Controller
Product_
Output_
Handler
possible alternative replies, for which message names must be defined;
a flow type;
the direction of a flow.
accept(PI)
The direction of a flow is not always predetermined. Usually an object sends a request
to another object that can perform some service. However a server can also offer its
service by taking the explicit initiative to send messages to potential users of their
services. Figure 11.15 shows the alternative message flow types. The choice of a
flow type has in general direct consequences for the behaviour of the process object
class. Architecture decisions can be taken into account if they concern concurrency,
distribution and implementation. Various boundaries can be used to guide the selection
of flow types. Well considered annotation of boundaries on clusters in MFDs can prevent
iterations in the selection of flow types. We discuss some aspects that can determine the
selection of a message flow type.