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

11.4 Essential Specification Modelling 355
Product_
Input_
Handler
Transporter_
Image
schedule
(PIKeeperId,
InitialPosition)
Service_
Scheduler
wakeAt(Position,Id)/
wakeup(Id)
serviceRequired
(PIKeeperId,
Service)/
required,
notRequired
Product_
Info_
Keeper
feed(PIKeeperId,InitialPosition)
giveStatus/
notMounted,
mounted(Service)
Feeding_Unit_
Image
mounted, feed
notMounted
misFed,
doubleFed
Feeding_
Unit
servicePerformed
(PIKeeperId,Service)
feedReady
(ProductInfoKeeperId,
Service)
Service_
Administrator
Figure 11.13: Feeder Station: Feeding Scenario
Feeder_Station
Feeder_Controller
corresponding operations. Required operations are briefly formulated in a scenario
narrative. Usually there are alternative ways to allocate operations to objects. The
allocation of operations is directly related to the modelling of message flows that
enter and leave an object in coherence with one or more corresponding operations.
Carefully allocated operations make objects more reusable entities. They perform
what you naturally expect them to do.
Message flows are added to MFDs by playing the role of an object in our imagination.
This means reasoning about possible orders of events (incoming messages)
and required responses internally and externally in the form of outgoing messages.
This is done in the context of scenarios initially. However to be able to explore a
more complete behaviour of a class this must be done by creating scenario assemblies.
Finally we must define behaviour as a formal POOSL description for each
class. For the description of a class all instances must be considered carefully.
Adding a message to MFDs requires careful selection of
a message name, corresponding to the vocabulary of the problem domain, and
suitable for polymorphic interpretation;