Java How to Program, 8/e

(C) 2010 Pearson Education, Inc. All rights reserved.

(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Section 13.2 shows how to convert class diagrams to
Java code.
 Section 13.3 tunes the design with inheritance and
polymorphism.
 Section 13.4 presents a full Java code implementation
of the ATM software.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Visibility
 Access modifiers determine the visibility or
accessibility of an object’s attributes and methods to
other objects.
◦ Before we can begin implementing our design, we must
consider which attributes and methods of our classes should be
public and which should be private.
◦ Attributes normally should be private and that methods
invoked by clients of a given class should be public.
◦ Methods that are called as “utility methods” only by other
methods of the class normally should be private.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 The UML employs visibility markers for modeling the
visibility of attributes and operations.
◦ Public visibility is indicated by placing a plus sign (+) before
an operation or an attribute, whereas a minus sign (–) indicates
private visibility.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Navigability
 The class diagram in Fig. 13.2 further refines the
relationships among classes in the ATM system by adding
navigability arrows to the association lines.
 Navigability arrows
◦ represented as arrows with stick () arrowhead in the class diagram
◦ indicate in the direction which an association can be traversed.
 Programmers use navigability arrows to determine which
objects need references to other objects.
 Associations that have navigability arrows at both ends or
have none at all indicate bidirectional navigability—
navigation can proceed in either direction across the
association.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Implementing the ATM System from Its
UML Design
 We are now ready to begin implementing the ATM
system.
 Convert the classes in the diagrams of Fig. 13.1 and
Fig. 13.2 into Java code.
 The code will represent the “skeleton” of the system.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Four guidelines for each class:
◦ 1.Use the name located in the first compartment to declare the class
as a public class with an empty no-argument constructor
(Fig. 13.3).
◦ 2.Use the attributes located in the second compartment to declare
the instance variables (Fig. 13.4).
◦ 3.Use the associations described in the class diagram to declare the
references to other objects (Fig. 13.5).
◦ 4.Use the operations located in the third compartment of Fig. 13.1
to declare the shells of the methods (Fig. 13.6). If we have not yet
specified a return type for an operation, we declare the method with
return type void. Refer to the class diagrams of Figs. 12.17–12.21
to declare any necessary parameters.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 To apply inheritance, look for commonality among
classes in the system.
 Create an inheritance hierarchy to model similar (yet
not identical) classes in a more elegant and efficient
manner.
 Modify class diagram to incorporate the new
inheritance relationships.
 Translate updated design into Java code.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Problem of representing a financial transaction in the system.
 Created three individual transaction classes—
BalanceInquiry, Withdrawal and Deposit—to
represent the transactions that the ATM system can perform.
 Figure 13.7 shows the attributes and operations of classes
BalanceInquiry, Withdrawal- and Deposit.
◦ Each has one attribute (accountNumber) and one operation
(execute) in common.
◦ Each class requires attribute accountNumber to specify the account
to which the transaction applies.
◦ Each class contains operation execute, which the ATM invokes to
perform the transaction.
 BalanceInquiry, Withdrawal- and Deposit represent
types of transactions.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Figure 13.7 reveals commonality among the transaction
classes.
 Use inheritance to factor out the common features.
 Place the common functionality in a superclass,
Transaction, that classes BalanceInquiry,
Withdrawal- and Deposit extend.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 The UML specifies a relationship called a generalization to
model inheritance.
 Figure 13.8 is the class diagram that models the
generalization of superclass Transaction and subclasses
BalanceInquiry, Withdrawal and Deposit.
 Arrows with triangular hollow arrowheads indicate that
classes BalanceInquiry, Withdrawal and
Deposit extend class Transaction.
 Class Transaction is said to be a generalization of
classes BalanceInquiry, Withdrawal and
Deposit.
 Class BalanceInquiry, Withdrawal and Deposit
are said to be specializations of class Transaction.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Polymorphism provides the ATM with an elegant way
to execute all transactions “in the general.”
 The polymorphic approach also makes the system
easily extensible.
 To create a new transaction type, just create an
additional Transaction subclass that overrides the
execute method with a version of the method
appropriate for executing the new transaction type.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Figure 13.9 presents an updated class diagram of our model that
incorporates inheritance and introduces class Transaction.
 We model an association between class ATM and class
Transaction to show that the ATM, at any given moment,
either is executing a transaction or is not (i.e., zero or one objects
of type Transaction exist in the system at a time).
 Because a Withdrawal is a type of Transaction, we no
longer draw an association line directly between class ATM and
class Withdrawal.
 Subclass Withdrawal inherits superclass Transaction’s
association with class ATM.
 Subclasses BalanceInquiry and Deposit inherit this
association, too, so the previously omitted associations between
ATM and classes BalanceInquiry and Deposit no longer
exist either.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 We also add an association between class
Transaction and the BankDatabase (Fig. 13.9).
◦ All Transactions require a reference to the
BankDatabase so they can access and modify account
information.
 We show an association between class Transaction
and the Screen.
◦ All Transactions display output to the user via the
Screen.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Fig. 13.10 presents a modified class diagram that
incorporates inheritance.
◦ This abbreviated diagram does not show inheritance relationships,
but instead shows the attributes and methods after we’ve employed
inheritance in our system.
 To save space, as we did in Fig. 12.12, we do not include
those attributes shown by associations in Fig. 13.9—we do,
however, include them in the Java implementation in
Section 13.4.
 We also omit all operation parameters, as we did in
Fig. 13.1—incorporating inheritance does not affect the
parameters already modeled in Figs. 12.17–12.21.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Figure 13.11 shows the declaration of class
Withdrawal.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Figure 13.12 is the Java code for class Withdrawal
from Fig. 13.9 and Fig. 13.10.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Complete working 673-line implementation of the ATM
system.
 Consider the classes in the order in which we identified
them in Section 12.3—ATM, Screen, Keypad,
CashDispenser, Deposit-Slot, Account,
BankDatabase, Transaction, BalanceInquiry,
Withdrawal and Deposit.
 Apply the guidelines discussed in Sections 13.2–13.3 to
code these classes based on how we modeled them in the
UML class diagrams of Figs. 13.9 and 13.10.
 To develop the bodies of class methods, we refer to the
activity diagrams in Section 12.5 and the communication
and sequence diagrams presented in Section 12.7.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Our ATM design does not specify all the program logic
and may not specify all the attributes and operations
required to complete the ATM implementation.
◦ This is a normal part of the object-oriented design process.
 As we implement the system, we complete the program
logic and add attributes and behaviors as necessary to
construct the ATM system specified by the
requirements document in Section 12.2.
 The Java application (ATMCaseStudy) starts the
ATM and puts the other classes in the system in use.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Class ATM (Fig. 13.13) represents the ATM as a whole.
 Line 7 declares an attribute not found in our UML
design—an int attribute
currentAccountNumber that keeps track of the
account number of the current authenticated user.
 Lines 8–12 declare reference-type attributes
corresponding to the ATM class’s associations modeled
in Fig. 13.9.
◦ These attributes allow the ATM to access its parts (i.e., its
Screen, Keypad, CashDispenser and DepositSlot)
and interact with the bank’s account-information database (i.e.,
a BankDatabase object).

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 The class diagram of Fig. 13.10 does not list any operations
for class ATM.
 We implement one operation in class ATM that allows an
external client of the class (i.e., class ATMCaseStudy) to
tell the ATM to run.
 ATM method run (lines 33–50) uses an infinite loop (lines
36–49) to repeatedly welcome a user, attempt to
authenticate the user and, if authentication succeeds, allow
the user to perform transactions.
◦ Simulates the fact that an ATM appears to run continuously until the
bank turns it off (an action beyond the user’s control).
◦ An ATM user has the option to exit the system but not the ability to
turn off the ATM completely.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Lines 39–43 cause the ATM to repeatedly welcome and
attempt to authenticate the user as long as the user has
not been authenticated (i.e., !userAuthenticated
is true).
 We refer to the requirements document to determine the
steps necessary to authenticate the user before allowing
transactions to occur.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Method performTransactions (lines 75–112)
carries out an ATM session for an authenticated user.
 We use a Transaction variable here to allow us to
take advantage of polymorphism.
◦ We name this variable after the role name included in the class
diagram of Fig. 12.7—currentTransaction.
 Method createTransaction (lines 127–149) uses
a switch statement (lines 132–146) to instantiate a
new Transaction subclass object of the type
indicated by the parameter type.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 However, if a user does not perform a transaction and
instead selects the main menu option to exit, line 104
sets userExited to true, causing the condition of
the while loop (!userExited) to become false.
 If the user enters an invalid main menu selection (i.e.,
not an integer from 1–4), lines 107–108 display an
appropriate error message, userExited remains
false and the user returns to the main menu to try
again.

(C) 2010 Pearson Education, Inc. All

rights reserved.
 Class Screen (Fig. 13.14) represents the screen of the
ATM and encapsulates all aspects of displaying output
to the user.
 We designed class Screen to have one operation—
displayMessage.
◦ For greater flexibility in displaying messages to the Screen,
we now declare three Screen methods—
displayMessage, displayMessageLine and
displayDollar-Amount.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class Keypad (Fig. 13.15) represents the keypad of
the ATM and is responsible for receiving all user input.
 We assume that the user presses only the keys on the
computer keyboard that also appear on the keypad—the
keys numbered 0–9 and the Enter key.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class CashDispenser (Fig. 13.16) represents the cash
dispenser of the ATM.
 Constant INITIAL_COUNT indicates the initial count of
bills in the cash dispenser when the ATM starts (i.e., 500).
 The class trusts that a client (i.e., Withdrawal) calls
dispenseCash only after establishing that sufficient
cash is available by calling
isSufficientCashAvailable.
 Thus, dispenseCash simply simulates dispensing the
requested amount without checking whether sufficient cash
is available.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class DepositSlot (Fig. 13.17) represents the
ATM’s deposit slot.
 DepositSlot has no attributes and only one
method—isEnvelopeReceived (lines 8–11)—
which indicates whether a deposit envelope was
received.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class Account (Fig. 13.18) represents a bank
account.
 Each Account has four attributes (modeled in
Fig. 13.10)—accountNumber, pin,
availableBalance and totalBalance.
 Variable availableBalance represents the amount
of funds available for withdrawal.
 Variable totalBalance represents the amount of
funds available, plus the amount of deposited funds still
pending confirmation or clearance.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class BankDatabase (Fig. 13.19) models the bank’s
database with which the ATM interacts to access and
modify a user’s account information.
 We determine one reference-type attribute for class
BankDatabase based on its composition relationship
with class Account.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class Transaction (Fig. 13.20) is an abstract
superclass that represents the notion of an ATM
transaction.
 It contains the common features of subclasses
BalanceInquiry, Withdrawal and Deposit.
 The class has three public get methods—
getAccountNumber (lines 20–23), get-Screen
(lines 26–29) and getBankDatabase (lines 32–35).
◦ These are inherited by Transaction subclasses and used to
gain access to class Transaction’s private attributes.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class BalanceInquiry (Fig. 13.21) extends
Transaction and represents a balance-inquiry ATM
transaction.
 BalanceInquiry does not have any attributes of its
own, but it inherits Transaction attributes
accountNumber, screen and bankDatabase,
which are accessible through Transaction’s
public get methods.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class Withdrawal (Fig. 13.22) extends
Transaction and represents a withdrawal ATM
transaction.
 Figure 13.9 models associations between class
Withdrawal and classes Keypad and
CashDispenser, for which lines 7–8 implement
reference-type attributes keypad and
cashDispenser, respectively.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class Deposit (Fig. 13.23) extends Transaction
and represents a deposit transaction.
 Lines 7–8 create reference-type attributes keypad and
depositSlot that implement the associations
between class Deposit and classes Keypad and
DepositSlot modeled in Fig. 13.9.
 Line 9 declares a constant CANCELED that corresponds
to the value a user enters to cancel.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.
 Class ATMCaseStudy (Fig. 13.24) is a simple class
that allows us to start, or “turn on,” the ATM and test
the implementation of our ATM system model.

(C) 2010 Pearson Education, Inc. All

rights reserved.
(C) 2010 Pearson Education, Inc. All
rights reserved.