In this project, you will implement a simulation of a simple Automatic Teller Machine (ATM) bank teller system. This project will give you experience in working with aggregation, file I/O, creating a user interface, as well as working on a larger, more-complete system, which you will design and implement on your own.
This project is divided into achievable parts that will each be built on one another; each type of account as well as "transaction information" can be developed incrementally and added to the system. At its most basic level, the project consists of a command-line interface for the ATM and interaction with account files, which contain information for individual accounts. At its most complex, the project consists of several types of account as well as an interface to account transaction history.
User files (account files) will exist as text files before the program is executed. Your program should accept "commands" to login and perform transactions on a user's bank accounts: Inquiry, Deposit, Withdraw, and Transfer to/from the accounts for a given user. Note you do not need to include an interface to "create accounts." Each user login id will be used as the name of the file (with a extension .bnk) that contains account information for that user. The first line of each of these user files will contain that user's password (in ASCII text), checking and savings account information, and line-of-credit information. The remainder of the file will contain a list of past transactions. A detailed description of the user file can be found below. Your interface will first allow a user to login to the system and then perform a series of transactions until the user Quits.
The above specifications include a percent, e.g. Basic Project (70%), which indicates that if you complete the Basic Project portion of the project then you receive a starting grade of 70. That grade of 70 is a starting point for the GTA to grade your project for its design, documentation, and code quality. For example, if you only do the 50% specification and you lose 20% for your design, then you will receive a 50 on the project. These projects will be graded for Design (20%), Documentation (20%), and Code Quality (30%). This means that if you have documentation, for example, that has virtually no redeeming qualities or is virtually absent, then you can lose up to 20%; similarly for the other two categories.
This project works with ASCII text files a great deal. Each user/customer has a file for their accounts; the name of the file is the user's "login" name with the extension .bnk. The password is on the first line in the file followed by information for the user's accounts, separated by whitespace. For example, for me, there would be a file called todds.bnk, and it might contain the following:
blahblahblah 500.00 12.32 100.02 1000.00 0.04 0.16
The first word is my password, which can be up to 20 characters long. The rest of the line corresponds to me having $500.00 in my savings, $12.32 in my checking, $100.02 in my line-of-credit (LOC, overdraft protection), $1000.00 limit for my LOC, 4% interest for my savings account, and 16% interest on my LOC. The first line of each file will always contain all of these fields. The LOC account is similar to a Credit Card account; money can be borrowed from the account up to the LOC limit. This account also serves as an overdraft protection account in the case that the checking account becomes overdrawn (either by a check overdrawing the checking account or a user withdrawing more money from his checking or savings account than he has in it).
Keep in mind that the balance of the LOC account goes UP when money is 'withdrawn' and goes DOWN when money is deposited (consider a deposit as a loan payment). Money cannot be borrowed above the credit limit.
The following is a general description of the first two lines of the user files:
passwd sav-bal check-bal LOC-bal LOC-limit sav-int LOC-int
All succeeding lines in the user files are transaction entries. Transaction entries are added at the end of the transaction list every time a transaction is performed on that user's accounts. Each transaction begins with a label for the transaction type: Deposit [D], Withdraw [W], Transfer[F,T], and Overdrawal[O]. Next, the date and time of the transaction are shown. This is followed by the account [S,C,L], the amount of the transaction, and the account balance after the transaction. The format of the transactions are:
D 12/30/98 22:33:22 S 0.00 0.00
D 12/30/98 22:33:22 C 0.00 0.00
D 12/30/98 22:33:22 L 0.00 0.00
W 12/30/98 22:33:22 S 0.00 0.00
W 12/30/98 22:33:22 C 0.00 0.00
W 12/30/98 22:33:22 L 0.00 0.00
F 12/30/98 22:33:22 C 0.00 0.00
T 12/30/98 22:33:22 S 0.00 0.00
F 12/30/98 22:33:22 S 0.00 0.00
T 12/30/98 22:33:22 L 0.00 0.00
O 12/30/98 22:33:22 C 0.00 0.00
Each transfer is represented by 2 lines: the first [F] indicates money being transferred from one account. The [T] indicates money being transferred to another account. The first transfer above represents money being transferred from Checking to Savings. A transfer is not processed if it causes an account balance to fall below $0. The second transfer represents a transfer from Savings to LOC.
An overdraft [O] occurs when a withdrawal from either Checking or Savings results in a negative balance. In this situation, the amount overdrawn is taken from the LOC account to bring the balance back to $0. In addition, a $1 fee is charged to the LOC account. The transaction is represented above with the account that was overdrawn [C or S] followed by the amount overdrawn, followed by the ending balance of the LOC account after the transaction. Note: if an overdraft would cause the LOC account to go above the credit limit, then the withdrawal will NOT be allowed. The LOC balance will NEVER exceed the credit limit.
When developing the Interface, you need to realize things like 1 transfer transaction results in at least 2 transaction entries in the transaction history (typically a T and an F). I.e. one action might produce more than one transaction in the file. Similarly, in the interface, a transfer from Savings to the LOC might be a type of "Payment" instead of a transfer. Also, a withdrawal from the LOC probably should be called something other than a withdrawal. You need to develop the interface accordingly.
As to the Transactions Interface, a good one won't just show the T and F transactions; the interface should combine those into a "Transfer," similarly for the Overdraft transactions. I.e. more than one transaction can be combined to be one action in the Transaction Interface.
We will not provide any test files. You are responsible for testing your own code. Remember that you should define test cases as you are writing the code. As a start, you can copy the above lines to test you code.
Login ID: __________
Pick the number of one of the following operations:
Pick the type of Account to Query: