Java Reference
In-Depth Information
SEM.GREEN
IN_PhC.occupy()
goTo()
IN_PhC.clear()
PROCEEDING
PHASE 1
PHASE 2
SB.UP
OUT_PhC.occupy()
goTo()
OUT_PhC.clear()
TD.DELIVERED
TD.withdraw()
PHASE 3
Figure 11.6
The car's finite state automaton
The car repeats a sequence of three phases indefinitely. In the first phase,
it waits for the semaphore to go green. Then it proceeds to the ticket
dispenser and, in phase 2, it waits for the ticket to be delivered. Finally, in
phase 3, the car waits for the stopping bar to be raised. When the car enters
the parking area, it starts this sequence again.
The last component to consider is the graphical user interface, which ani-
mates the physical devices and the cars. It should observe the event raised
by each component and react to them by redrawing the scene accordingly.
The layout should look like the diagram shown in Figure 11.1. The user will
watch the cars proceeding and crossing the photocell, the stopping bar
raising and lowering, and the dispenser delivering the ticket.
11.5.2
Design
The physical devices, the car and the controller extend the abstract class
EventProcess
(see Figure 11.7). Every subclass overrides method
run()
in
order to implement the finite state automata described in the previous
section. The classes representing the physical devices implement specific
methods that trigger their state transitions.
Figure 11.8 depicts the interaction diagram that shows the exchange of
messages between the subsystems. Labels in lower case correspond to
method invocations according to the caller
provider schema. Labels in
upper case correspond to event notifications according to the broadcaster
-
-
listener schema.
The graphical user interface is supported by three classes as depicted in
Figure 11.9. Class
GUIParkingArea
is a panel that represents the layout of the
access lane. Class
GUIMessages
displays events of interests raised by the
components. Class
GUIFrame
is the top class and implements the
Observer
