In order to run the simulation indefinitely, the red car is queued again
after the blue car.
This procedure repeats until the user stops the simulation.
Tables 11.1 and 11.2 report component interactions according to the
listener communication mechanisms.
It is interesting to note that the car plays both the role of broadcaster and
listener. In fact, an object of class Car broadcasts event PROCEEDING when it
enters the access lane. Objects representing cars waiting in the queue listen
to this event to know when they can proceed. This mechanisms simulates
the visual interactions between the car driver and the car in front of him or
provider and broadcaster
In the previous two case studies we discussed two examples of dynamic
systems. For the work cell system we chose a centralized event-based archi-
tecture. For the mobile robot system we chose a decentralized process-based
architecture. The access control system shows characteristics common to
the previous two case studies.
Which execution model supports the caller
provider interaction pattern?
To animate the dynamics of the car and the physical devices requires the
implementation of the system components as independent threads of
execution. The physical devices notify the car and the controller that a state
transition has occurred by raising events. Thus, we choose to implement
every system component as an event-based process.
We introduce the abstract class EventProcess to implement the con-
currency and synchronization mechanisms that are common to all the
system components. Class EventProcess inherits from the Runnable interface
(see Sidebar 10.1, p. 255) but leaves the implementation of the run() method
Table 11.1 The list of stimuli exchanged between callers and providers