Figure 9.11 The classes that implement the work cell subsystems
with the enumeration of all the automaton states. Then it identifies, for each
state, the enabled events and indicates, for each of them, how to implement
the transition to the next state.
The finite state automata presented in this case study have more states
than events. Thus, we follow the dual approach, i.e. we list the events that
the automaton is listening to, and for each event we determine the state
transition from the current state to the next.
How does the graphical user interface interact with the simulator?
The graphical user interface is represented by class WorkCellGUI (see
Figure 9.12), which extends class javax.swing.JFrame . It implements the
main() method and initializes the clock and the work cell simulator. Class
Workcell extends class DiscreteProcess in order to listen to all the events
raised by each subsystem. When an event is notified, the work cell invokes
method repaint() of class WorkCellGUI , which refreshes the graphical layout.
This method accesses through class WorkCell the state of the work cell
components in order to animate the simulation.
This new implementation of class PieceSource includes the definition of the
state transitions triggered by the FULL and NOTFULL events. The working
variable is set to true when the drill (or cutter) input buffer is not full.
Otherwise it is set to false . It might happen that the input buffer gets full
when a new LOADED event has already been activated. Since we do not
want to manage event deactivation, we assume that the drill and the
cutter raise the FULL event when their input buffers have still one place