Java How to Program Fourth Edition - DCC

Chapter 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 JPanel in
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 elevatorsimulation
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 objectoriented
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, BankCustomer is 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