Home MembershipSpecial Interest GroupsSIGCT (Computing Teachers)JCSE Online - Journal of Computer Science EducationPast Issues2001-2002 November 2001

One of My Favorite Assignments
Automated Teller Machine Simulation

Paul S. Oberman
Emory University

One of my favorite programming assignments is a program to simulate an automated teller machine (ATM). It is actually a program that I was taught in high school over the course of an entire semester, but it is usually one project of many in my introductory computer science classes. On occasion I have brought students to watch me make a transaction at a real ATM, and we have discussed the merits of the software. For example, during one demo I intentionally entered an incorrect password … and the machine let me go through the entire process of completing a withdrawal before telling me that my password had been incorrect much earlier in the process! Usually students are familiar with these machines, and the assignment explanation is fairly brief.

Assignment Description

Write a program that simulates an ATM. The user must enter an account number (similar to sliding in your bank card). The program then either welcomes the user or tells the user that she is not a member of this bank. If the user is a bank member, she is given three chances to enter a correct password. [In some cases I insist that they encode the password, if this is easily accomplished.] At this point either the user’s card is "eaten" and the person is kicked out, or the user is welcomed by name and then given a choice to withdraw from or deposit to either checking or savings. Remember that withdrawals may not exceed the user’s balance or the daily maximum of $300, must be positive, and must be made in increments of $10. Also check to ensure that deposits are positive and are not more specific than cents (for example, $15.234 should be disallowed). When the transaction is complete, the person’s information should be updated, so that if the user returns later, her account is properly modified.

Algorithm

Figure 1 contains one algorithm that could be used to accomplish the given task. Certainly other solutions are possible for the same problem.

Sample File Contents

Figure 2 illustrates the content and format of the data file for the ATM. Included are values for account number, customer name, password, balance in the checking account, and balance in the savings account. Note that no values are stored in the file documenting daily withdrawal amounts. We assume these values will be kept in the array of records used to maintain the data during updating. If only the record being updated is in main memory, then the data file will need to contain values for daily withdrawal amounts or this feature will be omitted from the program entirely.

Language Features Used

This program uses sequential files to store the bank’s account information. One possible assumption is that the file is in order by account number. If this is the case, and an array of records is used for storage, then a binary search could be used to locate the account number, considerably speeding up each search for a large banking institution. In all other cases, only a sequential search is feasible. Other possibilities exist with direct access files, but they are beyond the scope of this assignment.

Without a daily withdrawal maximum, this program can easily be implemented using only simple variables, using a single record (structure), or using an array of records (structures). Unless an array of records is used, however, (1) updating the sequential file becomes somewhat complex and (2) the file must be updated after each ATM customer then re-read when the next customer arrives.

1. In order to update the file without an array, a second file is required. The program will read and copy records from the original file to a temporary file until the record being updated is located, process the update (from any possible withdrawals or deposits), and then write the remainder of the file out to the temporary file. Then the program will write the temporary file contents back into a file with the original name so that this file is properly updated for the arrival of the next customer. If an array of records is used, the program can simply copy the records directly to the original file with no need for a temporary file.
2. Because only one record of information is available to the program at a time, the file will have to be immediately rewritten or the information will be lost. This also means that when the next ATM customer arrives the file must be read again to locate the new customer’s information and store it into the only record in memory. These steps would be necessary to ensure data integrity.

Assignment Variations

One simple extension that can be easily added to the program is the idea of a transfer from checking to savings, or vice versa.

Another challenge for the students can be the idea of a typo by the user. For example, if the ATM user meant to withdraw from checking but is now withdrawing from savings, is there a way to correct that typo? If students leave open the possibility of withdrawing or depositing zero dollars, a simple escape route is possible.

Discussion Points

The basics of the assignment include use of a file of records containing account number, name, password, and checking and savings balances. If all the records are not to reside in main memory at the same time, much discussion can take place concerning input files and output files.

Fruitful discussions can also be introduced on the best way to produce a menu. Some students may want to have a menu that gives the option to (W)ithdraw [user enters "w"], while others may prefer (1) Withdraw [user enters "1"]. Some students may prefer to have five menu items immediately—(1) withdraw from checking, (2) withdraw from savings, (3) deposit to checking, (4) deposit to savings, and (5) exit—while others may prefer to establish whether the user will withdraw, deposit, or exit before proceeding further to establish which account they will be using. Advantages and disadvantages of each approach may be discussed. A subroutine may also be employed to establish that a valid menu item has been entered. If this item accepts a low numeric value and a high numeric value, and returns the error-checked menu choice, this subroutine may be incorporated in many programs throughout the academic year.

One strength of this assignment is that it encourages modular programming. When students see that there is no reason to write a separate procedure to withdraw from checking and to withdraw from savings, they come to appreciate the concept of passing variables between the main program and subroutines. (The same can be said for the deposit procedure, of course.) Sometimes the students attempt to pass the entire array of records to this subroutine when in fact the only necessary part is an account balance (for example, bank_account[userid].checking). If this occurs, students may also exceed the program’s memory, and further design issues such as value and variable passes can be discussed before or after the suggestion to pass only the relevant portions of the record.

The program also encourages a very thorough test plan, which I insist that they submit with their program. They must be sure to test for such occurrences as:

• Not a bank member
• Incorrect password 3 times
• Correct password on third try (often an issue, because students may check only to see if incorrect_password_counter = 3 rather than if password is correct)
• Incorrect menu entry
• Attempt to withdraw/deposit a negative amount
• Attempt to withdraw more than account balance
• Attempt to withdraw not in increments of ten
• Attempt to withdraw more than $300 per day, in one or many transactions
• Attempt to deposit an amount more specific than cents

Another strength of this program is its data structure flexibility. With only a minor modification (removing the daily maximum withdrawal amount) this program can be done using only simple variable types, using only a record, or using an array of records. Using an array of records simplifies the "file update" procedure at the end, but the student who only uses a record learns a great deal about file processing and how much work it can be to merely update a single line of a file. Students who use only simple variable types usually regret their decision later and come to appreciate the strength of being able to pass everything in a record to a procedure easily.

The teacher may lead an interesting and fruitful discussion by mentioning the possibility of a computer error in the middle of the day. With an array of records and the intent to write to the file only at the end of the day, all the information from earlier in the day would be lost. One possible way to account for this possibility is to write an audit trail file detailing the transactions of the day. If computer crashes are very likely, programmers might also want to consider writing to the file after every fifth or tenth customer in order to eliminate the manual updates that would be required with only an audit trail.

An extra benefit of the program is that students really appreciate the "real life" application and will often come in weeks later talking of an automated teller machine that did not live up to their coding expectations.

Contributor

Paul Oberman is currently a PhD student at Emory University. He has worked as a software consultant and has also taught computer science for nine years. His research interests include student interaction in the computer science lab, particularly help-seeking behaviors. Away from work he enjoys playing Ultimate Frisbee and racquetball.

Contact

Paul S. Oberman
PO Box 22928
Atlanta GA 30322
poberma@emory.edu
http://userwww.service.emory.edu/~poberma

Copyright © 2001, ISTE (International Society for Technology in Education). All rights reserved.