Programming Project #4 Solution

Overview

For this project, you will implement a simple tool that might allow a user to keep track of their spending habits and try to keep to a budget. The project will be implemented using a client-server architecture, such that the client doesn’t maintain any data about the budget, but is instead just an interface that communicates with a server that maintains all budget data. Further, in order to make the system useful, the budget data will be stored on the server in a data file so that the user can use the program multiple times, essentially picking up where they left off.  AS you will see, we are going to “cut corners” on some aspects of this project so that the main focus can be on implementing the file I/O, use of data structures to store budget data, and the socket-based communication between client and server.

 

Due Date and Submission

This project is due Monday. Use the same submission

process as was described for project 1, 2, and 3. Both early bonus and late penalty are available and will apply as described in the course syllabus.

 

This program must be implemented in a package named: eecs285.proj4.<uniqname where

<uniqname is replaced by your UM uniqname. For example, my uniqname is morgana, so I would implement my solution in a package named eecs285.proj4.morgana.

 

Submissions will be made on Canvas, and that will be the only accepted method to submit. Email submissions are not accepted for any reason.  Canvas will not allow submissions after the posted times, and remember that extensions and late submissions are not allowed. Do not zip, jar, tar, gzip, or otherwise combine or compress your source files when submitting – instead simply attach all applicable

.java source files to your Canvas submission.

 

Important note:  You will submit your source files that contain Java source code (i.e. those ending in

.java).  Do NOT submit your .class files. It is the student’s responsibility to ensure that the correct files are submitted, and that all required files are submitted. We will only accept and grade the files submitted to Canvas for your last submission, so missing source files, or accidentally submitting .class files instead of .java files will result in an incomplete submission, leading to a grade of 0.  Resubmissions within the submission period are allowed, but only the complete set of files submitted on your last submission will be used, so if you make a change to a single source file, remember to attach ALL source files to each submission, and NOT just the updated files.  Also - please verify in Canvas that you have submitted all the proper files to avoid these types of problems.

 

Client and Server

As mentioned above, you will implement your solution using both a client and a server that work together, communicating over a socket. The client will be nothing more than a very simple graphical user interface (GUI) that allows the user to interact with the interface in order to communicate requests to the server. The server will be a separate main function that will do the majority of “the work”. That is, the server is responsible for reading the user’s budget data from a file, storing it in some data

structures while the server is running, receiving requests from the client and responding back to the client in an appropriate way.  Remember, this project must be implemented this way, and the client must be implemented such that it is just a GUI that displays information from the server. The client

must not know any of the budget details or try to store any budget-related data locally within the client.

 

Things Not To Worry About

Since this project is a shorter project than the majority or projects in this class, there are many things that you do not need to be concerned with.

 

•   File Format:  While every programmer ought to always be concerned with the correctness of file

formats, we’ll keep things simple for this project and agree that only files with the correct

format will be used during testing. This is a terrible, terrible assumption to make in general.

•     Prettiness of the GUI: I’ll provide a brief overview of how I organized the Swing components on my GUI. You should do the same and not worry about the fact that its not real “pretty” – again, this project is really about socket communications, file I/O, and storing data in data structures. As long as your GUI looks and acts like what is described in these specs, that is sufficient – it could certainly be made to look a lot nicer if there were more time available for implementation.

•     Multiple Clients: Certainly, you could imagine multiple members of a household working off of the same budget, and potentially be using the program at the exact same time, on two separate devices. With a client/server architecture like this, it would not be all that hard to do that, but with that comes some significant potential for difficulty (like race conditions, atomicity of transactions, etc.) Therefore, for this project, you can assume it will be used by one user at a time.

•     Efficiency: While you should always try to avoid ridiculous inefficiencies, we are not expecting you to take any significant steps to make your code especially efficient. There could be ways to speed up reading in the budget data file and populating your data structures (for example) but don’t worry about doing anything special to make it as fast as possible. Keep it simple even at the cost of a little slow down.

•   Multiple Categories with Same Name, Transactions with Unexpected Category Names: These are

essentially “file format” issues – we won’t test your program with budget data files that have the same category name listed more than once in the category section, and we won’t specify transactions with categories that aren’t listed in the category section of the file. You can do the error checking if you’d like, but it’s not necessary for this project.

•     Dated Transactions: Ideally, we would store dates that our transactions occurred on, but dates are a pain, so we won’t bother storing date information.  A transaction will consist only of the category to which it applies, the merchant at which it occurred, and the amount spent in the transaction.

•   “Inflow” Transactions: Obviously, we should allow the user to have “inflows”, but we won’t both

for this project.  All transactions will be “outflows” (i.e. money being spent on something).

•     Multiple Periods (Months): Usually a user would set budget amounts per month, and the beginning of each month would result more money being allotted to each category. Since we’re not dealing with dates, we’ll develop this project for a single month’s use only.

•     “Split” Transactions: Sometimes transactions, especially at grocery stores, etc., would be charged to multiple categories (i.e. some food, some entertainment). For our project, we will only allow a transaction to apply to a single category – if the user wants to split a transaction, they would have to input multiple transactions for it.

•   Security Features: In a real budgeting system, you’d probably want the data encrypted, and/or

stored in a binary format for space efficiency, password-protected, user account-managed, etc.

 

It would be easy to think up a ton of nice features that would make this program much more useful and

more secure, but we’re trying to keep things simple given the short timeframe of this project.

 

Things To Remember

This list of things are things that are important for this project, and need to be

 

•     Storing Duplicated Data: You may not store duplicated data. Don’t store the same thing multiple times for convenience, and don’t store values that can be computed using other data that is stored. This does not mean you can’t have a local variable to a method store a computed value, but it does mean you cannot have a class attribute that stores a value as an attribute if it could otherwise be computed or is stored in some other form already.

•     Money values are displayed as dollars and cents with a decimal point in between – the cents portion must be exactly two digits. For example, money values should be displayed as “13.00” or “14.82”, etc., and NOT as “13” or “13.9” or “14.820000001”.

 

The Client GUI

The general look of the GUI is shown here:

 

To make this GUI, I simply implemented a class that extended JFrame, and used several Box components for layout.  The content pane of the GUI is one big vertical Box. Each “row” in the GUI is a horizontal

Box.  For example, there is a horizontal Box that contains a JLabel with the String “Category:” and a

JComboBox containing the category choices. Both the label and the combo box are in a horizontal Box, and that horizontal Box is then added to the overall vertical Box.

 

After that, another horizontal Box is used to contain the JLabel “Merchant” and a JTextField for the user to type in the merchant name. That horizontal Box is then added to the overall vertical Box. The “Amount” row is treated the same.

There’s yet another horizontal Box with a JLabel containing “Balance: $” and a second JLabel that has the balance of the category as a string displayed. Again, that horizontal Box is added to the overall vertical Box.

 

The “Add Transaction” JButton is in a horizontal Box of its own, which is added to the overall vertical

Box.

 

Finally, the “File” menu contains two items “Save Budget” and “Exit Program”.  The menu should use a standard JMenuBar, JMenu, and JMenuItems.

 

The Budget Data File

The budget data file will have a very specific format – as described above, it is ok for this project, to assume the data file is in the specified format – we are not expecting you to perform error checking to confirm the file format, etc.  The format will be exactly as follows:

 

<numCategories

<categoryName:<categoryBudgetAmount

<categoryName:<categoryBudgetAmount

… (repeated numCategories times)

<transactionCategory:<transactionMerchant:<transactionAmount

<transactionCategory:<transactionMerchant:<transactionAmount

… (repeated for as many transactions are stored)

 

For example, here’s a simple budget data file with only two categories and 2 transactions for each category:

 

2

Food:250.00

Entertainment:53.75

Food:Meijer:16.82

Entertainment:MJR:12.50

Entertainment:Metroparks:35.00

Food:McDonalds:6.54

 

Note that the categories will always be grouped first with the budgeted amount for each, and after that the transactions can be in any order.  How the transactions are grouped in the data file doesn’t matter, but you must make sure that the transaction order within a category is maintained. For example, in the above sample file, the Meijer transaction was input to the system before the McDonalds transaction, and the MJR was input before the Metroparks.  The ordering of transactions across categories does not matter (i.e. MJR may have come before Meijer, etc.) Depending on your data structure used, you may find it simplest to output all transactions for a given category (in the appropriate order) before you output the transactions from another category. For example, after you read in the above file, and the user adds another transaction in the Food category for 3.16, the resulting data file might be saved like this:

 

2

Entertainment:53.75

Food:250.00

Food:Meijer:16.82

Food:McDonalds:6.54

Food:McDonalds:3.16

Entertainment:MJR:12.50

Entertainment:Metroparks:35.00

 

Again, note that with the Food category, the $3.16 transaction comes last (because it was the most recent Food transaction entered) but it could potentially be listed before transactions of other categories.

 

Sample Run-Through

For this sample, the file “budgetData.txt” in the Java package folder contains the following:

 

3

Food:250.00

Entertainment:53.75

Rent:675.00

 

 

•   User starts the server (which waits for connection client).

•   User starts the client (which requests the server load the specified budget data file)

•   User is presented with the following client GUI:

 

•   Upon clicking the Category combo box, user sees:

 

•   When user selects a category (in this case, “Rent”), the Balance near the bottom shows the

current balance associated with the Rent category:

 

 User switches to “Food” category (balance updates to show balance for “Food”):

•   User enters data for a transaction at McDonalds for 6.39:

 

•   User clicks “Add Transaction” button (balance is updated, text fields are cleared):

 

•   User switches to Entertainment category:

 

•   User inputs data for a transaction in Entertainment:

 

•   User clicks “Add Transaction”:

 

•   User clicks “Food” category again:

 

•   Inputs transaction for Burger King for 8.05

 

Clicks “Add Transaction”:

 

•   User clicks “File” menu:

 

•   User clicks “Save Budget” item

 

•   User clicks “File” menu:

 

 User clicks “Exit Program”, and program ends.

 

After all this has occurred, the budgetData.txt file looks like this:

 

3

Entertainment:53.75

Food:250.0

Rent:675.0

Entertainment:Museum:25.0

Food:McDonalds:6.39

Food:Burger King:8.05

 

Since the file is saved on the server, the user could then start the program up again and the saved transactions would be loaded, and balances displayed in the GUI would be as they were when the last session ended.

 

Client Code

To test your code, we will run your server (it must be well named, like “SimpleBudgetServer” so we can easily determine which of your files is the server to run!), and then we will run a client of our own. The client main is exceptionally simple. A full client main, in SimpleBudgetClient.java is provided here:

 

package eecs285.proj4.morgana;

 

import javax.swing.JFrame;

 

public class SimpleBudgetClient

{

public static void main(String[] args)

{

SimpleBudgetFrame sbFrame;

 

sbFrame = new SimpleBudgetFrame("Simple Budget", "budgetData.txt");

sbFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

}

}

 

Your program MUST be able to run using a client exactly like this, as we will be using clients like this to test your program.  Notice that the first parameter to the SimpleBudgetFrame ctor is a String for the title of the window, and the second parameter is the name of the budget data file to use. We will definitely test your program with multiple clients (not concurrently) specifying different file names, so do not assume the name “budgetData.txt” anywhere in your code.