Chapter 12 Graphical (Web server extensions) User Interface Components: Part 1
Sunday, February 24th, 2008Chapter 12 Graphical User Interface Components: Part 1 703 After JPanel buttonPanel is created at line 27, lines 28 29 set button- Panel s layout to a GridLayout of one row and five columns (there are five JButtons in array buttons). The five JButtons in array buttons are added to the JPanelin the loop with line 35. Notice that the buttons are added directly to the JPanel class JPanel does not have a content pane like an applet or a JFrame. Line 38 uses the content pane s default BorderLayout to add buttonPanel to the SOUTH region. Note that the SOUTH region is as tall as the buttons on buttonPanel. A JPanel is sized to the components it contains. As more components are added, the JPanel grows (according to the restrictions of its layout manager) to accommodate the components. Resize the window to see how the layout manager affects the size of the JButtons. 12.16 (Optional Case Study) Thinking About Objects: Use Cases The previous eight Thinking About Objects sections have concentrated on the elevator- simulation model. We have identified and honed the structure and behavior of our system. In this section, we model the interaction between the user and our elevator simulation through the UML use-case diagram, which describes the sets of scenarios that occur between the user and the system. Use-Case Diagrams When developers begin a project, they rarely start with as detailed a problem statement as the one we provided in Section 2.9. This document and others are the result of the object- oriented analysis (OOA) phase. In this phase you meet with the people who want you to build a system and with the people who will eventually use that system. You use the information gained in these meetings to compile a list of system requirements. These requirements guide you and your fellow developers as you design the system. In our case study, the problem statement described the requirements of our elevator simulation in sufficient detail that you did not need to go through an analysis phase. The analysis phase is enormously important you should consult the references we provide in Section 2.9 to learn more about object-oriented analysis. The UML provides the use-case diagram to facilitate requirements gathering. This diagram models the interactions between the system s external clients and the use cases of the system. Each use case represents a different capability that the system provides to clients. For example, automated teller machines typically have several use cases, including Deposit Money, Withdraw Money and Transfer Funds. In larger systems, use-case diagrams are indispensable tools that help system designers remain focused on satisfying the users needs. The goal of the use-case diagram is to show the kinds of interactions users have with a system without providing the details of those interactions: those details are, of course, provided in other UML diagrams. Figure 12.28 shows the use-case diagram for our elevator simulation. The stick figure represents an actor, which, in turn, represents a set of roles that an external entity such as a person or another system can play. Consider again our automated teller machine example. The actor is a BankCustomer who can deposit, withdraw and transfer funds from the ATM. In this sense, BankCustomeris more like a class rather than an object it is not an actual person, but rather describes the roles that a real person when playing the part of a BankCustomer can perform while interacting with the ATM (deposit, with Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01