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


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

  • our candidate 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.