Banking model
ATM
| transaction |
keeps balance | database |
deposit money | |
withdraw money | |
| transaction |
keeps balance | database |
deposit money | |
withdraw money | |
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
| transaction |
keeps balance | database |
deposit money | |
withdraw money | |
| event |
emits cash | transaction |
| event |
emits cash | transaction |
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.
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.