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.