Example -- ATM (1)
The example of an automated teller machine
discussed in [WWW90] nicely illustrates a number of
the notions that we have thus far looked at only
in a very abstract way.
A teller machine is a device, presumably familiar to everyone,
that allows you to get money from
your account at any time of the day.
Obviously, there are a number of constraints
that such a machine must satisfy.
For instance, other people should not be allowed
to withdraw money from your account.
Another reasonable constraint is that a
user cannot overdraw more than a designated
amount of money.
Moreover, each transaction must be correctly
reflected by the state of the user's account.
Candidate classes
ATM
- account -- represents the customer's account in the banks database
- atm -- performs financial services for a customer
- cardreader -- \c{reads and} validates a customer's bankcard
- cashdispenser -- gives cash to the customer
- screen -- presents text and visual information
- keypad -- the keys a customer can press
- pin -- the authorization code
- transaction -- performs financial services and updates the database
slide: The ATM example (1)
An initial decomposition into objects based
on these requirements is shown in slide [3-atm-1].
In [WWW90], a fully detailed account is given of how
one may arrive at such a decomposition by carefully
reading (and re-reading) the requirements document.
What we are interested in here, however,
is how we may establish that we have not overlooked
anything when proposing a design, and how we may
verify that our design correctly reflects the requirements.
This particular example nicely illustrates the need
for an analysis of the use cases.
To develop a proper interface, we must precisely
know what a user is expected to do
(for instance, insert a bank card, key in a PIN code)
and how the system must respond (what messages must
be displayed, how to react to a wrong PIN code, etc.).
Another decision that must be made is when the
account will be changed as the result of a transaction.
Also, we must decide what to do when a user overdraws.
A very important issue that we will look at in more
detail in the next sections is how the collection
of objects suggested above will interact.
What means do we have to describe the cooperation
between the objects, and how do we show that the
proposed system meets all the requirements listed above?
Moreover can we verify that the system satisfies
all the constraints mentioned in the requirements document?
Validation
However, before examining these questions
and trying out different scenarios, we may as well
try to eliminate the spurious classes that came up
in our initial attempt.
In [Rum91], a number of reasons are summarized that
may be a ground on which to reject a candidate class.
See slide [3-eliminating].
Eliminating spurious classes
- vague -- system, security-provision\c{, record-keeping}
- attribute -- account-data, receipt\c{, cash}
- redundant -- user
- irrelevant -- cost
- implementation -- transaction-log\c{, access, communication}
Good classes
slide: Eliminating spurious classes
For example, the notion underlying the candidate class
may be too vague to be represented by a class,
such as the notion of system or record-keeping.
Another reason for rejecting a suggested class
may be that the notion represents not so much a class,
but rather a possible attribute of a class.
Further, a proposed class may either be redundant,
for example the class user, or simply
irrelevant, as is the class cost.
And finally,
a class may be too implementation oriented,
such as the class transaction-log
or classes that represent the actual communication
or access to the account.
Looking back, our choice of candidate classes seems
to have been quite fortunate,
but generally this will not be the case,
and we may use the checklist above to prune
the list of candidate classes.
An interesting architectural issue is, how may we
provide for future extensions of the system.
How easily can we reuse the design and the code for
a system supporting different kinds of accounts,
or different input or output devices?
As illustrated by the example,
a linguistic approach, despite its apparent naivit\'{e},
may be a valuable heuristic in a first attempt
at finding a decomposition into objects.
However, the example also illustrates the need
for additional heuristics to establish that the objects, as
identified, interact as desired.