Solved-Credit Card Simulator -Solution

Description

You are to create a component (object) class to simulate the operations of a credit card. The class should handle the following normal activities related to a credit card: a) creating a new account or re-opening an existing account, b) making charges and payments, c) updating the credit balance and credit limits, d) charging monthly interest against the outstanding balance, and d) displaying transaction history. Account status and transaction history are kept in separate sequential text files, as discussed below. A GUI such as the following should be built as the ‘view’ component that uses the CreditCard class:

Develop the program according to the following guidelines:

1. A New account request will use the “empty” constructor of the CreditCard class (i.e., the constructor that takes no parameters); this constructor generates a random number for the account id and sets the starting credit limit at $1000. The account status (current limit and balance due) should be stored in a text file named as follows: “CC” + Account Number + “.txt”. Transaction history is stored in a credit card log file, with the name: “CCL” + account number + “.txt”. After instantiation, the history log file should show a log entry for the account creation.

2. An ‘Open Existing’ account request requires an account number to have been entered in the Account number text field. This account number is extracted and sent to an overloaded constructor of the CreditCard class. That constructor takes the account number and opens and reads the “CC” text file to set the current limit and balance due. Of course, it must also verify that the requested account does actually exist (i.e., the CC text file is present).

3. Methods for processing charge and payment transactions must be included in the CreditCard class. These increase and decrease the card balance along with the available credit. Make sure that the operator cannot exceed his/her credit limit with any given charge amount. However, the simulator should let the operator overpay the balance due on a payment transaction (so the balance due can go negative). All transactions should be posted with a date/time stamp showing when the transaction was processed; even denied transactions should have an entry in the log file.

4. The user will also be allowed to request a credit line increase. This request does not necessarily have to be granted; you should include some random number generator (in the credit card class) as a basis for determining success or failure of the request – and, of course, the Credit Card method must be able to inform the form what the outcome was. Credit increases are only granted in units of $100 (i.e., multiples); you may elect to reject requests not in a multiple of $100, or you may round the request to the nearest $100 unit.

5. Interest charges are posted by having the user enter an annual rate through the form. This creates a new charge transaction inside the Credit Card class.

6. The user can also request a history of the account. The history should be returned from the Credit Card class as an ArrayList of Strings where each string is a single line from the CCL text file. The form should then build a second pop-up display to show this data:

A summary of the Credit Card methods:

– Constructor (no parameters sent = random number generated for account #);

– Overloaded constructor taking account number which reads existing CC file

– ‘Get’ for AccountNumber – returns current account number of the object;

– ‘Get’ for CreditLimit – returns current credit limit on the account;

– ‘Get’ for AvailableCredit – returns the value of “credit limit – balance due”;

– ‘Get’ for BalanceDue – returns balance due amount;

– ‘Set’ for Charges (takes double and String parameters) – accepts amount and

description values for a new charge and updates the object values and text files;

this means adding amount to balance due and writing a new log file transaction entry.

Charges cannot be allowed to let the balance due exceed the credit limit.

– ‘Set’ for Payment (taking double parameter) – accepts a payment amount and

subtracts it from balance due, also writing a new log file entry for the payment.

Payments may result in a negative balance due.

– ‘Set’ for Interest Charge (taking double parameter) – accepts an annual interest rate

and applies it (in monthly rate form) to the outstanding balance

– ‘Set’ for Credit Line Increase (taking double as parameter) – receives an amount as

the request for a credit increase; uses internal probability control to accept or

deny increase request.

– ‘Get’ for account history – returns full CCL text file list as an ArrayList of strings

to be displayed as the transaction history log for the account.

PART A:

Part A will cover the building of the form, the creation of the credit card class with empty constructor for new accounts, and the creation of the charge and payment posting methods in the credit card class (along with an error messaging system within the credit card class).

PART B:

Part B will involve implementing the “open an existing account” function – where the user types in the account number and it is sent to an overloaded constructor of the credit card class, which re-opens the desired account. Also included in this part is the process for requesting a credit increase, posting interest charges, and displaying the account history in a pop-up form.

PART C:

The “open existing” function of part B need only receive an account number typed by the user into the account number text field and instantiate the existing card using that input value. For Part C, modify the open existing function (i.e., button click event in the form) to check if an account number has been entered and, if not, launch a JFileChooser to let the user select the account file to open. However, this operation must be able to let the user select a CC file or a CCL file (i.e., must be able to extract the account number from either type of file choice).