22.1 Figure 22.26 shows a use case diagram for a modified version of our ATM system that also allows users to transfer money between accounts.
22.2 b.
22.3 d.
22.4 [Note: Answers may vary.] Figure 22.27 presents a class diagram that shows some of the composition relationships of a class Car
.
22.5 c. [Note: In a computer network, this relationship could be many-to-many.]
22.6 True.
22.7 Figure 22.28 presents an ATM class diagram including class Deposit
instead of class Withdrawal
. Note that Deposit
does not access CashDispenser
, but does access DepositSlot
.
22.8 b.
22.9 c. Fly is an operation or behavior of an airplane, not an attribute.
22.10 This indicates that count
is an Integer
with an initial value of 500
. This attribute keeps track of the number of bills available in the CashDispenser
at any given time.
22.11 False. State diagrams model some of the behavior of a system.
22.12 a.
22.13 Figure 22.29’s activity diagram models the actions that occur after the user chooses the deposit option from the main menu and before the ATM returns the user to the main menu. Recall that part of receiving a deposit amount from the user involves converting an integer number of cents to a dollar amount. Also recall that crediting a deposit amount to an account involves increasing only the totalBalance
attribute of the user’s Account
object. The bank updates the availableBalance
attribute of the user’s Account
object only after confirming the amount of cash in the deposit envelope and after the enclosed checks clear—this occurs independently of the ATM system.
22.14 c.
22.15 To specify an operation that retrieves the amount
attribute of class Withdrawal
, the following operation would be placed in the operation (i.e., third) compartment of class Withdrawal
:
getAmount( ) : Double
22.16 This is an operation named add
that takes integers x
and y
as parameters and returns an integer value.
22.17 c.
22.18 Communication diagrams emphasize what collaborations occur. Sequence diagrams emphasize when collaborations occur.
22.19 Figure 22.30 presents a sequence diagram that models the interactions between objects that occur when a Deposit
executes successfully. A Deposit
first sends a displayMessage
message to the Screen
to ask the user to enter a deposit amount. Next, it sends a getInput
message to the Keypad
to receive input from the user. Then, it instructs the user to insert a deposit envelope by sending a displayMessage
message to the Screen
. It then sends an isEnvelopeReceived
message to the DepositSlot
to confirm that the deposit envelope has been received. Finally, it increases the totalBalance
attribute (but not the availableBalance
attribute) of the user’s Account
by sending a credit
message to the BankDatabase
. The BankDatabase
responds by sending the same message to the user’s Account
.
18.188.178.181