COIT20256 - Data Structures and Algorithms Assignment Help
COIT20256 Assignment 2 Practical Assessment 2
(Individual Assignment)
Due date:
Final submission – Friday Week 12 (see more details on Moodle and below – note an earlier phase 1 submission is also required.)
Phase 1 – in the assignment 2 phase 1 submission area
Submit your phase 1 version in this area as soon as it is complete. This is to allow markers to check incremental development.
Due Tuesday of week 9.
Final Submission (in the Assignment 2 final submission area):
The Word document with your report (NOT in a zip file)
A zip file with the NetBeans project with the code for the final version (your last completed phase) of your assignment.
Marks will be deducted for late submissions.
Weighting:
20%
This assignment must be implemented:
incrementally according to the phases specified in this documentation. If you do not submit a complete working and thoroughly tested phase you may not be awarded marks.
according to the design given in these specifications. Make sure your assignment corresponds to the class diagram and description of the methods and classes given in this document. You must use the interface and inheritance relationships specified in this document. You must implement all the public methods shown. Do not change the signature for the methods shown in the class diagram. Do not introduce additional public methods. You may introduce your own private/helper methods. Your output is to be displayed using the format shown in the example output in this specification document. This will be important for markers checking your work.
using only the features covered in the unit. This assignment uses JavaFX to develop a GUI for the application. Your project must be built according to the instructions in the NetBeans guide (use SceneBuilder to generate the fxml file and then use that fxml file to make the controller etc. as described in the NetBeans guide). In addition, your application must compile and run with the versions of the software specified. You can test this by compiling and running your code using Apache NetBeans 20 on a CQU lab computer.
Note that to be awarded marks:
Your program must compile and run.
You may be required to demonstrate your understanding of the code that you submit before marks can be awarded.
If required, you must be able to provide us with a copy of any of the phases of development. Keep backups of each phase so that you are prepared to show this work if requested. The specifications describe the functionality to be introduced in each phase. Develop the phases as specified in this document.
In this assignment you will develop a GUI application which uses JavaFX, inheritance, polymorphism, interfaces, generic collections, exception handling and writes to a file.
The Task
In this assignment you are to develop an application to manage customer accounts. It will have many limitations, some of which will be discussed here and some that you are be expected to identify and discuss in your associated assignment report.
All accounts will have the following attributes:
Account id: a unique account identifier.
Type: the type of account (see the possible types below).
Monthly interest rate: the monthly interest rate associated with the account
Customer id: the unique customer id of the “owner” of the account.
The calculations for monthly interest and rules for the different account types are simplified for the purposes of this assignment. The three different account types described below:
Home Loan account
In addition to the attributes above, a home loan account has the following information:
The original loan amount
The duration of the loan (in years)
The start date of the loan
The amount currently owing
The last interest amount charged
This is a home loan account – money borrowed to purchase a house or unit. We could have included additional attributes such as the minimum monthly payment, when each monthly payment is due and the last payment details (date and amount). The calculations and checks actually carried out for this type of loan would be more complicated than the specifications in this assignment. For example, in this application we do not check that a customer pays the minimum amount due by the due date and we make various simplifying assumptions about the calculations and how the account is managed.
For a home loan account assume that:
The monthly interest is charged on the last day of each month and it is calculated based on the total amount owing at that time.
The customer always pays at least the minimum payment on the first of each month- it is expected that the minimum monthly repayment would be more than the monthly interest and would be an amount calculated such that the loan would be repaid in the time specified. However, there is no need to carry out any calculations or checks for that in this assignment.
In the assignment we will use the GUI interface to “deposit” the customer’s monthly payment into the system. Normally there would be a separate interface to allow a customer to do this, but that is not required for this application.
Withdrawals are not normally permitted unless there are exceptional circumstances. We will provide a withdrawal method for this account type, but you must prevent it from being accessed in the GUI that you develop (i.e. the withdraw button is to be disabled for this account type). Note that you should not disable the withdraw button until you have tested that your withdraw method works correctly (and included that test and its result in your test plan and report). After that test is completed you must modify the code so that the withdraw button is disabled when interacting with a home loan account (and enabled with the other account types).
Note that for a home loan:
the interest gets added to the amount owing
a deposit/payment gets deducted from the amount owing
a withdrawal must be added to the amount owing.
Daily Access account
In addition to the attributes that all accounts have (account id, type, monthly interest rate and customer id), a daily access account has the following information:
Current balance
Minimum monthly balance (used for the monthly interest calculation)
Last interest earned
A daily access account is one that a customer would use for day-to-day use. The interest on this type of account is to be calculated on the last day of each month and is calculated on the minimum balance since the last time interest was calculated (and added to the balance). This means that when the interest is added, the system must also reset the minimum balance to this new balance and whenever there is a withdrawal the withdraw method must check to see if there is a new minimum that must be set. Any amount deposited is added to the balance.
Goal Saver account
In addition to the attributes that all accounts have (account id, type, monthly interest rate and customer id), the goal saver account has the following information:
Current balance
Balance at the start of the interest calculation period
Last interest earned
A goal saver account is to encourage the customer to save. It offers a higher interest rate than the daily access account to encourage saving, but it has the constraint that no interest will be earned unless the balance at the end of the interest period is $500 more than it was at the start of the interest calculation period. To keep the calculations simple when an account qualifies for interest, the interest calculation will be calculated based on the current balance in the account at that time.
In addition, when the monthly interest calculation is carried out the “balance at the start of the interest calculation period” attribute must be reset. If the account qualifies for interest being added, then “the balance at the start of the interest calculation period” should be reset to the balance after the interest is added. If the account did not qualify for interest being added “the balance at the start of the interest calculation period” should be reset to the balance at that time. (We will call the instance variable that tracks the “starting amount for an interest period the “startOfMonthBalance”.) You can assume that the interest is calculated and added on the last day of each month and that “startOfMonthBalance” is actually reset at that time.
In this account type, any amount deposited gets added to the balance and any withdrawals are deducted from the balance.
Limitations
In this assignment we are not going to read the information from persistent data storage (e.g. from a database) or save our changes in persistent data storage. However, we will generate final reports and save the reports in a file.
In the requirements below interest is calculated at specific times of the month. However, when developing and testing your application it is not appropriate to enforce this constraint. You are to are to perform these calculations independently of the data. You are not to include any safeguards to prevent the calculations from being carried out at other times as part of this assignment.
The Use Cases
When a customer id is entered in the GUI and the “Find Customer” button clicked, the application must display the customer details and also allow the user to iterate through all the accounts for that customer in both a forward and a backward direction. You are to implement the next and previous buttons so that the program cycles continuously through the list of accounts in a similar way to the contact lists exercise in the tutorial. Note that the number of accounts for a customer is also to be shown on the GUI.
If a customer with the given id is not found, an appropriate message is to be displayed in the messages text area. It is to show the customer id that was requested and state that there is no customer with that id.
When an account id is entered and the “Find Account” button is clicked, the application must display the details of the account and the details of the customer who owns the account. Again, it must also be possible for the user to iterate through all the accounts for that customer.
If an account with the given id is not found, an appropriate message is to be displayed in the messages text area. It is to show the account id that was requested and state that there is no account with that id.
When the user clicks on the “Add all monthly interests” button, the application must perform all the monthly interest calculations and updates the information about all the accounts in the system.
When the deposit button is clicked, the amount entered is to be “deposited” into the current account being viewed. If a valid amount is not entered in the deposit text field (i.e. it is negative or the data is not a valid floating point number), then an appropriate error message is to be displayed in the messages text area. Hint: For this assignment, if it is not a valid floating point number you can catch the exception that occurs when the application attempts to convert the string amount to a double, display an appropriate error message in the messages area and allow the user to re-enter the data[1]. Something similar was illustrated in the TipCalculator example in the lectures where the GUI also refocused on the text field where the user was to re-enter the data. Although preferred, you are not required to use regular expressions to validate the input data using regular expressions in this assignment as they are not covered until week 11.
When the withdraw button is clicked, the amount entered is to be withdrawn from the current account being viewed . Again, as with the case for deposits, your program must display an error message if a valid amount is not entered etc.
When the “generate reports” button is clicked, a file with a report about the accounts for every customer is to be written. The report name is to include the date. The format of the report and report name are shown in Appendix B.
In all cases appropriate error messages must be displayed if there is no current customer, no current account or if invalid information is entered into text fields and this information is required to achieve the functionality described. (For example, the user cannot deposit an amount if no amount or an invalid amount has been entered and/or if there is no current account being viewed. Negative values for deposit and withdrawal amounts are also to be treated as invalid input.)
The Class Diagram
Figure 1: UML Class Diagram
The GUI
The GUI that you are to develop for this application is shown in the screenshot below:
Fgure 2: The Graphical User Interface.
The above GUI has the following controls:
4 labels displayed in bold. These are used for the headings: customer details, account details, action buttons and messages/
7 normal labels – one next to each of the text fields for customer details (including how many accounts the customer has), and the account id and account type.
9 text fields for customer and account details plus text fields to allow the user to enter the amounts for deposits and withdrawals.
10 buttons which are labelled with their functions. The clear button should result in the GUI appearing as it does in the screenshot above (i.e. all the text fields and text areas cleared). The exit button should exit the application. Next and previous are to get the details about the next and previous account in the list of accounts for the current customer.
2 text areas – the two larger rectangles in the screenshot above. One text area is where messages are to be displayed to the user (if required). The other text area is under the account details. It is to display the additional information about the account. Examples for each the account types are shown in phase 3B.
The user must be able to enter data into the text fields associated with the Customer ID and the Account ID labels. The user must also be able to enter data into the text fields for the amounts associated with the deposit and withdraw buttons.
The user must NOT be able to enter text into any of the other text fields or into either of the two text areas.
The Phases
Phase 1: GUI
The unit covers the content required to develop the GUI in week 8.
Note: Phase 1 is due for submission at the start of week 9. Check the unit website submission area for the exact date and time.
In this phase you are to:
develop the GUI shown in figure 2 using the instructions in the NetBeans guide.
The functionality for the clear and exit buttons is to be implemented. Clicking the clear button is to clear all the text field and text areas as well as enable the withdraw button. (It may have been disabled if a home loan account was being viewed.) Clicking the exit button is to exit the application.
When any of the other buttons are clicked they are to display a “button name clicked - under development” message in the messages text area. For example, if the user clicks on the deposit button, the message should be “deposit button clicked - under development”.
Phase 2: Find and Display Customer Details
In week 9 we cover generic collections. As part of the week 9 content you will learn how to use a HashMap. The CustomerList class has two HashMaps:
One HashMap for the customer objects
One HashMap for the account objects.
The HashMaps will allow efficient lookup of the customer and account objects based using their ids.
You can implement most of the code required to implement phase 2 code without an understanding of HashMaps so you should begin this phase as soon as you have completed phase 1. Details of the requirements for this phase are provided below.
This phase is divided into 2 sub-phases.
Phase 2A: Display Customer details
In this phase you are to add the following classes to your project and implement the find customer button’s action listener.
Add the following classes to your application. See the UML class diagram for details about the instance variables, methods and relationships between these classes. Make sure that you follow the design in the UML class diagram. Do not change names, parameter lists or public/private accessors etc. Do not add additional public methods. You can add private helper methods.
Customer
Account
DailyAccessAccount
GoalSaverAccount
HomeLoanAccount
CustomerList
Include the inheritance relationships shown in the class diagram.
The Customer class
This class has the customer attributes and an array list of the accounts for a customer. In this phase you are to complete the implementation the following methods:
The constructor
The get methods for the customer’s id, name, email and phone number.
The toString() method which might not be required in this application but may be useful when testing/debugging your code.
The getNumberOfAccounts() method
The getFirstAccount(), getNextAccount() and getPreviousAccount() methods used to iterate through the array list of customer accounts. The currentAccount instance variable tracks the “index”/location of the current account in the array list when iterating through the list of accounts. This is similar to the exercise in the JavaFX tutorial. The getNextAccount() and getPreviousAccount() are to keep cycling through the accounts in either the forward or backward direction.)
The setCurrentAccount() method. It is to be passed an account id that it uses to find the position of the account with that id in the array list. This method is needed when the user needs to find an account with a particular id. In that case the customer associated with the account must also be found and the customer details displayed. In that scenario the user must also be able to use the getNextAccount() and/or getPreviousAccount() methods to find the details about the other accounts for that customer, hence the need to set the currentAccount.
The addAccount() method. It is to be used to add an account object to the array list of accounts.
The following methods are not implemented in this phase:
applyMonthlyInterest() is not implemented in this phase. It is to be used in a later phase to apply the monthly interest calculations and updates to all the accounts for the customer.
generateReport() is not implemented in this phase. It is to be used in a later phase to generate the report for the customer (with details about all the customer’s accounts).
The Account classes (super and subclasses)
About monthly interest calculations for the account classes:
In the bank, monthly interest calculations are only intended to be carried out once per month and on the last day of each month. However, you must NOT introduce any such constraints in your code. That would be out of scope and would interfere with your testing and that of the markers.
Details about each of the account classes follows.
The Account class
This is the super class of the three account classes. It is an abstract class (with several abstract methods).
It has instance variables to store:
The account id.
The type of account.
The interest rate to be applied each month.
The id of the customer who “owns” the account.
In this phase you are to implement the following methods in the Account class:
the constructor
the “get” methods for the account id, type, interest rate and customer id.
You must also include the statements for the 4 abstract methods to be implemented by classes that inherit from Account. (See the class diagram.)
The DailyAccessAccount class
This is the class for daily access accounts. It has instance variables to store:
The current balance of the account.
The minimum balance since the last interest was calculated (and added to the balance).
The last amount of interest earned.
In this phase you are to implement the following methods in this class:
The constructor.
A skeleton/dummy getAccountDetails() method that is to return a “Method Name Under Development” string in this phase.
You must also include “dummy/skeleton” implementations for the other abstract methods (applyMonthlyInterest(), withdraw() and deposit()). If you don’t do that your class would have to be abstract. You can either implement the bodies of these methods in this phase (testing won’t be possible yet) or print a “method name under development” message to the console. If you add the actual implementation, testing will have to be carried out in a later phase when you can view all the account details on the GUI. Marks can only be awarded for these methods when they can be tested – i.e. in phase 4.
Note that for this account type:
The withdraw() method is to deduct the withdrawal amount from the current balance to get the new current balance. When you implement the withdraw() method for this account type you MUST check if the balance after the withdrawal is less than the “minimum balance since the last interest was calculated”. If it is, then the minimum balance must be set to this new balance.
When you implement the applyMonthlyInterest() method for this class, it is to calculate the interest earned by multiplying the “minimum balance since the last interest was calculated” by the monthly interest rate. The interest earned is then to be added to the current balance. In addition, this new current balance is then to be assigned to the “minimum balance since the last interest was calculated”.
The deposit() method adds the deposit amount to the current balance.
The GoalSaverAccount class
This is the class for goal saver accounts. It has instance variables to store:
The current balance of the account
The balance at the start of the month (actually the balance that is to be assigned immediately after the “monthly” interest gets added).
The last amount of interest earned
In this phase you are to implement the following methods in this class:
The constructor
A skeleton/dummy getAccountDetails() method that is to return a “Method Name Under Development” string in this phase.
You must also include “dummy/skeleton” implementations for the other abstract methods (applyMonthlyInterest(), withdraw() and deposit()). If you don’t include them at this stage then, as discussed above, your class would have to be abstract. Again, you can either implement the bodies of these methods in this phase (without testing) or print a “method name under development” message to the console. If you add the actual implementation, testing will have to be carried out in a later phase when you can view all the account details on the GUI. Marks can only be awarded for these methods when they can be tested – i.e. in phase 4.
Note that for this account type:
When you implement the applyMonthlyInterest()you MUST check if the current balance at the time of the calculation is greater than or equal to the startOfMonthBalance + 500). If it is then the interest earned is to be calculated by multiplying the current balance by the monthly interest rate. The interest calculated is then to be added to the balance. If the current balance is not greater than or equal to the (startOfMonthBalance+ 500), then no interest is to be added to the current balance, i.e. the current balance is unchanged. The applyMonthlyInterest() method must then reset the startOfMonthBalance to the value of the resultant current balance. Strictly speaking, the startOfMonthBalance is actually the balance after the last month’s interest has been applied.
The deposit method() adds the amount to be deposited to the current balance.
The withdrawal method() deductsthe withdrawal amount from the current balance
The HomeLoanAccount class
This is the class for home loan accounts. It has instance variables to store:
The original loan amount
The duration of the loan
The start date of the loan
The amount still owing
The last monthly interest that the customer had to pay. (This gets added to the amount owing.) Again, we assume that the monthly interest is only charged on the last day of each month and it is calculated based on the total amount owing at that time
In this phase you are to implement the following methods in this class:
The constructor
A skeleton/dummy getAccountDetails() method that is to return an “Method Name Under Development” string in this phase.
You must also include “dummy/skeleton” implementations for the other abstract methods (applyMonthlyInterest(), withdraw() and deposit()). Again, if you don’t do that your class would have to be abstract. You can either implement the bodies of these methods in this phase (without testing) or print a “method name under development” message to the console. If you add the actual implementation, testing will have to be carried out in a later phase when you can view all the account details on the GUI. Marks can only be awarded for these methods when they can be tested – i.e. in phase 4.
Note that for this account type:
The applyMonthlyInterest() calculates the interest by multiplying the amount still owing by the monthly interest rate. That amount is then added to the amount owing.
The deposit() method is to deduct the deposit amount from the amount still owing.
The withdrawal() method is to add the withdrawal amount to the amount still owing.
The CustomerList class
When you have completed the week 9 content about HashMaps you will have covered all the content required to complete this class apart from the generateReports() method. The generateReports() method is required to write reports to a file. Reading from/writing to files is covered in week 10. After the week 10 lecture you will have covered all the content required to complete the whole assignment.
The CustomerList class has two instance variables:
A HashMap with all the customers objects. The key used to locate a customer object is the customer id.
A HashMap with all the account objects. The key used to locate an account object is the account id.
In this assignment the data about customers and their accounts is to be hardcoded into the application. The CustomerList class’s loadCustomerData() method is to be used construct all the customer and account objects, add the account object reference to the customer object that “owns” the account and store customer and account objects in their respective HashMaps. The code to achieve this with example data that you can use for testing is provided in Appendix A. It populates the data structures with 3 customers each with at least two accounts.
In the CustomerList class implement the following:
The loadCustomerData() which loads customer and account details – see Appendix A.
The findCustomer() method – this method has one parameter, the customer id. It is to get the customer object associated with the customer id from the HashMap of customers. Given the id (of type String) and the HashMap called customers, the reference to the Customer object with the given id is obtained by calling customers.get(id). Note that this will return null if there is no customer with the given id.
The findAccount() method – similarly, this is to get the account object associated with the specified account id from the HashMap of accounts.
There is no need to include a constructor. A default constructor will be created for this class.
The following methods are to be implemented in a later phase:
applyMonthlyInterest()
generateReports()
In the CustomerController class
This class must be able to access the CustomerList object with all the data about accounts and customers. It must also maintain references to the “current customer” and “current account” being displayed on the GUI.
In the CustomerController class complete the following
Declare the three private instance variables to refer to Customer, Account and CustomerList objects.
Add the inject(CustomerList clist). This method is to assign the value passed in to the CustomerController’s CustomerList instance variable. It is to be invoked in the start() method of the App class.
Implement the action listener for the “find customer” button. It is to:
Get the customer id entered by the user (in the customer id text field)>
Find the customer object with the customer id entered. (It is to use the CustomerList object’s findCustomer() method).
Assign the reference to the customer object to the currentCustomer instance variable in the controller.
Display the customer details on the GUI. (This is to include the information about the number of accounts for that customer. See the example in the screenshot below.)
Note:
It will be useful to include some private methods in the CustomerControlller (e.g. displayAccount() and displayCustomer()).
You will not be able to test the “find customer” button until you make the following changes to App.java and provide the controller with access to the CustomerList object.
In App.java
Modify App.java so that in the start() method the CustomerList object is constructed, its loadCustomerData() method is invoked and the reference to the new CustomerList object is passed into the CustomerController using the inject() method (similar to the ContactList JavaFX tutorial exercise).
Test Phase 2A – find and display the customer details
In this phase the output should be similar to the following screenshots.
Example where customer is found:
In the test below C0003 was entered for the customer id and the “find customer” button clicked.
Example where customer is not found:
In the test below C0004 was entered for the customer id and the “find customer” button clicked.
Phase 2B: Display Customer Accounts Using Next and Previous Buttons
In this phase you are to:
Extend your “find customer” button’s action listener so that it now displays the account id and the account type of the first account in the customer’s list of account objects. The other account information will be displayed in the text area under account details in a later phase.
Implement the action listeners for the next and previous buttons so that the user can iterate through the accounts for the customer. (In this phase, only the account id and account type are displayed in their respective text fields.)
Test phase 2B
Make sure that you test previous and next. They are to cycle through the list of accounts continuously going backwards or forwards through the list respectively. The screenshot below shows the result when you enter C0003 and click the find customer button when phase 2B is completed. Note that the type and id of the first account is displayed.
Also test your previous and next buttons now and ensure that they allow you to cycle through the accounts for the current customer.
Phase 3: Find an Account
This phase is split into 2 sub-phases.
Phase 3A: Find an Account and Display the Account ID, Account Type and the Customer Details.
In this phase the following functionality is to be implemented:
Find an account. Given an account id, display the account id and type on the GUI as well as the details about the customer who “owns” the account.
Having found the account and the associated customer, the user must now be able to view all the other accounts for this customer. This requires the implementation and use of the setCurrentAccount() method to set the Customer object’s currentAccount instance variable to the location of the account in the customer’s list of accounts.
Test phase 3A
Phase 3B: Display All the Details About an Account
In this phase you are to add code to display all the information about an account in the text area below the id and type.
Note that because strings are immutable, rather than concatenating strings you are to construct and use a StringBuilder object to gather all the additional information about the account. Once constructed new information can be appended to the StringBuilder object. When all the information has been added to the StringBulder object it can be converted to a String be returned from the getAccountDetails() method. The string can then be displayed in the text area below the account number and account type.
For example, if the amount owing on a home loan was $600,000.00 and the annual interest rate was 6%, then the following getAccountDetails() method would return the string shown after the method:
The above method would return the following string:
“Amount Owing: $600000.00
Annual Interest Rate: 6.00%”
Note:
In the above example (and in the required output in the application) we display the annual interest rate. We therefore multiply the monthly interest rate by 12.
There is more information that needs to be included in the string to complete the method above. The example above is a simple example to show how to use the StringBuilder class. StringBuilder is covered in more detail in week 11.
Screenshots showing examples of what is to be displayed for each of the account types are provided below:
Home Loan Account
Goal Saver Account
Daily Access Account
Test phase 3B
Phase 4: Withdraw, Deposit and Add Monthly Interest
This phase is also split into 2 subphases. In the first phase you are to implement the code to withdraw and deposit money from/to the accounts. You need to be able to modify what is in the accounts to be able to thoroughly test phase 4B under different circumstances.
Phase 4A: Withdraw and Deposit
Now that you are able to display all the information about the accounts on the GUI, you are in a position to test the withdraw() and deposit() methods.
If you did not do this earlier, you should now implement the deposit() and withdraw() methods in each of the account classes according to the rules for the account type. Remember to update any of the instance variables that need to be updated as a result (e.g. balance, minimum balance). The details will depend on the account type.
To get the amount to be deposited or withdrawn the action listener will have to get the information from the appropriate text field. Remember, the data you get from the text field will be a string. You will have to convert it to a double for your calculations. Hint: use Double.parseDouble() which gets passed a String and returns a double. You must also make sure that the data entered into the text fields for the deposit and withdraw amounts are valid. If the data is not a valid representation of numeric data, an exception will be thrown when the code attempts to convert it to a double. As discussed earlier, you could test that it is a valid representation of a double using regular expressions, but we do not cover regular expressions until week 11, so that is not required. For this assignment you are to catch the exception that is thrown when the program attempts to convert an invalid representation to a double. The catch block is to display an appropriate message in the messages text area. Also remember to check that negative values are not entered for the withdraw and deposit amounts.
Test that withdraw() and deposit() work correctly for all your account types.
After testing that withdraw behaves correctly for the home loan (and capturing this in your test plan and results) modify the code to disable the withdraw button when the account type is a home loan. Note that the withdraw button must be enabled for other loan types. You will also require tests to check that this works correctly.
Phase 4B: Add Monthly Interests
Again, now that you can view the account details, you are able to test that monthly interest is calculated correctly and that the instance variables of the account are updated appropriately.
If you did not complete the code to apply the monthly interest calculations and updates required for all the accounts earlier, add the code for this now.
Thoroughly test the applyMonthlyInterest() method. Check that all the rules are followed for each of the account types under the different circumstances described for each of the accounts.
The screenshots below show some sample tests. They have the before interest is applied and after interest is applied for each of the account types. The testing is not exhaustive.
Daily Access Account
The before interest applied state
(The screen shot below will be the state after a withdrawal so that balance and minimum balance are not the same.)
After Interest applied
Goal Saver
The before interest applied state
(The screenshot below will be the state after a deposit of 500 so that balance is at least 500 more than the starting balance and as a result interest will be added. Note that you should also have a test when that is not the case.)
After Interest applied
Home Loan
The before interest applied state
(The screenshot below will be the state after a deposit of 3000.)
After Interest applied
Phase 5: Generate Reports
In this phase you are to generate a report in a text file that has the details of every customer and their accounts. The text file is to be called ReportForDate_dd_mm_yyyy (where dd_mm_yyyy correspond to the current date). The file is to be located in the same folder as the src folder for the NetBeans project (i.e. the default folder/ current working directory for the application).
An example report is shown in Appendix B.
Note that the report must be ordered according to customer id. (Hint: See the example that achieves a similar ordering of the output in the displayMap() method in Fig 16.17 of the textbook and lecture slides.)
When the report has been generated display an appropriate message in the Messages text area (e.g. report generated).
To obtain the report name with the date in the correct form, use the following:
Date date = Calendar.getInstance().getTime();
SimpleDateFormat dateFormat = new SimpleDateFormat("dd_MM_yyyy");
To obtain the string with the date in the form required for the heading for each customer use the following:
dateFormat = new SimpleDateFormat("dd/MM/yyyy");
String dateString = dateFormat.format(date);
Questions
The following questions are to be answered in the report.
In the assignment we have used type double for storing the values of balances etc. However, double should NOT be used in practice when working with monetary calculations. What should you use instead and why?
Were there any other concerns that you had and/or safeguards/checks or additional functionality that is missing that you thought your application required or will require in the future?
To be Submitted
For the phase 1 submission (in the phase 1 submission area) you are to submit:
A zip file with the NetBeans project with your phase 1 application.
You are not required to submit the report with the phase 1 submission.
For the final submission you are to submit the following two files:
A zip file with the NetBeans project with the last phase that you have completed (ideally the final) phase.
Your Report.doc. This report document must NOT be in a zip file because it must go through Turnitin and have a similarity score before it can be marked. The report file is to contain your completed report template (including your answers to the two questions above). The report template can be found in the assessment block under this assignment specification. Your completed report must include a test report with the test plan and results of performing the tests in the test plan. The test plan is to list all the tests that you will use to test the program (clearly showing what is being tested), data used in the tests and the expected output for each of the tests. The test report must then show the actual output generated by your program. The test results are screenshots to show that the program generates the expected outputs shown in the test plan. For each test in the test plan indicate whether the test passed or failed. See the documentation about testing in the resource block of the unit website.
Note that it is better to document any known bugs (and to indicate that a test has failed). That indicates that you found the problem and that you were aware of the bug. If you do not document a bug and the marker finds it, you will lose marks not just for the bug but also for poor testing. See the marking criteria – testing is important and there are significant marks assigned for your test plan and test results.
Marking Criteria
Note: this table shows you the maximum mark you can get for each of the criteria for each phase. If you do not complete the final phase (all phase 4 functionality) you can still achieve the marks available for the last completed phase that you submit. Always keep a backup of your last working phase.
Phase
Functionality (and good practices)
Report (sections other than the test plan & results)
Test Plan
(test plan and test results)
Source code documentation and layout/presentation
Totals
P1: GUI
4
5
3
1
13
P2A: Infrastructure + find customer and display their details
4
2
6
12
P2B: also display the customer’s first account id and type; cycle through accounts (prev and next)
5
3
2
10
P3A: find account – display account and the customer for the account (and again prev, next work)
5
3
2
10
P3B: display all account information
3
3
1
7
P4A: withdraw() and deposit() methods and withdraw button disabled/enabled
6
5
1
12
P4B: monthly interest calculations and updates
5
4
1
10
P5: generate reports and write to file
4
1
1
6
Totals
36
5
24
15
80
Note: This assessment item is worth 20% of your overall mark so this mark out of 80 will be converted to a mark out of 20 in the gradebook and in your marksheet.
Appendix A: Initializing the Data in the CustomerList Constructor
In the code below customers and accounts are both instance variables that are references to HashMaps where the key is the customer and account id respectively. HashMaps are covered in week 9. The declarations for the two instance variables (and construction of the HashMaps assigned to the variables) requires the following two statements at the start of the CustomerList class:
private HashMap<String, Customer> customers = new HashMap<>();
private HashMap<String, Account> accounts = new HashMap<>();
public void loadCustomerData(){
// create three customers
Customer cust1 = new Customer("C0001", "John Smith", "0412345678", "j.smith@cqumail.com");
Customer cust2 = new Customer("C0002", "Mary Brown","0412456789","m.brown@cqumail.com");
Customer cust3 = new Customer("C0003", "Peter Green", "0412567890", "p.green@cqumail.com");
// add them to the HashMap of customers
customers.put("C0001", cust1);
customers.put("C0002", cust2);
customers.put("C0003", cust3);
// create 7 accounts and add them to the HashMap of accounts
Account acct3 = new GoalSaverAccount("GS0001", "C0002", 0.0075, 2000 );
accounts.put("GS0001", acct3);
Account acct4 = new GoalSaverAccount("GS0002", "C0003", 0.0075, 10000 );
accounts.put("GS0002", acct4);
Account acct5 = new DailyAccessAccount("DA0001", "C0003", 0.0025, 400 );
accounts.put("DA0001", acct5);
Account acct6 = new DailyAccessAccount("DA0002", "C0002", 0.0025, 1000 );
accounts.put("DA0002", acct6);
Account acct7 = new DailyAccessAccount("DA0003", "C0001", 0.0025, 3000 );
accounts.put("DA0003", acct7);
// add accounts to the customers.
cust1.addAccount(acct1);
cust1.addAccount(acct7);
cust2.addAccount(acct3);
cust2.addAccount(acct6);
cust3.addAccount(acct2);
cust3.addAccount(acct4);
cust3.addAccount(acct5); (details about testing continued on the next page)
Note that your testing is not limited to using only the above data. You can add additional customers and accounts to do more thorough testing as required. You can also remove data for specific tests. For example, do the next and previous buttons still work correctly if a customer only has one account?
In your test plan, you can make reasonable assumptions about the application data, but these assumptions must be documented. Form example, you might assume that:
There will not be a customer in the system unless the customer has at least one account.
An account will definitely be in the list of accounts for the customer with the id stored in the account details. (Or you could code defensively and test for the account not being found in the customer’s list of accounts in case you make an error setting up your data structures. If there is such an error in the data structure relationships, you should display an appropriate error message indicating that the account is not correctly “linked” to the customer.
Appendix B: A Sample Report
The following is a sample of the report generated on 17/4/24. It was saved in a file called ReportForDate_17_04_2024
Date: 17/04/2024 Customer ID: C0001 Name: John Smith
Date: 17/04/2024 Customer ID: C0003 Name: Peter Green
Account ID: HL0002 Type: Home Loan
Amount Owing: $600000.00
Interest Rate: 0.0500
Monthly Interest Charged: $0.00
Original Loan Amount:$600000.00
Loan Start Date: 01/03/2024
Duration of Loan: 20 years
Account ID: GS0002 Type: Goal Saver
Account Balance: $10000.00
Balance at start of month: $10000.00
Last Interest Earned: $0.00
Interest Rate: 0.7500
Account ID: DA0001 Type: Daily Access
Account Balance: $400.00
Minimum monthly Balance: $400.00
Last Interest Earned: $0.0000
Interest Rate: 0.2500
[1] Note that doing validation in this manner is generally considered bad practice. Explicit validation (e.g. using regular expressions) would normally be used.
