Perl

Homework 4

For this assignment, you will become intimitely familiar with Perl's system for modules and classes, as well as writing documentation and testing.

Description

You are to write two modules. The first is a class module that defines a Bank Account. The second will be a 'traditional' module that creates subroutines which will be used by your class.

A Bank Account has the following attributes: Account holder (first & last name), type (checking or savings), current balance.

A bank account can accept deposits, which increase the balance, and withdrawls, which decrease the balance. A balance can never be less than $0.00 (assume no overdraft protection on these accounts). The name of the account holder can change, but a savings account can never become a checking account, nor vice-versa

If a user attempts to withdraw more than the account balance, reject the transaction - do not withdraw anything.

Deposits can be made either by calling a method explicitly, or by simply adding an amount to an existing object. Likewise, withdrawls can be made either with a method call, or by subtracting an amount from an existing object. (Creating a new object from an existing one via an addition or subtraction is not required). See the sample main program for examples.

Your account must keep track of its history. That is, it must keep a record of when all transactions (deposits and withdrawls) were made, and in what amounts. When the account's history is queried, you should print a list of all transactions - the transaction number, original balance, amount of deposit or withdrawl, and new balance. For example:

# | Original | Amount | New
--+----------+--------+-------
1 |     0.00 |  50.32 |  50.32
2 |    50.32 | -20.00 |  30.32
3 |    30.32 | 143.20 | 173.52

(You may find the printf and sprintf functions very helpful for creating this list. Read about them using perldoc -f sprintf.)

An account can also report a limited number of statistics: The average withdrawl amount from a certain range of transactions and the average deposit amount from a certain range of transactions.

To help implement these last two methods, you will write a helper module that defines two subroutines. The first subroutine will take a list of amounts, and return the average of all amounts that are less than 0. The second will take a list of amounts and return the average of all amounts that are greater than zero.

These subroutines will be defined in your helper module. Your class module will use this module and access those subroutines (in whatever way you deem most appropriate). Remember that these are utility functions. They are not specific to bank accounts. They are generic subroutines you're writing for general use - that just so happen to be useful to your Bank Account class.

You will need to write a test suite for each module. The test files should test all features of each module. Remember especially to test "edge" cases, and test that your module deals with incorrect data appropriately. It may, in fact, be a good idea to write the test files first, and then to continually test the modules as you develop, to see what tests you've not yet completed correctly.

Both modules should be fully documented, using POD. I should be able to see full documentation for each module, including its purpose, description, synopsis, and brief description of each subroutine or method.

Notes

• I will be posting a sample main program that uses your BankAccount class. Make sure you define methods that my main program uses, and name them correctly.
• When naming your modules, the class module should be Rcsid::BankAccount, and the helper module should be Rcsid::Averages. (For example, my modules will be Lallip::BankAccount and Lallip::Averages)
• Make sure you use Carp; and use carp() to tell the user they've done something wrong, like trying to withdraw more than they're allowed.
• Any submission that does not follow these specifications - that is, that does not create and properly use the two modules - will earn a 0 grade.

Grading Criteria

Compilation

Points are deducted for any warning messages your code produces. Note that warnings will be enabled when we run your program, regardless of whether or not you've enabled warnings within the code.

As a reminder, while use strict; is not a requirement for the homework, it is a very strong suggestion (also keep in mind that it is required before emailing for help.)

If your code produces compilation errors, you will lose all the points for compilation, and the remainder of your program will be graded subjectively based on the code you've written itself. You should never submit code that does not compile.

Error Checking

You should always error check anything done by the user. Warn the user when he/she does something wrong. Please make sure to properly use Carp; and it's carp() subroutine. Anything your module does wrong should be notified with 'warn'. Anything the user does wrong in using your module should be notified with 'carp'.

Output Style

Output, in this case, refers to all prompts and information printed to the user. In general, output should be well formatted and clearly identifiable. All output on one single line is bad. The raw data, without being labeled, is also bad. If it hurts my (or the TA's) eyes to look at, it's bad.

Code Style

All code that you write should be well styled. Most important are three features: A consistent and helpful indentation scheme; Meaningful variable names; explanatory but not over-abundant comments.

For examples of well-styled code, please see perldoc perlstyle

Supplemental Files

The main homework page will soon have a sample main file which to use your class file, a transcript of a sample runthrough of the program, and a Frequently Asked Questions page.

Submission Instructions

This homework is due Tuesday, Nov 1, 2005 at 11:59:59pm. As a reminder, your program must be functional on the machine rcs-sun4.rpi.edu. Make sure you follow the procedure documented in the 2nd Object Oriented Programming lecture to create two tarballs, one for each module. To submit your homework, log in to rcs-sun4.rpi.edu, and run the program:
~lallip/public/hw_submit4.pl
Follow the prompts. You will receive an email confirmation of your submission. If anything goes wrong, please email Paul at lallip@cs.rpi.edu ASAP.

Remember that you may submit infinite times. Only the last homework submission will be looked at.

You may submit by Wednesday, Nov 2, 2005 for a deduction of 20 points