Money Manager
Assignment
Overview
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 test money manager.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
money manager test case.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
MoneyManager
user_number: int
pin_number: String
balance: float
transaction_list: list of
two-tuples
add_entry(amount, entry_type)
deposit_funds(amount)
get_transaction_string()
save_to_file()
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 Entry Type 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.
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 "Fed Uni Money Manager"
using the top-level window object's winfo_top level().title() function.
The
window uses the Grid Manager layout manager for placing GUI elements (e.g.
'widgets'), it contains a Label that spans the top of the window saying
"Fed Uni 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 message box 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 Money Manager 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 :
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 Money Manager class' deposit funds and add entry methods
operate correctly.
You are provided
with a stub of a test money manager.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 Money Manager 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 set Up 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 this 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 penalized for not matching the project
specification.
Comments
Post a Comment