Assignment: Classes and Objects II: ATM System Overview This lab involves the design and implementation of a transaction system using classes and objects. Do not use complex data structures such as linked lists or trees (if you don't understand these restrictions, then ignore them, we will get there). The system modesl a simple Automatic Teller Machine (ATM) that allows account holders to process various transactions such as deposit and withdrawal. Managers have more options. An example account database will be provided via a Google spreadsheet. The classes and data members are defined as is the functionality of the ATM. Students must translate these into appropriate methods, functions, and main code. An important point is to decide to which class a method should be assigned if there is no clear answer for this. Emphasis is on an effective and efficient design and implementation. Get started early. There is a good chance after you get into this, you will throw out your first attempt and start over. Do not go straight to coding. Plan your system top down. Grading will place considerable emphasis on good code: neat and consistent lay out, well commented, easy to follow, efficient, easy to modify, effective variable naming, effective use of variable typing (use of const, call by reference versus call by value, etc.), unnecessary code, etc. Sloppy code will be graded down considerably regardless of the fact it may work. Sometime(s) during development, you may receive changes to specifications or clarifications. Designing good code will help you deal with them quickly. Extension to the due date is not an option. Design and Implementation Details and Clarifications Design UML diagrams for all classes. Use a Google spreadsheet or similar. Submit one image file with the diagrams to the Sakai assignment. E.g., .jpg or similar. You can do this taking a screenshot of your UML document. UML diagrams are in chapter 8, and an introduction to UML is in Sakai->Resources. Once design is finalized, write the .h files for the classes. Be sure to consider member functions' return values and how parameters are passed. These files will be called: ATM.h, and Account.h. For all parameters and methods, use const whenever applicable to ensure no side effects (inadvertent changing of values). Pass by value or reference as the application might dictate. Be able to state reasons for your choice. Include default and other constructors as needed for both classes. Implement these classes in: ATM.cpp, .h and Account.cpp, .h. Design and implement four unit tests for your classes that use assert(). Do not write four similar tests (e.g., four tests of only setters). Invoke these tests in your code to be sure they work. One of the unit tests should test the userID validation. Use #define TEST with #ifdef TEST to compile or not compile the unit tests. Write main() in main.cpp that inputs the database file name (not the file) and creates an ATM object. Creating an ATM includes loading the accounts vector. See below for more information on this. main() should also input the output file name. The database will be loaded in from a tab-delimited txt file (.txt extension). A sample database will be provided in a Google spreadsheet, which you can put in an txt file in various ways. One way is to first download as an Excel spreadsheet. The file name should be: ATM_Data.txt. However, you should be able to create your own database. When reading in, make a vector of account objects as part of the ATM. Use switch statement(s) to select transactions. Do not worry for now about checking for non-numeric input when numeric input is required. However, you should see what happens when you provide non-numeric input just to be aware. Comment appropriately and liberally be sure the comments explain and simply do not repeat the code. Comments should show program flow major blocks, and clarify tricky or non-obvious code. Each class should have appropriate setters, getters, and print methods. Duplicate userID or PIN not allowed. I.e., both should be unique in the database. When writing out the database, the output file should be tab-delimited txt file named: ATM_Data_Out.txt.This file should be formatted the same was as the input so it could be used also as an input. Class Data Item Specifications An example of an account database will be made available in a Google Spreadsheet. ATM Name (string) ATM name. E.g. WFU Student ATM Location (string) ATM location. E.g., WFU Hearn Plaza Total # of currency bills available for withdrawal in ATM (int) Keep running total. Currency size (int) Currency size available in the ATM. E.g., 20 indicating only $20 bills. Thus, any withdrawals must be validated against this number. Only one currency size is available. Total withdrawal # bills (int) Running total of currency bills withdrawn. Total withdrawal # (int) Running total of number of withdrawals. Total deposit $ (int) Running total of $ deposited in the ATM. Max Single Withdrawal Amount $ (int) Individual account max for all accounts. Takes precedence over same field in an account. Max Total Number of Withdrawals # (int) Individual account max for all accounts Accounts (vector ) Database of accounts from file. Account userID (string) specifications as in functions lab. PIN (unsigned int) valid range for all PINs [1001:9999] Last Name (string) No whitespace allowed (assume input correct). Account Type (char) 'C' customer; 'M' manager. Account Status (char) 'A' active; 'C' closed. Account Balance $ (unsigned int) Keep running balance Max Single Withdrawal Amount $ (int) Individual account max for the specific account Total Deposit $ (unsigned int) Total amount that has been deposited over time Total Deposit # (unsigned int) Total number of deposits into account over time Total Withdrawal $ (unsigned int) Total amount that has been withdrawn over time Total Withdrawal # (unsigned int) Total number of withdrawals from account over time Use (functionality) Specifications (these would correspond to a use-case diagram) Startup The ATM starts, an ATM object is created, and the database is loaded. Login prompt is presented. Login options Request and verify userID and PIN (in that order). Request both then verify. If incorrect, request both again. After logging in, the Account Type for a Customer should constrain the possible transactions that can be performed, as indicated in the bullets below. Account Transactions for all account types (W) Withdraw $. Confirm funds available, multiple of currency size, and other limitations on the ATM. Then confirm funds available and other limitations on the user. No negative balances allowed. Update Total Withdraw $ and Total Withdraw #. (D) Deposit $. Update Total Deposit $ and Total Deposit #. Deposits can be in any whole dollar amount. (B) Check Balance. Print account info using account print method. (Q) Logout. Go back to the login request. (U) Change userID. Be sure to validate per userID specifications and ensure the new userID is not the same as another customer. If an invalid change is requested, prompt again for a new userID. Account Transactions only for 'M' account types. (X) Shutdown ATM. Output updated ATM as a new, tab-delimited txt database to a file. Overwrite the file if it exists. The file name should be: ATM_Data_new.txt (A) Add Account (Request a userID, PIN, and Last Name (in that order). Verify no duplicate userID or PIN and that the userID and PIN are valid. Set all other fields to a default value of 0. Make it active. (L) Load currency into the ATM. The amount would be the number of currency bills not $. (C) Close Account. Verify userID and PIN, mark as closed (C). (R) Report - list account information for all accounts. Use print method for account class. (N) Change Name and Location. Output current Name and Location and request new. Print new and ask to verify. If manager does not verify, do not change and go back to transaction input. Program Flow Specifications Input the account database file name from the console (user input) and load the account database into the ATM (implement an ATM load method). The path and file name should contain no spaces (blanks). Input the output file name from the console (user input). The path and file name should contain no spaces (blanks). Loop until valid login provided (userID and PIN) Loop inputting and processing transactions. (Prompts for input should be consistently formatted, unambiguous, and concise.) If an invalid transaction letter is input, indicate an error and request again. If logout (Q) transaction, then return to requesting valid login. If Shutdown (X) transaction (Manager only), output report of updated database in a neat column format (this is the print method and should use the account print method). Write the new data base file, removing all closed accounts. Then stop program. Process all other valid transactions as appropriate. E.g., request amount for D or W transactions. Any transaction that results in an error of any type should print: ***ERROR*** followed by an explanation of the error on the same line. Then return to whatever point of program needed. Example: A problem with any transaction, insufficient funds, etc., should request a new transaction not new funds amount. When checking for limitations on a transaction, such as funds available, ATM limitations take precedence over account limitations.