Saint Louis University |
Computer Science 180
|
Dept. of Math & Computer Science |
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.
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.
Chapter 1.6 of the text introduces an example of a credit card class. We will use that class as a model for that assignment, but we are making some adaptions and adding additional functionality. In particular, we will introduce bookkeeping for a typical monthly cycle.
Meeting formal specifications is a vital aspect of programming. The public interface for a class serves as a contract for coordination between the implementor of the class (in this case, you) and the users of that class (in this case, you and the rest of the class). As part of this assignment, we are providing a header file, CreditCard.h, which defines the public interface for the CreditCard class. This includes signatures for the required public member functions. Formal documentation has been embedded in the source code and is viewable here. 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.
A CreditCard instance manages aspects of a typical credit card account. Some of the functionality is rather basic, for example keeping track of the owner's name, the card number, the credit limit. There must also be basic support for managing the up-to-the-minute balance on the account, including allowing for the customer to make charges against the card (though not exceeding the limit) and making payments to pay off some portion of the current balance.
The most challenging aspect of our specification is that your class must also manage the typical monthly cycle for a credit card. A customer can stay in good grace each month by paying the full balance as it existed at the time of the most recent formal statement. (even if new charges this month means that the current balance is non-zero). A good customer is never charged interest or fees. However, additional charges are accrued when that previous balance is not paid off. In particular, once a customer loses good graces, interest is charged on the entire current balance (old charges and new charges). Furthermore, if the customer did not even meet the minimum payment schedule established by the company, an additional late fee is assessed.
More formally, a processMonth method will be triggered at the end of each hypothetical month. The responsibility of that method is to calculate appropriate interest and fees and to recalculate a minimum payment for the coming month. The formal rules are as follows.
The process is based upon the balance and minimum payment that had been recorded at the conclusion of the most recent call to processMonth (these figures are assumed to be $0 if this is the customer's first month with the card). The updated balance and minimum payment should be computed as follows:
If payments received this month did not meet or exceed
the balance on record at the conclusion of the most recent
call to processMonth, an interest charge
of
If payments received this month do not meet or exceed the minimum monthly payment on record at the conclusion of the most recent call to processMonth, an additional late charge of $20 should be added to the balance.
This updated balance becomes the current balance, but is also recorded as the offical "statement" balance, for future reference.
If the new balance is non-zero, a minimum monthly payment should be calculated and recorded. Generally, the minimum payment will be the larger of $30 or 5% of the new balance (rounded to the nearest dollar). However, we cannot demand a minimum payment that is greater than the balance. If the above calculation were greater than the current balance, the minimum payment should be set to the full balance (unless, of course, the current balance is negative, in which case a minimum payment of $0 should be assigned).
The official set of public methods which must be supported is as follows:
The constructor has the following signature
CreditCard(string no, string nm, int lim, double rate, int bal=0)
Although not explicit in the documentation, you may assume that the rate parameter is nonnegative.
Although your class may have other private attributes in addition to those listed as parameters, all others attributes should have initial values that are not directly customizable. For example, the minimum required payment for the first month of a new card is automatically zero (even with a non-zero starting balance).
There are seven standard accessor functions to return the values of respective aspects of the underlying state. Those signatures are:
string getNumber() const
Though we talk about the 16-digit "credit card number", we
represent this as a string, because it is too large to represent
numerically.
string getName() const
Customer's name.
int getLimit() const
Reports the card's credit limit (expressed in dollars).
Note, however, that interest charges may actually cause
a balance to rise above this limit.
double getRate() const
Montly interest rate. Represented as a floating-point number
rather than as a percentage. (e.g., an interest rate of .01
represents 1% per month)
int getCurrentBalance() const
This reports the up-to-the-minute balance on the account
(measured in cents).
int getStatementBalance() const
This reports the balance (measured in cents) that had been recorded at the
conclusion of the most recent call to processMonth
This is significant, as it affects the rules for interest
charges and late fees.
int getMinPayment() const
This should be the minimum payment (measured in cents) that was
recorded at the
conclusion of the most recent call to processMonth
This is significant to the customer when making payments to
avoid subsequent late fees.
bool chargeIt(int price)
This is called when the card owner attempts to make a purchase
for the given price (measured in cents). The charge should only be approved if the
resulting balance were to remain at or below the user's credit
limit. The return value should be true if the charge
is being accepted and false if rejected.
You should refuse charges for a negative amount.
void makePayment(int payment)
This is called when the card owner submits the specified
payment (measured in cents).
Negative payments should be ignored.
Assuming the payment is positive, the customer's current
balance should be reduced to reflect the payment.
int processMonth()
This is the method which is responsible for the end-of-month
bookkeeping, as explained in detail above. The updated balance
and new minimum payment should be recorded internally for future
reference. In addition, the new minimum payment should be
returned to the caller (measured in cents).
Note Well: None of your methods should generate any output. We have provided an implementation already for the output stream operator (<<) and the user of a credit card can print their own information based on values returned by the standard accessors.
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 $325.75, $800 and $100 are made to the card. When processMonth() 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 $1225.75 and a minimum payment of $61 is recorded.
Continuing, lets assume that the next month includes new charges
totaling $228, and payments totaling $300. If processMonth()
is again called, the processing should be handled as follows. The
received payments of $300 surpass the minimum monthly requirement of
$61, so no late charge is assessed. However, the $300 does not
constitute payment in full against the previous monthly balance of
$1225.75. Therefore interest will be computed based on the current
balance which is
In the third month, assume that there is no activity on the card. Because there is an unpaid balance of $1162.86, an interest charge of $9.19 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 $1192.05. The minimum payment assigned for the subsequent month is $60.
In the fourth month, the customer starts by making a payment of $400. At that point in time, a query of the current account balance reports $792.05, although a query of the statement account balance remains at $1192.05. Next, the customer makes a purchase of $500, but later sends a payment of another $800. At the end of the month, no late fees or interest are charged, because the payments of $1200 exceeds the previous month's balance of $1192.05. At this point the updated balance of $492.05 ($1192.05 - $1200 + $500) is recorded, along with a minimum monthly payment of $30.
In the fifth month, the customer makes a payment of $475 and does not charge any purchase. Because there is an unpaid balance of $17.05, an interest charge of $0.13 is added to the balance. Therefore the new balance is $17.18 and the minimum payment assigned for the subsequent month is also $17.18.
Thus far, we have given a clear explanation of the public semantics of the class, and examples of several scenarios. However we have said nothing at all about how you are to implement this. Based on the concept of encapsulation, it is up to you how to accomplish this.
You may feel free to add any private members to the original definition in CreditCard.h. Clearly, some basic attributes will be necessary to store the information needed for the standard accessor methods. However you will likely need to store additional internal information to properly support the specifications.
We strongly suggest that you think a bit about your design before getting too far into your implementation.
You must be very careful in respecting the specifications regarding values that are to be stored or computed when measured in cents or dollars. Note that we intentionally store balances as an integer number of cents, rather than as a floating-point with fractional portion of a dollar.
In C++, when you perform arithmetic that involves one integer operatnd and one floating-point operand, the result is a floating-point. If a floating-point is assigned back to an integer variable, or explicitly cast with a syntax such as, (int) val, the value is truncated. For example, (int) 3.99, results in the value 3. If the goal is to round a floating-point value to the nearest integer, a typical strategy is to compute an expression such as, (int) (val + 0.5); note that if val has a fractional portion of 0.5 or greater, than (val + 0.5) will reach the next integer value.
For this assignment, we wish to have you submit your own version of a test program which utilizes the CreditCard class. Your test may only use the public behaviors which have been defined for this assignment. As part of the assignment, we will attempt to run your test program on everyone's CreditCard implementation as well as your CreditCard implementation on everyone's test program. Out of fairness, we will limit the testing to the first 100 method calls.
To get you going, we provide an initial implementation of Test_CreditCard.cpp which simulates the five months of activity as described in the above example. However, you should go on to add additional such tests. Those five months do not demonstrate a complete set of scenarios which may arise. We will certainly test more possibilities when we grade your program!
Rather than have the entire project in a single file, we would like to shift to a more standard development practice where components of a program are stored in a combination of different files which support better reuse of components. Please read Chapter 1.6 of our text for a discussion of this breakdown.
For this assignment, we are providing four files. These can either be downloaded from this website, or copied directly into your account on turing, with the command
cp -R /public/goldwasser/180/programs/credit .
The files are:
CreditCard.h - The header file which contains the class definition.
CreditCard.cpp - A file that should provide the bodies of the functions that were declared in CreditCard.h.
Test_CreditCard.cpp - A file which serves as a main driver for testing the credit card.
makefile - A makefile is a special configuration file which can help when trying to compile large projects with multiple pieces of source code. Rather than invoking the compiler directly, you should be able to build an executable for this project by typing the simple command,
make
Please see details regarding the submission process from the general programming web page, as well as a discussion of the late policy.
Because this is a pair assignment, you should abide by the following procedures:
Both members of the pair should submit a readme file (plain text format). This provides a way for you to add any further comments you wish to make to the grader. In the case of a pair assignment, please give a brief overview of the breakdown of work and describe your personal role in the development of the submitted work.
In addition, one member of the team should submit the three source code files:
CreditCard.h - The header file which contains the class
definition, akin to that of
CreditCard.cpp - A file which includes additional code
providing the bodies of the member function for class CreditCard,
akin to that of
Test_CreditCard.cpp - A file which provides a main driver for testing the credit card. Please make sure to adhere to the requirements as described in the above section on testing.