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

354 SHE Framework
accept(PI)
Product_
Input_
Handler
productArrived
Transporter_
Image
schedule
(PIKeeperId,
InitialPosition)
wakeAt(Position,Id)/
wakeup(Id)
currentPosition
(InitialPosition)
productArrived
move(Speed)
Transporter
encoderPuls
free(PIKeeperI)
store(PIKeeperId,PI)
Service_
Scheduler
wakeAt(Position,Id)/
wakeup(Id)
Product_
Info_
Keeper
handOver(PIKeeperId,InitialPosition)
stop,start
retrieve(PIKeeperId)/take(PI)
Figure 11.12: Feeder Station: Product Flow Scenario
Feeder_Station
Feeder_Controller
Product_
Output_
Handler
accept(PI)
The reason that the design of MFDs is a key issue in SHE is because the design of
message flows concerns all four activities simultaneously. We describe some aspects of
the relation between message flow design and each of the four key activities.
Frequently a message flow arises from the need to have a partner to perform a
particular operation. This can lead to the need to define a new process object class.
Message flows are denoted with their name and with parameters that are data
object classes. Therefore many data object classes emerge from the definition of
flows.
Messages activate various kinds of operations such as accessors and transformers.
They access or transform attributes. So the sorts of properties of objects, modelled
as attributes, are affected by the definition of messages. Modelling MFDs simultaneously
with Object Class Diagrams is recommended to produce well-balanced
objects that adequately represent their (real-world) counterparts.
The definition of a new message extends the behaviour of both the classes of
the sender and the receiver. The definition of a message requires reflection about