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.
The goal of this assignment is to implement and test a CreditCard class, used to manage a typical credit card account.
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. We are also providing a Money class, as a convenient data type for representing monetary values.
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 by paying off the entire previous balance (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 the 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, at the end of each hypothetical month an endOfMonth method will be triggered, starting the bookkeeping process. It is at this time that interest and fees may be assessed and when the minimum payment is determined for the coming month. The rules used are as follows.
The process is based upon the balance and minimum payment that had been recorded at the end of the previous month (though 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 as stated at the end of the previous
month, then an interest charge
of
If payments received this month do not meet or exceed the stated minimum monthly payment as computed at the end of the last month, 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 "end of the month" 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 in the case that the above calculation results in a minimum payment which is greater than the balance itself, the minimum payment should be set to the balance itself.
The official set of public methods which must be supported is as follows:
The constructor allows for general customization of the initial state of a credit card account. The parameters should be used to initialize the underlying state of the respective attributes. Notice that the initial balance provides a default parameter value of 0. Typically a new account will start with such a balance, however we leave open the possibility that someone may open a new credit card while transferring a non-zero balance from elsewhere.
CreditCard(string no, string nm, Money lim, double rate, Money bal=Money(0))
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.
Money getLimit() const
Overall credit limit (though 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)
Money getCurrentBalance() const
This should be the up-to-the-minute balance on the account.
Money getPreviousBalance() const
This should be the balance that was recorded at the end of the
last monthly cycle. This is significant to the customer when
making payments to avoid interest charges.
Money getMinPayment() const
This should be the minimum payment that was recorded based upon
the end of the last monthly cycle. This is significant to the
customer when making payments to avoid subsequent late fees.
By our rules, this value will always be measured in dollars, and
thus an integer.
bool chargeIt(Money price)
This is called when the card owner attempts to make a purchase
for the given price. 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(Money payment)
This is called when the card owner submits the specified
payment.
Negative payments should be disallowed.
Assuming the payment was positive, the customer's current
balance should be reduced to reflect the payment.
Money endOfMonth()
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.
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 $35.75, $800 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 $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 endOfMonth()
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 again $60.
In the fourth month, the customer makes a payment of $1200 and an additional purchase of $500. In this case, at the end of the month, no late fees or interest are charged, because the payment 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.
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.
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.3 (pp. 75-81) of our text for a similar discussion in the breakdown of the Clock program into three pieces. You may also look at the breakdown between Money.h and Money.cpp as another example.
For this assignment, we are actually providing four different files. These files 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 six files are:
CreditCard.h - The header file which contains the class definition.
CreditCard.cpp - A file which provides 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.
Money.h - The header file which contains the Money
class definition.
Do not edit this file.
Money.cpp - A file which provides the implementation of
the functions that were declared in Money.h.
Do not edit this file.
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.
You should submit four 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.
readme - For every assignment, you will be asked to submit such a text file. In general, this provides a way for you to add any further comments you wish to make to the grader. For many assignments, there will also be additional explicit requirements for the contents of this file.
For this assignment, please explain the design decisions you made in regard to the private data members of the CreditCard class.