JDEP 183H

Fall 2006

Homework Assignment 3: Help Me Balance My Account!

Assigned: October 3, 2006

Due: October 26, 2006

Note: This assignment is to be completed individually - collaboration is strictly prohibited.

Points: 100 points

Objectives

The objectives of this homework assignment:

1. Understand basic GUI objects

2. Understand the relationships between an object and its GUI frontend

3. Write a GUI application

a. Identify the GUI objects that are necessary for the application

b. Organize the positions and functions of these GUI objects for the application

c. Design the application such that the user interface is sensible and user-friendly

d. Design the application such that the user interface is robust and can recover from errant response from the user

4. Make use of event-driven programming to replace while loops

a. Learn how Java’s delegation-based event model allows a GUI application to be always ready to receive the next user input

5. Become familiar with use exception-handling

6. Become familiar with encapsulation, one of the four pillars in Object-Oriented Programming

7. Become familiar with program upgrading

a. Create a GUI version of a text-based application

8. Become familiar with the javax.swing package

9. Become familiar with code documentation, compilation, and execution

10. Expose to Java syntax, programming styles, and Java classes

Problem Description

Impressed by your prototyping of the Profit Advising System (PAS), ABC has decided to give you a more ambitious task: a GUI-based accounting system. They want the GUI system as users of PAS have expressed that they would rather point-and-click than type-and-type-and-type. Having gained enough experience, ABC has specific requirements for this system: Transaction and Account Balance Reporting System (TABRS).

Basically, TABRS will allow the user to post four simple transactions and then create a trial balance based on a set of transactions. It uses a GUI interface to select and input transactions, and then to show the resulting trial balance. Figure 1 shows a very basic diagram flow of what ABC has in mind:

Figure 1. Flow of the GUI component of TABRS.

For the first GUI panel, “Welcome & Main Menu”, it should have the following two groups of buttons that allow the user to choose specific actions.

The first group consists of the “Transaction Reporting” buttons:

(1) Make a sale, receiving some combination of cash and account payable;

(2) Receive a payment on an account receivable using cash;

(3) Make a payment on an account payable using cash;

(4) Buy supplies, using a combination of cash and account payable.

The second group consists of the “Account Balancing” buttons and a “Quit” button:

(5) Prepare a trial balance;

(6) Save the trial balance;

(7) Quit.

Each button, except for the “Quit” button that simply closes the “Welcome & Main Menu” panel, will trigger the display of a specific GUI panel or window. See the appendix for what each choice leads to.

You know what this TABRS is supposed to do. But how are you going to implement it? Once again, the solution has to be object-oriented as it is expected that further modifications and extensions will be made to your solution. And, the first question that comes to mind is: what are the objects of importance? There has to be an application class called TABRS. And this class also has a GUI frontend. What are the other objects that TABRS will have to manipulate? Transactions? Accounts? Which are more relevant? What’s the output that the user wants? The transactions or the accounts? In this case, it seems that the accounts are more important.

Thus, maybe one should create a basic class that captures the attributes and functions that one can do with an account: Account.class. This class should have at least the following attributes: name, number, creditOrDebitType, and balance, and have at least the following methods: modifyBalance() and printBalance(). (Hmm … think about what these attributes and methods are supposed to do.) Ah ha! Equipped with this basic class, the TRABS application class can instantiate five types of accounts: cash, supplies, accountPayable, accountReceivable, and salesRevenue. Each can now be responsible for safeguarding itself as a unique account type. (Hint: Encapsulation!)

You still need some GUI or application classes for transaction and account balance reporting, that will also modify or access these Account objects. Each class has a GUI frontend, processes user entry, performs some computations, and updates or accesses the relevant Account objects. (Hmm … how can these relevant Account objects be updated or accessed elegantly – in an object-oriented manner?)

Finally, you will need to use exception-handling when processing content entry (especially dealing with non-numeric values).

Challenge - Extra Credit (10 points)

For extra credit, you have a neat idea: in addition to saving the balance sheet, you also want to log every action that takes place during the user session of the system. (A log file is very useful and important in programming for debugging, testing, and validation.) The format of this log file should look like this:

<Account#>,<Account Name>,<$Credit>,<$Debit>

...

<Account#>,<Account Name>,<$Credit>,<$Debit>

...

...

<$CreditTotal>,<$DebitTotal>

Note that <Action Name> refers to one of the seven choices on the main menu. For each of the “Transaction Reporting” actions, account information should follow. For “Prepare a trial balance”, “Save a trial balance”, and “Quit”, the balance sheet, credit, debit, and message should follow. (Hint: To do this extra credit well, think about encapsulation and how one can make use of methods already implemented.)

Submission Procedure

This assignment is due on October 26th, 2006 at the start of class (12:30 PM). Assignments five minutes late will NOT be accepted. It is highly recommended that you read the grading policy and grading guidelines on the course website for a complete explanation of how the assignments will be graded. Remember, your program should follow a good programming style, include plenty of comments – both inline documentation and Javadoc documentation, and perform all of the functionality outlined above. Also, in the welcome message of your program, state whether you are implementing the extra credit functionality.

There are two submission steps:

(1) You must “handin” the following files on-line:

1. Source files: TABRS.java Account.java *.java

2. Compiled files: TABRS.class Account.class *.class

3. Readme file: README

4. Testing file: Screenshots of all GUI windows, output file of a trial balance

(2) You must submit a stapled paper copy of a coversheet, your source files, the README file, and all the testing files.

Both of these steps must be done by the start of the class on the day the assignment is due. Please download this coversheet from the instructor’s course website, under the Homework Assignments link. This coversheet allows the grader to give comments and categorize the points for your homework.

APPENDIX: SPECIFICATION FOR TABRS

(1) When the user chooses to “Make a sale”, the following GUI panel should appear:

				Account	Debit	Credit
Date	Cash			100	$$1
	Account Receivable			110	$$2
		Sales Revenue		410		=$$1+$$2
			Make a Sale

The user will need to enter the Date, enter a value for Cash or Account Receivable or both, and TABRS will compute the Sales Revenue automatically for the user. (See the above equation.)

(2) When the user chooses to “Make a payment”, the following GUI panel should appear:

			Account	Debit	Credit
Date	Account Payable		210	$$1
		Cash	100		=$$1
		Make a Payment

The user will need to enter the Date, enter a value for Account Payable, and TABRS will compute Cash automatically for the user. (See the above equation.)

(3) When the user chooses to “Receive payment”, the following GUI panel should appear:

				Account	Debit	Credit
Date	Cash			100	$$1
		Account Receivable		110		=$$1
			Receive Payment on Account Payable

The user will need to enter the Date, enter a value for Cash, and TABRS will compute Account Receivable automatically for the user. (See the above equation.)

(4) When the user chooses to “Buy supplies”, the following GUI panel should appear:

					Account	Debit	Credit
Date	Supplies				130	$$1
		Cash			110		$$2
			Account Payable		210		=$$1-$$2
				Buy Supplies

The user will need to enter the Date, enter values for Supplies and Cash, and TABRS will compute Account Payable automatically for the user. (See the above equation.)

(5) When the user chooses to “Prepare a trial balance”, a GUI panel should appear that uses all transactions so far to create an accounting trial balance. There are five types of accounts:

Account Name	Account Number
Cash	111
Account Receivable	112
Supplies	131
Account Payable	211
Sales Revenue	411

Your trial balance should use the standard format as shown in (Needles et al. 2005, pp. 61-63).

Your GUI should also include a message telling the user that debits and credits either match or do not match.

(6) When the user chooses to “Save a trial balance”, then TABRS saves the accounts, the balance, and the message to an external text file. Here is the format, a variant of the Comma Separated Value (CSV) file format:

<Account#>,<Account Name>,<$Credit>,<$Debit>

<$CreditTotal>,<$DebitTotal>

In this prototype, there are only five accounts as listed in the above table.

(7) When the user chooses to “Quit”, TABRS will automatically save the current trial balance, and then close the “Welcome & Main Menu” window.

You are allowed to deviate from the above design or flow as long as all the required elements are included in your design.

Also, for each specific GUI panel, it must have a button that allows the user to close the panel and go back to the “Welcome & Main Menu” window.

References

Needles, B. E., Jr., M. Powers, and S. V. Crosson (2005). Principles of Accounting, Boston: Houghton Mifflin.