Description

You will be writing a program that runs an ATM (Automated Teller Machine), also called a “cash machine”. The program will display options on the screen and the user will select an option by typing on the keyboard. In real life, the user would press a touch screen, instead. We will assume that the ATM is the only interaction that the user has with their bank account. There is no physical bank at which your customer can make changes to their accounts, outside of your program.
Your program will allow users to interact with their accounts by:
viewing their account balance(s) transfer money between accounts that they own withdraw money from an account (This will decrease their balance.) transfer money from their account to another user’s account (This will also decrease their balance.) pay a bill by transferring money out to a non-user’s account (This can be stored in an outgoing.txt file that is outside of the program. It also decreases their balance.) deposit money into their account by entering a cheque or cash into the machine (This will be simulated by individual lines in an input file called deposits.txt. You can decide the format of the file. This will increase their balance.)
requesting the creation of an account from the bank manager
Each user can have more than one account. But no account can be co-owned by multiple users. Instead of using a card and numeric passcode to interact with their account, the user will have to use a login and password. Only a bank manager can create and set the initial password for a user. But the user can change their password, later.

Accounts
There are two main types of accounts: Debt and Asset. Debt accounts include:
1. Credit Cards Accounts
These are accounts that display a positive balance when the user owes money and a negative balance when the user overpays. It is not possible to transfer money out of a credit card account. But it is possible to transfer money in.
2. Line of Credit Accounts
A line of credit account allows you to transfer money in or out. But it also displays a positive balance when the user owes money and a negative balance when the user overpays.
Asset accounts include:
1. Chequing Accounts
If a user has only one checking account, it will be the default destination for any deposits. If the user has more than one chequing account, one of the chequing accounts should be selected as a “primary” account. This will be the default destination for deposits. Chequing accounts store a positive balance when money is stored in the account. The balance is allowed to decrease to -$100 if the user withdraws money when there is a positive balance, but the withdrawal is more than the balance. A negative balance beyond -$100 will not be allowed. A withdrawal from a chequing account with a negative balance will not be allowed.
2. Savings Accounts

Time

Handling Cash
The bank machine should know how many $5, $10, $20, and $50 bills it has. When the amount of any denomination goes below 20, your program should send an alert to a file called alerts.txt that the reallife manager would read and handle by restocking the machine. When a user requests a withdrawal, your program will have to decide which bills to give to the user and decrease the total of those denominations accordingly.

The Bank Manager
The bank manager is the only person who should be able to create a login and set the initial password for a user. Also, they can increase the number of $5, $10, $20, and/or $50 bills in the machine to simulate restocking the machine. Lastly, the manager has the ability to undo the most recent transaction on any asset or debt account, except for paying bills.

User Info
A user should have the option to see on the screen:

System Boundaries

What you hand in
This ensure that you are working on the most current version of your team’s files.
At the end of phase1, your repository should include:
1. All of your code
2. Examples of any files we need, in order to run your project. For example, include deposits.txt with a few lines of text in it, so we can easily edit it to simulate depositing money.
3. A file called README.txt that contains enough instructions so that we can run your program and try out all of the functionality. This includes anything we must do to start up the program initially.
4. A uml diagram that demonstrates the inheritance relationships between the classes that you wrote and implementation of interfaces that you wrote (if any). It should also include the names of all methods, the types of all variables, and the accessibility modifiers for both. If your entire uml diagram is in one file, call it design.pdf. If you have split your diagram into multiple files, call them design1.pdf, design2.pdf, etc.

Teamwork, Git, Comments, and Tests
We will look at your git log and will consider everyone’s contribution when deciding on your mark. We can also see the contents of each commit, so please do not cut-and-paste the same code back into a file without making changes or pretending that superficial changes are more important than they are.
It is helpful to the marker and also to your fellow team members to include proper Javadoc. If a part of your code is particularly difficult to understand, you can also leave a quick in-line comment to help the reader. Please do not include more comments than is helpful. If you do, it will take much longer to read through your code.

Preview of Phase 2
There will be some other features required in Phase 2 involving new types of accounts, allowing the user more options, and other types of bank workers who will have some of the same access as the bank manager, but not all of it.
You will also be asked to implement features of your choice. For example, your ATM could handle multiple currencies, investments such as buying/selling stocks, etc. Or you could design features that are not yet currently handled by banks, such as creating labels and paying for courier delivery service, handling in-game wealth/points for massive multiplayer online games, or other features that you think would be useful.
Your program has to run and satisfy the Phase 1 specification in order to get a passing grade. Do NOT add extra features until your Phase 1 works! However, you are welcome to design in a way that makes Phase 2 easier. Most of your Phase 1 marks come from your use of encapsulation, the absence of code smells, and adherence to the SOLID principles of design. If it is easy to work with your code (read, understand, add new things), then you will get a good mark. At the end of the semester, we will replace your Phase 1 mark with the maximum of your Phase 1 and Phase 2 marks.