Modeling an ATM
You will work in pairs to practice object-oriented design while modeling an automatic teller machine that builds upon your existing BankAccount inheritance hierarchy.
You will turn in a brainstorming document that demonstrates your process for finding classes, determining classes’ responsibilities and finding the relationships between classes. This should include a rough class diagram (doesn’t have to be formal UML). You will then implement the ATM and a textual client to test it.
Each customer of a bank has a customer number, a PIN (personal identification number) and two accounts: a checking account and a savings account. A customer must enter in their number and PIN correctly to use the ATM (if they don’t exist in the bank or type in an invalid PIN, they are prompted again for an account number). Once the correct information is entered, a customer can select an account. The balance of the selected account is displayed. The customer can then deposit or withdraw money. Once the transaction is complete, the user is back at the account choosing screen until he/she chooses to exit.
Your classes should be entirely independent of the user interface. We will start by building a textual interface for testing then will soon learn to build a graphical interface (GUI) for it.
Here is a test run using a textual interface:
Enter account number: 1 Enter PIN: 1234
A=Checking, B=Savings, C=Quit
Select account: A
Balance=0.0
A=Deposit, B=Withdrawal, C=Cancel Select transaction: A Amount: 1000
A=Checking, B=Savings, C=Quit
Select account: C
Here is what the GUI might look like:
Your ATM should always be running, so it may help you to use an infinite while(true) loop. Your client will also need to keep track of the state your ATM is in to display the correct messages and interpret commands properly. This state diagram should help you reason about this:
The ATM will need to keep track of its current state. It might help readability to give each state a class constant.






