CS 280 Spring 2009 Assignment 11 – Arrays and Classes and Loops and Everything Else 100 “Assignment” points

Assigned: 04/22/2009

Due: 04/30/2009 at the start of class - NOTE – that’s the day of the lab exam, so you don’t really want to be working on this right up to the deadline.

Pre-Lab (Do Before Lab): Read the assignment. Bring materials – a USB for a take home copy. Download and unzip the code that I’m providing. Look at Javadoc documentation to try to understand the methods that I’m asking you to provide as well as those that are already provided.

Main Assignment:

You are writing some parts of an EZ Pass (simplified demo) program. We are still quite a ways away from being able to do the whole job, so please pay attention to what I’m asking for (clearly, we are not scanning transmitters for who is driving through where). Your job is to 1) Add to the EzPassCustomer class as described below (and in Javadoc documentation); 2) Add to the GUI class as described below. These are provided in a zip file on Blackboard. The zip also includes the javadoc generated html documentation for the classes. NOTE first that we are producing an EzPassCustomer class with the idea of possible future re-use. Hence, there is code that may not be used in the current GUI. Try to rig up ways to test that code. NOTE second that because of code that you are going to write, some current code has red squigglies on it as downloaded.

Things You Should Already Know::

· Do your own assignments !!!! Work that is copied or done with somebody (when not assigned to a group) will be punished. If programs are copied, both students will receive a zero for the assignment. If significant sections of programs are copied, points will be taken off. Changing small aspects of a copied program does not make it not a copy. Asking another for help on a step or two in a many-step assignment is acceptable; looking at another person’s program is temptation for cheating; handing in a near duplicate program is cheating

· Instance variables are the data that has one value for each object created using the class as a blueprint.

· Constructors handle the details of instantiating objects of a class. They MUST have the same name as the class. They never have a return type. They should ensure that instance variables have values. They should not let these values be unreasonable or illegal.

· Inspectors report the value of an instance variable. They do not need to have anything passed in to them as parameters (and SHOULD NOT). Their return type should correspond with the type of the instance variable (but see pseudo inspector). Their name should start with “get” and really ought to use the instance variable name (e.g. to report the value of the instance variable balance, the inspector method should be getBalance).

· Pseudo – inspectors look like inspectors but are reporting something that is not directly stored as an instance variable. Thus, they do not need to have anything passed in to them as parameters (and SHOULD NOT). Their name should start with “get” and should describe what it is that they are reporting.

· Simple Mutators are responsible for changing the value of an instance variable. They NEED an appropriate type of data to be passed to them as a parameter. If it is possible to validate (check for reasonableness / legality) the passed value, it should be checked, and the mutator should return a boolean as to whether it was successful or not. Their name should start with “set” and really ought to use the instance variable name (e.g. to change the value of the instance variable year, the mutator method should be setYear). Sometimes, we want to have more control over the instance variable so as to only allow certain kinds of changes to the value (e.g. balances should generally be adjusted up or down from their current value rather than being allowed to be set to just any value). In those cases, we might provide what I call “Controlled Mutator”s instead of simple mutators.

· Controlled Mutators generally are NOT named setInstanceVariable, but are named to describe what they do.

· toString is an important method that should probably be supplied as part of every class you ever write. It’s name is very important; a method with a different name that performs the same task is NOT a suitable substitute because there are specific things done based on toString.

· The Javadoc utility semi-automatically generates documentation for a class – by processing specific comments – those that start with /** and end with */ and are immediately before methods. Each and every method that you write (except probably GUI event handling methods) should have such a comment!

Task Requirements:

Your EzPassCustomer class has its instance variables declared already. These include an cust ID that uses the provided ID class, a name, a current balance, a replenishment amount, and a Boolean indicating whether they are a credit card customer or not (vs paying by check). Some methods are already provided. You need to add:

· 3 constructors –

o one that is passed the customer’s name and replenishment amount (see background knowledge);

o one that is passed the customer’s name, replenishment amount, and whether they are a credit card customer

o one that is passed the customer’s name, replenishment amount, whether they are a credit card customer, and their current balance

· Simple inspectors for 3 instance variables (the others are already included) – balance, replenishment amount, and whether they are a credit card customer.

· Simple mutator for all 1 instance variable: replenishment amount (the others are already included). It should check the passed value, and if valid set the appropriate instance variable to the passed value and return true (return false if invalid). Valid values for instance variables are discussed in the Background Knowledge section.

· Two controlled mutators to change the balance –

o Replenish the account with money using the account’s replenishment amount

o Accept payment from the customer - passed an amount, if the amount is positive, increases the amount of money in the account. Returns false if passed an invalid amount.

· A toString method that turns a EzPsssCustomer into a reasonable String representation of a EzPsssCustomer.

· A toShortString method that turns an EzPassCustomer into a shorter String representation including only the ID and name. Existing code is counting on this method!!

· A compareTo method that compares two EzPassCustomers based on their balance. It needs to be passed and Object that can be converted into a EzPassCustomer. If the passed customer is less than the invoking customer, the method should return a positive integer. If the passed customer is greater, the method should return a negative integer. If they are equal, the method should return zero. This is used by general sorting methods, and it MUST be named compareTo.

The GUI class is also partially written. It needs:

· A declaration and instantiation of the array of customers as an instance variable in the GUI class. Other code assumes that it is named customerList. You can assume that we will not have more than 100 customers in this demo.

· A method named loadCustomerComboAndArrayFromFile. You’ve done something very similar to this (with ArrayLists instead) in the past. A file named custlist.txt should be in the project folder and should be appropriate for the task. Call this method upon start up (after GUI components are initialized) so that no buttons need to be clicked in order for customer info to be available.

· A method to obtain a String representation of the whole group of current customers. Mine was called allCustomersToString.

· Code for the combobox which upon the selection of a new item in the combobox finds the appropriate customer in the array (setting the global instance variable named currentCust in the GUI class) and refreshes the customer info in the GUI. It is important that the currentCust is set so that all of the buttons in the GUI do not have to repeat the same code. The header to the method already exists.

· Code to handle the Ave button (only seen in the Startup screen shot). It should calculate and display the average account balance across all real customers.

· Code to handle the Bridge button. All bridges cost the same - $4.00 (a constant is provided). A lot of support for this is provided in the EzPassCustomer class. My code has 6 lines not counting curly braces and comments. If you’re thinking about a lot of complicated code, you’re not thinking about letting the EzPassCustomer class do a lot of the work for you. Don’t even think about using setBalance; it is way too primitive. The customer to be updated should be known via the currentCust gui instance variable if you have done all of your tasks correctly.

User Interface:

· You can fiddle with the interface. I know that my interface can be improved upon!!! However, it is not really part of your task here. Some pictures (“screen shots”) illustrating the program in action are shown below. The version of the assignment on my www site includes more pictures. The version on Blackboard may not include any.

· Add your name to the label or the title bar on the GUI form

Background Knowledge:

Customers have a balance – which is money that they have put in their EzPass account to pay for future tolls (i.e. it is “stored value”; the customer generally does not “owe” EzPass anything for the past except when occasionally their balance goes below zero.
Each time a customer goes through a paying tool booth (at a bridge or when exiting a turnpike) money is to be deducted from their account (i.e. the balance is reduced).
When the customer’s balance goes below a certain point, it is in need of “replenishment”. Each customer has a “replenishment amount” which is the amount that is to be added to their balance.
For credit card customers, the replenishment amount is automatically added to their balance (and paid for by their credit card (outside our current demo)). In this particular demo, this happens when their balance goes below zero.
Non credit card customers pay by check, so are a little bit more iffy for the EzPass organization. Hence, if a non credit card customer goes below zero balance they are charged a fee (currently $10.00). The balance DOES go below zero, so that we don’t lose track of the fact that money is owed.
Currently the charge for all bridges is $4.00.
Valid values related to EzPass:

Balance – initial balance (constructor) and simple mutator should ensure that it is never negative. Controlled mutators should allow negatives if they happen
Replenishment amount – should always be positive
Turnpike tolls – $0.25à $25.00 valid
Score – 0-30000
Level Reached – 0-10

Miscellaneous Details:

Random custIDs can (and SHOULD) be generated. The customer ids seen in the GUI example WILL NOT be the same ones you get.

Documentation should be available on the EzPassCustomer and ID classes. Make sure you read it. It is provided as Javadoc documents, which are html files that can be found inside the project folder included in the zip. The javadoc includes methods that I’ve written, methods I’m asking you to write, and perhaps some that I was going to ask you to write but decided to skip.
You probably have to get reading from a file to work before you can test any other part of your program.
The file contains one line for every customer. If you read in a line at a time (as done in the past), you are well on your way to creating the array of customers. There is an EzPassCustomer constructor that will be very valuable for creating an EzPassCustomer object. Adding customer objects to an array is the main new challenge here.
In reading the file, catch exceptions involving the file not being found and display a message (as done in class and on assignment 8). A data file will be available on Blackboard and my www site. It is (obviously) shorter than real life data and is made up data. Any file with the same format (name, balance, replenishment amount, Y/N indicating credit card or not should work.
The decrease balance method throws an InsufficientFundsNonCreditException exception if a non-credit card customer goes below zero balance. You need to handle there when you encounter it. (A message to the user would be sufficient since we don’t have billing capabilities. Don’t call it quits on the program!
All changes to the current customer’s info should be reflected both in the actual customer object AND in the GUI. The GUI class has a handy method to refresh the GUI based on the object. It should NEVER happen that the GUI values are updated without a change in the correct object.
Don’t try to calculate anything if the inputs are bad (i.e. turnpike tolls) – only display a message and let the user back into control.
If the user enters letters instead of numbers in numeric text fields, the parse commands will cause a NumberFormatException. Let’s catch this - . display a message and let the user back into control. (NOTE also that no entry in a text field is like having non-numeric).
In working through arrays (in general), loops tend to be handy. For loops tend to be handiest. Foreach loops, not so much.

Good Programming Practices:

o MAKE SURE YOUR PROGRAM WORKS! (i.e. gets correct results). It must provide all of the requested capabilities AND provide them in the expected way.

o We are now branching – so the program must be tested on more inputs to ensure that all paths through the program code work!

· Add YOUR NAME, e-mail address, and purpose of the program in comments at the beginning of files that you edit. (the date should already be there – which is also a very good practice). The purpose should be what the program is supposed to do, not the learning goals.

· Name all variables and constants meaningfully.

· I have define numbers (especially those that could change sometime in the future) as named constants. You should generally use these instead of the number itself. Hence, if the number ever changes, it can be changed in the one place without searching throughout the project.

· Indent to show any structure of the program (The IDE usually does this well if you don’t go back and change things – probably not much to worry about on this basic of a program)

o You MUST include some comments that explain your program in order to get full credit; any complexity should have comments – if you had to stop and think about how to do something, it needs a comment.

Red Tape to Aid Grading:

· Please set the name of the project to something other than the default name (JavaApplication1, …).

· Add your name in a jlabel on the GUI form or on the title bar.

Name your zip file so that it identifies you as well as the assignment (e.g. yourlastname assignment11.zip). This is very important for my grading!!!!

Hand in:

Compressed (zipped) folder with your entire assignment containing all files related to the assignment, including your code and mine – including the ID class – submitted to Blackboard. Please submit one zip file.
Printed copy of your code – To get just that, paste into Word, WordPad, NotePad etc. Please don’t double space. If you have NetBeans 6.5, there is a Print Option checkbox to only print selected code.

On Startup: