Chapter 12 Graphical User Interface Components: Part 1 (Web server iis)
Chapter 12 Graphical User Interface Components: Part 1 705 Relocate Person Elevator Person Fig. 12.29Use-case diagram from the perspective of a Person. 12.29 We must ensure that our use cases do not model interactions that are too specific between the external client and the system. For example, we do not subdivide each use case into two separate use cases such as Create Person on first Floor and Create Person on second Floor, or Relocate Person to first Floor and Relocate Person to second Floor because the functionality of such use cases is repetitive (i.e., these seemingly alternative use cases are really the same). Improper and repetitive subdivision of use cases can create problems during implementation. For example, if the designer of an automated teller machine separated its Withdraw Money use case into Withdraw Specific Amounts use cases (e.g., Withdraw $1.00, Withdraw $2.00, etc.), there could exist an enormous number of use cases for the system. This would make the implementation tedious. (Our elevator system contains only two floors separating the use case into two would not cause that much extra work; if our system contained 100 floors, however, creating 100 use cases would be unwieldy.) Constructing the Graphical User Interface Our simulation implements both the Create Person and Relocate Person use cases. We have studied the Relocate Person use case through the activity diagram of the Person in Fig. 5.29 we implement this use case and the activity diagram in Appendix H when we create class Person. We implement the Create Person use case through a graphical user interface (GUI). We implement our GUI in class ElevatorController (Fig. 12.30, line 17), which is a JPanel subclass containing two JButton objects firstControllerButton(line 21) and secondControllerButton(line 22). Each JButtoncorresponds to a Flooron which to place a Person.1 Lines 33 38 instantiate these JButtons and add them to the ElevatorController. We discuss in Section 13.17 how class ElevatorModel ties together all objects composing our elevator simulation model. Line 25 of class ElevatorController declares a reference to the ElevatorModel, because the ElevatorController allows the user to interact with the model. Lines 42 56 and 60 74 declare two anonymous ActionListener objects and register them with firstFloorController- Buttonand secondFloorControllerButton, respectively, for ActionEvents. When the user presses either JButton, lines 49 50 and 67 68 of methods actionPer 1. This approach is feasible with only two Floors. If the building had 100 Floors, we might have opted for the user to specify the desired Floorin a JTextFieldand press a JButtonto process the request. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01