ITECH1400: Foundations of Programming - Money Manager - Python Script - IT Assignment Help

Internal Code: A_AI_DAAD_AAB

IT Assignment Help

Task:  Class Design – Money Manager Tool The following design for MoneyManager 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:

o 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 o 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): user_number user_pin currentBalance 123456 7890 800.00 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: Deposit 500.00 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: Rent 200.00 Bills 250.00 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. Login Screen When the application is first launched, it should open a window that is "500x660" 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! Development and Marking Tips You will need to bind all the numerical log in buttons to the <Button-1> event and the same function, and then extract which button was pressed to help 'build up' the PIN number text. To extract which widget triggered the function use event.widget["text"]. You are provided with the complete function to remove all widgets from the top level window, the function to read a line from the user file which does NOT include the final "\n" newline character and most of the code to generate a graph and place it in your window - so you do not have to write these yourself. The grid for the login screen has 3 columns and 6 rows, while the grid for the user screen has 5 columns and 5 rows. The fifth column on the user screen is the one holding the scrollbar. Once you have your login screen working, it makes sense to set the user number variable and PIN number variables to '123456' and '7890' respectively so that they are already filled in when you launch the app and you can immediately click the "Log In" button to move to the user screen. Without this you will have to enter these values each time you run the program, which will be a nuisance. When you are writing your code to save the money manager user object to file be aware that if the function fails before closing the file then the file will now be blank (i.e. it will not contain any user details). As such, it's probably best to keep a copy of the file close by so you can replace it if necessary. The way this assignment is marked is a little different from assignment 1 where you could get marks for effort - that is, if something didn't quite work as it should you would still get marks. This was because you were designing the code and its logical flow. In this assignment you are given a precise specification of how the application should work, and the marking guide is more along the lines of "did you implement this feature as specified?, did you implement that feature as specified?". The answer to these questions is largely a simple yes or no - if you did, you get the mark - and if you didn't then you don't get the mark. If your code doesn't run at all (i.e. it produces an error on startup) then it means your code cannot possibly implement the functionality, and your marks will be severely affected. Nobody wants this - so even if you do not implement the entire suite of functionality, please make sure that your code at least runs! As a final reminder, please do not add functionality that is not described in this document. Rather than being rewarded with extra marks you will be penalised for not matching the project specification.

This ITECH1400: IT Assignment has been solved by our IT experts at My Uni Paper. Our Assignment Writing Experts are efficient to provide a fresh solution to this question. We are serving more than 10000+ Students in Australia, UK & US by helping them to score HD in their academics. Our Experts are well trained to follow all marking rubrics & referencing style.