Communication diagrams emphasize the participants in collaborations but model their timing a bit awkwardly. A sequence diagram helps model the timing of collaborations more clearly. Figure 22.25 shows a sequence diagram modeling the sequence of interactions that occur when a Withdrawal
executes. The dotted line extending down from an object’s rectangle is that object’s lifeline, which represents the progression of time. Actions typically occur along an object’s lifeline in chronological order from top to bottom—an action near the top typically happens before one near the bottom.
Message passing in sequence diagrams is similar to message passing in communication diagrams. A solid arrow with a filled arrowhead extending from the sending object to the receiving object represents a message between two objects. The arrowhead points to an activation on the receiving object’s lifeline. An activation, shown as a thin vertical rectangle, indicates that an object is executing. When an object returns control, a return message, represented as a dashed line with a stick arrowhead, extends from the activation of the object returning control to the activation of the object that initially sent the message. To eliminate clutter, we omit the return-message arrows—the UML allows this practice to make diagrams more readable. Like communication diagrams, sequence diagrams can indicate message parameters between the parentheses following a message name.
The sequence of messages in Fig. 22.25 begins when a Withdrawal
prompts the user to choose a withdrawal amount by sending a displayMessage
message to the Screen
. The Withdrawal
then sends a getInput
message to the Keypad
, which obtains input from the user. We’ve already modeled the control logic involved in a Withdrawal
in the activity diagram of Fig. 22.15, so we do not show this logic in the sequence diagram of Fig. 22.25. Instead, we model the best-case scenario in which the balance of the user’s account is greater than or equal to the chosen withdrawal amount, and the cash dispenser contains a sufficient amount of cash to satisfy the request. For information on how to model control logic in a sequence diagram, please refer to the web resources at the end of Section 22.3.
After obtaining a withdrawal amount, the Withdrawal
sends a getAvailableBalance
message to the BankDatabase
, which in turn sends a getAvailableBalance
message to the user’s Account
. Assuming that the user’s account has enough money available to permit the transaction, the Withdrawal
next sends an isSufficientCashAvailable
message to the CashDispenser
. Assuming that there is enough cash available, the Withdrawal
decreases the balance of the user’s account (i.e., both the totalBalance
and the availableBalance
) by sending a debit
message to the BankDatabase
. The BankDatabase
responds by sending a debit
message to the user’s Account
. Finally, the Withdrawal
sends a dispenseCash
message to the CashDispenser
and a displayMessage
message to the Screen
, telling the user to remove the cash from the machine.
We’ve identified the collaborations among the ATM system’s objects and modeled some of them using UML interaction diagrams—both communication diagrams and sequence diagrams. In Section 23.2, we enhance the structure of our model to complete a preliminary object-oriented design, then we implement the ATM system in C++.