ITECH1400 – Assignment 2 – Money Manager
You are tasked with creating an application that uses a GUI that simulates a simple money manager. This tool is used to track all spending of an individual.
The assignment is broken up into the following main components:
1.) The ability to provide a login screen to prevent other people from viewing the information contained in the tool
2.) The ability to view the current balance funds, add purchases made and deposits into the balance
3.) The ability to save the transactions to a file so that you can log in, add transactions to the application, log out and then return to find all of the transactions still there – i.e. the data is persistent.
4.) The ability to display a graph of your spending broken down by type – i.e. food, bills, rent.
5.) A Test Case that ensures that your simple money manager works as required.
Your submission should consist three Python scripts that implement the computer program (moneymanager.py, main.py and testmoneymanager.py).
You are provided with a ‘stub’ of each of these files which contain all the function declarations and comments which describe the role of the function and how it can be put together, but you will have to write the code for vast majority of the functions yourself. You are also provided with a stub of the moneymanagertestcase.py file.
Your final submission should be a zipped archive (i.e. ‘zip file’) containing your completed Python scripts.
Assignment Part 1 Details
Class Design – Money Manager Tool
The following design for MoneyManager
transaction_list: list of two-tuples
The following is the functionality of the class:
- add_entry – this adds a new entry into the money manager representing the spending of the user. This includes the amount spent and the type of item the money was spend on. It also removes the amount from the current balance. For the sake of simplicity the type of item the money was spent on can only be food, rent, bills, entertainment or other – any other type will raise an exception that should be handled
- Each transaction in the transaction_list is a tuple containing the word Deposit followed by an amount or EntryType followed by an amount
- The user the tool represents cannot go into a negative balance so the user cannot spend money that is not available in their user. So if they have $100 in their user and then want to add an entry to spend $150 an exception will be raised with a suitable error message which is caught and displayed in the main.py file where the operation was attempted.
- All error messages, such as those from exceptions, should be displayed in a pop-up message box
- The get_transaction_string method should loop over all the transactions in the transaction_list creating a string version (with newline characters) of all the transactions associated with the user.
- The save_to_file function should save the user_number, pin_number, and balance in that order to a file called <user_number>.txt followed by the transaction list string generated from the get_transaction_string() method. The name of the user file is NOT ‘<user_number>.txt’ – the name of the file is the ACTUAL USER NUMBER followed by “.txt”, so for an user with user_number 123456 the name of the user file would be 123456.txt.
The Main Python Script
Our main.py script will contain all the main logic for our program. It will allow us to:
- Enter a user number via an Entry field by using the keyboard,
- Enter a PIN number via an Entry widget (we can use the keyboard OR a series of buttons to enter the PIN),
- Once we are logged in we must be able to:
- See the balance of the user, o Deposit money for the user,
o Add entries to represent spending of funds from our user (only up to the amount we have available),
o Display a plot of spending
- Log out of our user.
Every time a successful deposit or entry is made then a new transaction should be added to the user’s transaction list. When we log out then the user file is overwritten with the new user details including our new balance and any transactions if any have been made.
The format of the user text file is as follows (each value on separate lines):
After these first three lines we may have a number of transactions, each of which is specified as two lines. A deposit is indicated by the word Deposit on one line and then the amount on the next like. For example a deposit
of $500 would look like this:
Similarly, a entry is also specified as two lines – first the word being the type of entry and then on the next line the amount, for example entries representing rent of $200 and bills of $250 would look like this:
You are provided with an example user file called 12345678.txt – this file along with others will be used to mark your assessment, so you should make sure that your final submission can use users in this format successfully.
When the application is first launched, it should open a window that is “500×660” pixels in size (use the window object’s geometry function to set this). Set the title of the window to “FedUni Money Manager” using the top-level window object’s winfo_toplevel().title() function.
The window uses the GridManager layout manager for placing GUI elements (e.g. ‘widgets’), it contains a Label that spans the top of the window saying “FedUni Money Manager” (font size is 28). On the next line is a label saying “User Number” and then an Entry widget for the user to type in their user number and an entry for the PIN number.
It then has a series of buttons from 0 through 9, along with a Log In button and a Clear/Cancel button.
Each time a number is pressed it is added to a string – for example, if the user pushed the 4 button then the 3 button then the 2 button and then the 1 button then the string should contain the text “4321”. By using the show=”*” attribute you can ‘mask’ the input so that anyone looking over your shoulder cannot see the exact pin number, they’ll just see “****” instead. When the Clear/Cancel button is pressed, or when a user “logs out” then this PIN string should be reset to an empty string.
When the Log In button is pressed then the program should attempt to open the file with the user number followed by “.txt” – so in the example below, because the user number entered was “123456”, the program will attempt to open the file “123456.txt”.
If that file could not be opened then a messagebox should display a suitable error message such as “Invalid user number – please try again!”. You will have to “try/catch” this risky functionality to avoid the program crashing – see the week 7 lecture materials if you need a recap.
If the user exists, then MoneyManager object should be created and the fields of the MoneyManager object should be set (e.g. user_number, pin_number, balance, and the transaction_list).
Because you don’t know how many transactions are stored for this user, after reading the first three lines you will need to attempt to read two lines and if they exist create a tuple of the transaction (i.e. it’s type and amount) and then add it to the MoneyManager object’s transaction_list – for example you may do the following in a loop:
- Try to read a line, break if we’ve hit the end of the file line = read_line _from_user_ file()
if not line: break
else: # read another line, create a tuple from both lines and append the # tuple to the the MoneyManager object’s transaction_list
The user screen has:
- A large “FedUni Money Manager” label at the top that spans 5 columns (font size is 22),
- A label with the user number followed by the actual user number displayed,
- A label with the current balance followed by the actual balance,
- A log out button which saves the user file (overwriting it) and causes all widgets to be removed from the screen and the log in screen displayed again,
- An “Amount” label followed by an amount Entry widget where you can type in how much to deposit or an entry added,
- Deposit and Withdraw buttons that deposit or withdraw funds using the MoneyManager classes methods to do so,
- A Text widget (i.e. multi-line text) that shows all the transactions associated with the user. The height of this widget is 10 lines and the width of the widget is 48 characters.
- To the right of the Text widget this is a scrollbar which can be used to scroll the Text widget (it is not really showing in the above screenshot because the Text widget does not have more than 10 lines worth of content), and finally
- At the bottom of the screen is a plot (histogram) of the spending of the user broken down by type
Below is the top section of the screen:
Money Manager Test Case
The final thing to do is to add a small test case consisting of five unit tests that ensure that the MoneyManager class’ deposit_funds and add_entry methods operate correctly.
You are provided with a stub of a testmoneymanager.py test case that already has the definitions of the five unit tests that you will write and a description of what they are testing. Your job is to write suitable assert statements into each of these unit tests so that they ensure the MoneyManager class’ deposit and add entry functions do operate as they should. You should be able to accomplish each unit test in a maximum of two lines of code per unit test.
Two things to remember:
1.) The setUp method is automatically executed before each unit test, so the balance gets reset to 1000.0 before each test, and
2.) If your unit test fails (and the test is correct) then you should modify your code so that it passes the test, not the test so that it matches up with what your code is doing!
- File Format: Python .py
- When will I get my solution? Within 48 hours of successful payment, contact firstname.lastname@example.org for more details