Course Home | Homework | Programming | Schedule & Lecture Notes | Submit

Saint Louis University

Computer Science 180
Data Structures

Michael Goldwasser

Spring 2006

Dept. of Math & Computer Science

Programming Assignment 01

Due: Monday, 30 January 2006, 8pm

Please make sure you adhere to the policies on academic integrity.

Please see the general programming webpage for details about the programming environment for this course, guidelines for programming style, and details on electronic submission of assignments.

The files you may need for this assignment can be downloaded here.


Contents:


Collaboration Policy

For this assignment, you are allowed to work with one other student if you wish (in fact, we suggest that you do so). If any student wishes to have a partner but has not been able to locate one, please let the instructor know so that we can match up partners.

Please make sure you adhere to the policies on academic integrity in this regard.


Overview

Chapter 1.6 of the text introduce an example of a credit card class, giving the class definition in Code Fragments 1.5-1.6, and giving a sample test program in Code Fragment 1.7.

For this assignment, we will use that class as our model, however our goal is to adapt it to meet new specifications which more accurately model typical credit card terms. In particular we will introduce a monthly interest calculation, a minimum monthly payment, and a penalty for a late payment. Precise details are in the coming section.


New Specifications

Meeting the formal specifications is an important aspect of programming. For this reason, please make sure that you carefully read and follow the specifications outlined in this section when designing your program. If you feel that there are any ambiguities, ask for clarification before completing the assignment.

At minimum, the state information for a credit card should include the following:

All of your member data should be declared as private, and you are free to make your own personal design decisions in representing the necessary state information as you see fit.

The public member functions must include each of the following. We describe each giving the formal prototype (i.e., parameters and return types) as well as a prose description of the expected behavior.


An example

As an example, assume a new card is created with zero balance and 0.79% monthly interest (approximately 9.5% per year). During the first month,charges of $25, $500 and $100 are made to the card. When endOfMonth() is called, no late charge or interest charge should be incurred, because there was no minimum payment or balance as of the beginning of the month. However at this time, the current balance of $625 and a minimum payment of $31 is recorded.

Continuing, lets assume that the next month includes new charges totaling $228, and payments totaling $300. If endOfMonth() is again called, the processing should be handled as follows. The received payments of $300 surpass the minimum monthly requirement of $31, so no late charge is assessed. However, the $300 does not constitute payment in full against the previous monthly balance of $625. Therefore interest will be computed based on the current balance which is $553 ($625+$228-$300). At the specified rate, an interest charge of $4.37 is added to the balance, resulting in an end of the month balance of $557.37, and an associated minimum monthly payment of $28.

In the next month, assume that charges of $300 are incurred, and a payment of $600 is received. In this case, at the end of the month, no late fees or interest are charged, because the payment of $600 exceeds the previous month's balance of $557.37. At this point the updated balance of $257.37 ($557.37+$300-$600) is recorded, along with a minimum monthly payment of $30.

In the next month, assume that there is no activity on the card. Because there is an unpaid balance of $257.37, an interest charge of $2.03 is added to the balance. Worse yet, because not even the minimum payment from the previous statement was paid, a late charge of $20 is added to the balance. Therefore the new balance is $279.40. The minimum payment assigned for the subsequent month is again $30.


Testing your Credit Card class

The text demonstrated the functionality of their original credit card class by means of a Test program shown in Code Fragment 1.7. That program is somewhat bizarre in nature and we suggest that you scrap the whole thing and start anew.

For this assignment, we wish to have you submit your own version of such a test program. In particular, please make sure that you demonstrate those areas of additional functionality which go above and beyond the original credit card class given in the text (e.g., monthly statements, penalties, etc). You might start by trying to script the example given above. Yet you should go on to add additional such tests (as we will certainly do when we grade your program!)

As an example, here is a simple test program which simulates the first two months of activity as described in this handout. Ideally, you might start with that file and then expand upon the test to show more scenarios which might arise.


Submitting Your Assignment

Please see details regarding the submission process from the general programming web page, as well as a discussion of the late policy.

You should submit four files:


Files you may Need

You may wish to use the code from the book as your original model. For your convenience, we will provide those original files as well as a makefile for compiling the project.


Grading Standards

The assignment is worth 10 points. Eight points will be awarded based on our own evaluation of your assignment and the readme file. One additional point will be awarded fractionally based on how well your program performs on other students' test inputs. The final point will be awarded fractionally based on how well your test input fools other students' flawed programs.

Extra Credit (1 point)

Preface: If you are going to attempt the extra credit challenge, please first complete and submit the required class, CreditCard. Then copy and rename those files to define a new class CreditCardExtra for this challenge. (we want to make sure to avoid penalizing your original submission because of mistakes incurred in attempting the extra credit.)

Based on the above assignment specifications, a credit card owner was receiving what is known as a grace period. That is, purchases could be charged to the card, yet the debt was interest-free until the end of the month. In fact, if the previous monthly balance was paid in full before the end of the next month, no interest charges were incurred.

For extra credit, we would like to take away such a grace period for users who do not pay off their balance in full. In particular, once a month ends with a non-zero balance, interest computation should be performed daily (at 1/30 of the monthly interest rate) rather than monthly. The daily computation of interest should continue until a point in time when a user's balance reaches zero. At this point, the grace period policy should be reinstated, reverting to interest computations at the end of the month.

Implement this new specification, adding a new method, void endOfDay(), which is presumably called at the end of each day. Please keep in mind that the system is presumed to still call endOfMonth() at normal increments as well. You must not double-charge interest; that is, if you have been charging daily interest on a balance, there should not be any additional interest at the end of the month (though late fees may still apply).


Michael Goldwasser
CSCI 180, Spring 2006
Last modified: Saturday, 04 February 2006
Course Home | Homework | Programming | Schedule & Lecture Notes | Submit