Example -- ATM (2)

Actually, the ATM example is an interesting example for comparing the various approaches, since it is used by many authors to illustrate their methods. In  [WWW90] the example is used for spelling out all the steps that must be taken. In  [Rum91] it is also extensively described to illustrate the various modeling techniques employed by the method. Also, in  [BC89] the CRC cards method is illustrated by sketching the design of an automated teller machine. The approaches presented in  [BC89] and  [WWW90] are actually very closely related. Both may be characterized as responsibility-driven, in that they concentrate on responsibilities and collaboration relations to model the interaction between objects. However, the method described in  [WWW90] is much more detailed, and to some extent includes means to formally characterize the behavior of an object and its interaction with other objects. To this end it employs an informal notion of contracts as originally introduced by  [Meyer88]. In section ATM-1 a number of candidate classes have been suggested for our ATM. Now, with the use of CRC cards, we will delineate the functionality of (a number of) these classes more precisely. Also we will establish how the various object classes must collaborate to perform their duties. At the highest level of the design, we may distinguish between two groups of classes: the classes representing the banking model (comprising the class account and the class transaction), and the classes that model the interaction with the user (comprising the class card-reader and the class cash-dispenser, very important indeed). At a lower level, we also need a class modeling the database that provides persistent storage for the user's account and the information needed for authorization. For each of these classes we will use a CRC card to indicate their responsibilities and the classes with which they need to collaborate. The banking model consists of the classes account and transaction. The class account keeps a record of the actual balance of the account and must allow a user to deposit or withdraw money. However, for safety reasons, these operations are never carried out directly, but are performed by an intermediary transaction object. See slide 3-atm-2a.

Banking model

ATM


slide: The ATM example (2a)

The responsibilities of the transaction class may be summarized as: the validation of user requests and the execution of money transfers. The responsibility for maintaining audit information is also assigned to the transaction class. To act as required, a transaction object needs to communicate with a number of other objects. It must acquire information from both the card-reader and the database to check, for example, whether the user has entered the right PIN code. To validate a request, it must check whether the account will be overdrawn or not. To pay the requested money, it must instruct the cash-dispenser to do so. And it must contact the database to log the appropriate audit information. In contrast, an account only needs to respond to the requests it receives from a transaction. Apart from that, it must participate in committing the transaction to the bank's database. Note that the CRC method is non-specific about how the collaborations are actually realized; it is unclear which object will take the initiative. To model these aspects we will need a more precise notion of control that tells us how the potential behavior (or responsibility) of an object is activated. The second group of classes may be called interaction classes, since these are meant to communicate with entities in the outside world, outside from the perspective of the system. Also the bank's database may be considered as belonging to the outside world, since it stores the information concerning the account and the authorization of customers in a system-independent manner. See slide 3-atm-2b.

Interaction classes

ATM


slide: The ATM example (2b)

Both the card-reader and the cash-dispenser rely on a class called event, which is needed to model the actions of the user. For example, when a user inserts a bankcard, we expect a transaction to start. For this to happen, we must presuppose an underlying system that dispatches the event to the card-reader, which in turn notifies the teller machine that a new transaction is to take place. See also section cooperation for a comparative study of such mechanisms. The flow of control between a transaction object and the cash-dispenser is far more straightforward, since a transaction object only needs to issue the appropriate instruction. However, the actual interaction between the cash-dispenser and the underlying hardware, that turns out the money, may be quite intricate. The database may either respond directly to the request coming from the account or transaction object or it may respond to events by taking the initiative to call the appropriate methods of the account and transaction objects. Whether the database may be accessed directly or will only react to events is actually dependent on the control model we assume when developing the system model.