Mysql, Java, Jsp, Servlet, Tomcat, Ssh, Shared Web Hosting Blog

710 Graphical User Interface Components: Part 1 Chapter 12 The original GUI components from the Abstract Windowing Toolkit package java.awt are tied directly to the local platform s graphical user interface capabilities. Swing components are lightweight components. AWT components are tied to the local platform and are called heavyweight components they must rely on the local platform s windowing system to determine their functionality and their look and feel. Several Swing GUI components are heavyweight GUI components: in particular, subclasses of java.awt.Window (such as JFrame) that display windows on the screen. Heavyweight Swing GUI components are less flexible than lightweight components. Much of each Swing GUI component s functionality is inherited from classes Component, Containerand JComponent(the superclass to most Swing components). A Container is an area where components can be placed. JLabels provide text instructions or information on a GUI. JComponent method setToolTipText specifies the tool tip that is displayed automatically when the user positions the mouse cursor over a JComponent in the GUI. Many Swing components can display images by specifying an Icon as an argument to their constructor or by using a method setIcon. Class ImageIcon (package javax.swing) supports several image formats, including Portable Network Graphics (PNG), Graphics Interchange Format (GIF) and Joint Photographic Experts Group (JPEG). Interface SwingConstants (package javax.swing) defines a set of common integer constants (such as SwingConstants.LEFT) that are used with many Swing components. By default, the text of a JComponent appears to the right of the image when the JComponent contains both text and an image. The horizontal and vertical alignments of a JLabel can be set with methods setHorizontal- Alignmentand setVerticalAlignment. Method setTextsets the text displayed on the label. Method getText retrieves the current text displayed on a label. Methods setHorizontalTextPositionand setVerticalTextPositionspecify the text position in a label. JComponent method setIcon sets the Icon displayed on a JComponent. Method get- Icon retrieves the current Icon displayed on a JComponent. GUIs generate events when the user interacts with the GUI. Information about a GUI event is stored in an object of a class that extends AWTEvent. To process an event, the programmer must register an event listener and implement one or more event handlers. The use of event listeners in event handling is known as the delegation event model the processing of an event is delegated to a particular object in the program. When an event occurs, the GUI component with which the user interacted notifies its registered listeners by calling each listener s appropriate event handling method. JTextFieldsand JPasswordFields are single-line areas in which text can be entered by the user from the keyboard or text can simply be displayed. A JPasswordField shows that a character was typed as the user enters characters, but automatically hides the characters. When the user types data into a JTextFieldor JPasswordField and presses the Enter key, an ActionEvent occurs. JTextComponent method setEditabledetermines whether the user can modify the text in a JTextComponent. JPasswordField method getPasswordreturns the password as an array of type char. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 12 Graphical User Interface Components: Part 1 709 Location - locationName : String # setLocationName( String ) : void + getLocationName( ) : String + getButton( ) : Button + getDoor( ) : Door Floor + getButton( ) : Button + getDoor( ) : Door Elevator - moving : Boolean = false -summoned : Boolean = false -currentFloor : Location -destinationFloor : Location - travelTime : Integer = 5 + ride( ) : void + requestElevator( ) : void + enterElevator( ) : void + exitElevator( ) : void + departElevator( ) : void + getButton( ) : Button + getDoor( ) : Door Fig. 12.32Modified class diagram showing generalization of superclass 12.32 Locationand subclasses Elevatorand Floor. In this section we mentioned that the goal of object-oriented ananlysis is to produce a system-requirements document. We introduced the UML use-case diagram that facilitates gathering system requirements, and we examined the two use cases in our elevator simulation. We implemented our simulator s Graphical User Interface in Java. This section concludes the discussion on the interaction between the user and the simulation model. In Thinking About Objects Section 13.17, we integrate class ElevatorControllerwith the rest of the simulation. We also introduce the UML Component diagram, which models the .class, .java, image and sound files that comprise our system. SUMMARY A graphical user interface (GUI) presents a pictorial interface to a program. A GUI (pronounced GOO-EE ) gives a program a distinctive look and feel. By providing different applications with a consistent set of intuitive user interface components, GUIs allow the user to spend more time using the program in a productive manner. GUIs are built from GUI components (sometimes called controls or widgets). A GUI component is a visual object with which the user interacts via the mouse or the keyboard. Swing GUI components are defined in package javax.swing. Swing components are written, manipulated and displayed completely in Java. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

708 Graphical User Interface Components: Part 1 Chapter 12 98 99 // other methods implementing PersonMoveListener 100 public void personCreated( 101 PersonMoveEvent event ) {} 102 103 public void personArrived( 104 PersonMoveEvent event ) {} 105 106 public void personExited( 107 PersonMoveEvent event ) {} 108 109 public void personDeparted( 110 PersonMoveEvent event ) {} 111 112 public void personPressedButton( 113 PersonMoveEvent event ) {} 114 115 } // end anonymous inner class 116 ); 117 } // end ElevatorController constructor 118 } Fig. 12.30 Class ElevatorControllerprocesses user input (part 3 of 3). Lines 53 and 71 of methods actionPerformeddisable the respective JButtons to prevent the user from creating more than one Personper Floor. Lines 78 116 of class ElevatorController declare an anonymous PersonMoveListener that registers with the ElevatorModel to reenable the JButtons. Method personEntered (lines 82 97) of the PersonMoveListener reenables the JButton associated with the Floor that the Elevator services after the Personhas entered the Elevator, the user may place another Personon the Floor. We mentioned in Section 9.23 that classes Elevatorand Floorinherited attribute capacity from superclass Location in Appendix H, we were going to use this attribute to prevent more than one Person from occupying a Location. However, the PersonMoveListener s method personEntered in class ElevatorControllerprevents the user from creating more than one Personper Floor. Therefore, we have negated the need for attribute capacityin class Location. Figure 12.32 is the modified class diagram of Fig. 9.18 removing this attribute. 1 // ElevatorConstants.java 2 // Constants used between ElevatorModel and ElevatorView 3 package com.deitel.jhtp4.elevator; 4 5 public interface ElevatorConstants { 6 7 public static final String FIRST_FLOOR_NAME = “firstFloor”; 8 public static final String SECOND_FLOOR_NAME = “secondFloor”; 9 public static final String ELEVATOR_NAME = “elevator”; 10 } Fig. 12.31 Interface ElevatorConstantsprovides Locationname constants. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 12 Graphical User Interface Components: Part 1 707 45 // invoked when a JButton has been pressed 46 public void actionPerformed( ActionEvent event ) 47 { 48 // place Person on first Floor 49 elevatorModel.placePersonOnFloor( 50 FIRST_FLOOR_NAME ); 51 52 // disable user input 53 firstControllerButton.setEnabled( false ); 54 } 55 } // end anonymous inner class 56 ); 57 58 // anonymous inner class registers to receive ActionEvents 59 // from second Controller JButton 60 secondControllerButton.addActionListener( 61 new ActionListener() { 62 63 // invoked when a JButton has been pressed 64 public void actionPerformed( ActionEvent event ) 65 { 66 // place Person on second Floor 67 elevatorModel.placePersonOnFloor( 68 SECOND_FLOOR_NAME ); 69 70 // disable user input 71 secondControllerButton.setEnabled( false ); 72 } 73 } // end anonymous inner class 74 ); 75 76 // anonymous inner class enables user input on Floor if 77 // Person enters Elevator on that Floor 78 elevatorModel.addPersonMoveListener( 79 new PersonMoveListener() { 80 81 // invoked when Person has entered Elevator 82 public void personEntered( 83 PersonMoveEvent event ) 84 { 85 // get Floor of departure 86 String location = 87 event.getLocation().getLocationName(); 88 89 // enable first JButton if first Floor departure 90 if ( location.equals( FIRST_FLOOR_NAME ) ) 91 firstControllerButton.setEnabled( true ); 92 93 // enable second JButton if second Floor 94 else 95 secondControllerButton.setEnabled( true ); 96 97 } // end method personEntered Fig. 12.30 Class ElevatorControllerprocesses user input (part 2 of 3). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

706 Graphical User Interface Components: Part 1 Chapter 12 formed call the ElevatorModel s method placePersonOnFloor, which instantiates a Person object in the ElevatorModel on the specified Floor. Method placePersonOnFloor takes as an argument a String defined in interface ElevatorConstants(Fig. 12.31). This interface used by such classes as ElevatorController, ElevatorModel, Elevator, Floor and ElevatorView provides constants that specify the names of Locations in our simulation. 1 // ElevatorController.java 2 // Controller for Elevator Simulation 3 package com.deitel.jhtp4.elevator.controller; 4 5 // Java core packages 6 import java.awt.*; 7 import java.awt.event.*; 8 9 // Java extension packages 10 import javax.swing.*; 11 12 // Deitel packages 13 import com.deitel.jhtp4.elevator.model.*; 14 import com.deitel.jhtp4.elevator.event.*; 15 import com.deitel.jhtp4.elevator.ElevatorConstants; 16 17 public class ElevatorController extends JPanel 18 implements ElevatorConstants { 19 20 // controller contains two JButtons 21 private JButton firstControllerButton; 22 private JButton secondControllerButton; 23 24 // reference to model 25 private ElevatorModel elevatorModel; 26 27 public ElevatorController( ElevatorModel model ) 28 { 29 elevatorModel = model; 30 setBackground( Color.white ); 31 32 // add first button to controller 33 firstControllerButton = new JButton( “First Floor” ); 34 add( firstControllerButton ); 35 36 // add second button to controller 37 secondControllerButton = new JButton( “Second Floor” ); 38 add( secondControllerButton ); 39 40 // anonymous inner class registers to receive ActionEvents 41 // from first Controller JButton 42 firstControllerButton.addActionListener( 43 new ActionListener() { 44 Fig. 12.30 Class ElevatorControllerprocesses user input (part 1 of 3). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

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

704 Graphical User Interface Components: Part 1 Chapter 12 draw and transfer funds). A person is an external entity that can play the part of a Bank- Customer. In the same manner as an object is an instance of a class, a person playing the part of a BankCustomer performing one of its roles (such as making a deposit) is an instance of actor BankCustomer. For example, when a person named Mary plays the part of a BankCustomermaking a deposit, Mary in the role of the depositor becomes an instance of actor BankCustomer. Later in that day, another person named Jon can be another instance of actor BankCustomer. In the course of a day, several hundred people might use the ATM machine some are depositors , some are withdrawers and some are transferrers, but all of these people are instances of actor BankCustomer. The problem statement in our elevator simulation supplies the actors The user requires the ability to create a person in the simulation and situate that person on a given floor. Therefore, the actor of our system is the user who controls the simulation (i.e., the user who clicks the buttons to create new Persons in the simulation). An external entity a real person plays the part of the user to control the simulation. In our system, the use case is Create Person, which encompasses creating a Person object, then placing that Personon either the first or second Floor. Figure 12.28 models one actor called User. The actor s name appears underneath the actor. The system box (i.e., the enclosing rectangle in the figure) contains the use cases for the system. Notice that the box is labeled Elevator Simulation. This title shows that this use-case model focuses on the one use case that our simulation provides to users (i.e., Create Person ). The UML models each use case as an oval. The system box for a system with multiple use cases would have one oval per use case. There is a reasonable alternate view of the use case of our elevator simulation. The problem statement from Section 2.9 mentioned that the company requested the elevator simulation to determine whether the elevator will meet the company s needs. We are designing a simulation of a real-world scenario the Personobject in the simulation represents an actual human being using an actual elevator. Thus, we may view the user of the elevator simulation as the user of the elevator. Therefore, specifying a use case from the Person object s perspective helps model how a real person uses a real elevator system. We offer the use case of Fig. 12.29, titled Relocate Person. This use case describes the Person moving (relocating) to the other Floor. (The Person travels to the second Floor if starting on the first Floor and to the first Floor if starting on the second Floor.) This use case encompasses all actions that the Personperforms along his or her journey, such as walking across a Floorto the Elevator, pressing Buttons and riding the Elevatorto the other Floor. Create Person Elevator Simulation User Fig. 12.28Use-case diagram for elevator simulation from user s perspective. 12.28 Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

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 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

702 Graphical User Interface Components: Part 1 Chapter 12 13 private JButton buttons[]; 14 15 // set up GUI 16 public PanelDemo() 17 { 18 super( “Panel Demo” ); 19 20 // get content pane 21 Container container = getContentPane(); 22 23 // create buttons array 24 buttons = new JButton[ 5 ]; 25 26 // set up panel and set its layout 27 buttonPanel = new JPanel(); 28 buttonPanel.setLayout( 29 new GridLayout( 1, buttons.length ) ); 30 31 // create and add buttons 32 for ( int count = 0; count < buttons.length; count++ ) { 33 buttons[ count ] = 34 new JButton( “Button ” + ( count + 1 ) ); 35 buttonPanel.add( buttons[ count ] ); 36 } 37 38 container.add( buttonPanel, BorderLayout.SOUTH ); 39 40 setSize( 425, 150 ); 41 setVisible( true ); 42 } 43 44 // execute application 45 public static void main( String args[] ) 46 { 47 PanelDemo application = new PanelDemo(); 48 49 application.setDefaultCloseOperation( 50 JFrame.EXIT_ON_CLOSE ); 51 } 52 53 } // end class PanelDemo Fig. 12.27 A JPanel with five JButtons in a GridLayoutattached to the SOUTHregion of a BorderLayout(part 2 of 2). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 12 Graphical User Interface Components: Part 1 701 Fig. 12.26 Program that demonstrates components in GridLayout. Lines 27 28 in the constructor define two GridLayoutobjects. The GridLayout constructor used at line 27 specifies a GridLayoutwith 2rows, 3columns, 5 pixels of horizontal-gap space between Components in the grid and 5pixels of vertical-gap space between Components in the grid. The GridLayoutconstructor used at line 28 specifies a GridLayoutwith 3rows, 2 columns and no gap space. The JButtonobjects in this example initially are arranged using grid1(set for the content pane at line 32 with method setLayout). The first component is added to the first column of the first row. The next component is added to the second column of the first row, and so on. When a JButton is pressed, method actionPerformed (lines 48 57) is called. Every call to actionPerformedtoggles the layout between grid2and grid1. Line 56 illustrates another way to relayout a container for which the layout has changed. Container method validate recomputes the container s layout based on the current layout manager for the Containerand the current set of displayed GUI components. 12.15 Panels Complex GUIs (like Fig. 12.1) require that each component be placed in an exact location. They often consist of multiple panels with each panel s components arranged in a specific layout. Panels are created with class JPanel a subclass of JComponent. Class JComponent inherits from class java.awt.Container, so every JPanel is a Container. Thus JPanels may have components, including other panels, added to them. The program of Fig. 12.27 demonstrates how a JPanelcan be used to create a more complex layout for Components. 1 // Fig. 12.27: PanelDemo.java 2 // Using a JPanel to help lay out components. 3 4 // Java core packages 5 import java.awt.*; 6 import java.awt.event.*; 7 8 // Java extension packages 9 import javax.swing.*; 10 11 public class PanelDemo extends JFrame { 12 private JPanel buttonPanel; Fig. 12.27 A JPanel with five JButtons in a GridLayoutattached to the SOUTHregion of a BorderLayout(part 1 of 2). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01