So far, we’ve not been concerned with the parameters of our operations—we’ve attempted to gain only a basic understanding of the operations of each class. Let’s now take a closer look at some operation parameters. We identify an operation’s parameters by examining what data the operation requires to perform its assigned task.
Consider the authenticateUser
operation of class BankDatabase
. To authenticate a user, this operation must know the account number and PIN supplied by the user. Thus we specify that operation authenticateUser
takes integer parameters userAccountNumber
and userPIN
, which the operation must compare to the account number and PIN of an Account
object in the database. We prefix these parameter names with “user” to avoid confusion between the operation’s parameter names and the attribute names that belong to class Account
. We list these parameters in the class diagram in Fig. 22.18 that models only class BankDatabase
. [Note: It’s perfectly normal to model only one class in a class diagram. In this case, we are most concerned with examining the parameters of this one class in particular, so we omit the other classes. In class diagrams later in the case study, in which parameters are no longer the focus of our attention, we omit the parameters to save space. Remember, however, that the operations listed in these diagrams still have parameters.]
Recall that the UML models each parameter in an operation’s comma-separated parameter list by listing the parameter name, followed by a colon and the parameter type (in UML notation). Figure 22.18 thus specifies that operation authenticateUser
takes two parameters—userAccountNumber
and userPIN
, both of type Integer
. When we implement the system in C++, we’ll represent these parameters with int
values.
Class BankDatabase
operations getAvailableBalance
, getTotalBalance
, credit
and debit
also each require a userAccountNumber
parameter to identify the account to which the database must apply the operations, so we include these parameters in the class diagram of Fig. 22.18. In addition, operations credit
and debit
each require a Double
parameter amount
to specify the amount of money to be credited or debited, respectively.
The class diagram in Fig. 22.19 models the parameters of class Account
’s operations. Operation validatePIN
requires only a userPIN
parameter, which contains the user-specified PIN to be compared with the PIN associated with the account. Like their counterparts in class BankDatabase
, operations credit
and debit
in class Account
each require a Double
parameter amount
that indicates the amount of money involved in the operation. Operations getAvailableBalance
and getTotalBalance
in class Account
require no additional data to perform their tasks. Class Account
’s operations do not require an account number parameter—each of these operations can be invoked only on a specific Account
object, so including a parameter to specify an Account
is unnecessary.
Figure 22.20 models class Screen
with a parameter specified for operation displayMessage
. This operation requires only a String
parameter message
that indicates the text to be displayed. Recall that the parameter types listed in our class diagrams are in UML notation, so the String
type listed in Fig. 22.20 refers to the UML type. When we implement the system in C++, we’ll in fact use a C++ string
object to represent this parameter.
The class diagram in Fig. 22.21 specifies that operation dispenseCash
of class CashDispenser
takes a Double
parameter amount
to indicate the amount of cash (in dollars) to be dispensed. Operation isSufficientCashAvailable
also takes a Double
parameter amount
to indicate the amount of cash in question.
We do not discuss parameters for operation execute
of classes BalanceInquiry
, Withdrawal
and Deposit
, operation getInput
of class Keypad
and operation isEnvelopeReceived
of class DepositSlot
. At this point in our design process, we cannot determine whether these operations require additional data to perform their tasks, so we leave their parameter lists empty. As we progress through the case study, we may decide to add parameters to these operations.
In this section, we’ve determined many of the operations performed by the classes in the ATM system. We’ve identified the parameters and return types of some of the operations. As we continue our design process, the number of operations belonging to each class may vary—we might find that new operations are needed or that some current operations are unnecessary—and we might determine that some of our class operations need additional parameters and different return types.
3.144.30.62