Before we begin implementing our design in C++, we introduce an additional UML notation. The class diagram in Fig. 23.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 arrowheads in the class diagram) indicate in which direction an association can be traversed and are based on the collaborations modeled in communication and sequence diagrams (see Section 22.8). When implementing a system designed using the UML, you use navigability arrows to help determine which objects need references or pointers to other objects. For example, the navigability arrow pointing from class ATM
to class BankDatabase
indicates that we can navigate from the former to the latter, thereby enabling the ATM
to invoke the BankDatabase
’s operations. However, since Fig. 23.2 does not contain a navigability arrow pointing from class BankDatabase
to class ATM
, the BankDatabase
cannot access the ATM
’s operations. Associations in a class diagram that have navigability arrows at both ends or do not have navigability arrows at all indicate bidirectional navigability—navigation can proceed in either direction across the association.
Like the class diagram of Fig. 22.10, the class diagram of Fig. 23.2 omits classes BalanceInquiry
and Deposit
to keep the diagram simple. The navigability of the associations in which these classes participate closely parallels the navigability of class Withdrawal
’s associations. Recall from Section 22.4 that BalanceInquiry
has an association with class Screen
. We can navigate from class BalanceInquiry
to class Screen
along this association, but we cannot navigate from class Screen
to class BalanceInquiry
. Thus, if we were to model class BalanceInquiry
in Fig. 23.2, we would place a navigability arrow at class Screen
’s end of this association. Also recall that class Deposit
associates with classes Screen
, Keypad
and DepositSlot
. We can navigate from class Deposit
to each of these classes, but not vice versa. We therefore would place navigability arrows at the Screen
, Keypad
and DepositSlot
ends of these associations. [Note: We model these additional classes and associations in our final class diagram in Section 23.3, after we have simplified the structure of our system by incorporating the object-oriented concept of inheritance.]