CPT206 Computer Programming for Financial Mathematics:

Coursework 3 Task Specification

Set: Tuesday 29 April, 2025

This is the specification task sheet for the Coursework 3 assessment component of your CPT206 module. The task covers all Learning Outcomes, and accounts for 70% of the final mark for this module. This assignment has two parts: a coding part described in Section 1, and a report described in Section 2. The submission deadline for this assignment is Sunday 18 May, 2025, at 23:59 (China-time). Detailed submission instructions are provided in Section 3.

1 Program description (72 marks)

The aim of this coursework is to build a budget planning and management system (for an individual, family, company, etc.). All the work should be coded into a single Java NetBeans project, with the class structure and different functionalities of the program described below. All classes should be properly encapsulated, as seen in the Lectures and Labs throughout the semester. Your project should also contain a main class for running the application.

1.1 Transaction class and subclasses (24 marks)

The Transaction class will be a base class representing a transaction. It will have two subclasses: Expense and Income. Each transaction is for a specified positive amount, and occurs on a given date and at a given time. Transactions are given a unique identifier in the system (using the built-in java.util.UUID class). The date and time of a transaction will be used to sort transactions (see some of the operations in the BudgetManager class in Section 1.3). You may assume that no two transactions will ever occur at the exact same date and time in the system. The Transaction class should also have a getEffectiveAmount() method that returns the signed value (i.e., negaive for expenses, positive for income) of the amount which effectively occurs for that transaction (taking into account fees and so on). This method will be overridden in the subclasses.

Each income transaction should also indicate its source (such as salary, gift, bonus, etc.). The effective amount of an income transaction is the same as its amount. Expenses should use a specific payment method, which should be one of the following: cash, card, Alipay, or . Each payment method comes with a specified fee or charge, corresponding to a certain percentage of the transaction amount: 0% for cash payments, 1% for card payments, and 0.5% for both Alipay and payments. This fee should be incorporated into the calculated effective amount of the transaction.

1.2 BudgetCategory class (10 marks)

The BudgetCategory is intended to manage expenses related to a particular category, such as food, electricity bills, holiday costs, and so on. Each budget category has a name, a fixed monthly limit (how much money can in theory be spent on that category every month), and a current expenditure (the amount that has been spent on that category during the current month to date). Budget categories are always created with a current expenditure of 0. There should be methods to add expenses to the category, to check if current expenditure is over the monthly limit, and to reset the current expenditure to zero. Note that in a fully-developed application, this last method would be automatically called on the first day of each month, but that is not a requirement for this coursework task.

1.3 BudgetManager class (20 marks)

The BudgetManager class should be responsible for managing an entity’s budget (here, “entity” could be an individual person, a family, a company, and so on). For that, it should store the information of all expenses incurred and income received by the entity. Every expense should be tied to a specific budget category, and it should be easy to retrieve all expenses tied to a particular category. Income is not tied to a particular category. You should choose an appropriate object from the Java collection framework to store expenses and income, and leave a comment in your code clearly detailing and explaining your choice. On initial creation, a BudgetManager will have no expenses or income.

Budget managers should be able to add transactions. New incomes are simply added to the collection above, while the method to add a new expense should also specify the corresponding budget category. If the new expense would cause that category’s current expenditure to exceed the monthly limit, a customised MontlyLimitExceededException should be thrown, with a suitable error message displayed. This means that you will have to create a MonthlyLimitExceededException class in your program. Budget managers should also be able to add new budget categories (with initially no corresponding expenses), and delete existing ones.

Finally, your class should be able to filter relevant information pertaining to expenses and/or income, through methods that retrieve the following information:

• all expenses incurred in a specified budget category (see above);

• all expenses incurred that exceed a specified amount (in effective terms).

• all transactions that occurred in a particular time period (specified by its start and end dates).

All filtered transactions retrieved as above should be sorted according to the date and time they occurred.

1.4 User interface (10 marks)

In order to create a friendly user-interactive application that allows the user to manage their budget, you should add a command-line text-based user interface to your program. Since user interfaces have not been taught in this course this semester, you will have to learn how to code such an interface. To do this, you should enlist the help of XipuAI (for more details, see Section 2.3).

Your user interface should allow a user to manage their budget according to the functionalities of the BudgetManager class from Section 1.3. You may also wish to include additional functionalities not listed in the task description (for example, calculating net earnings – total income minus total expenditure – over a given period). Your interface should adhere to best practices of command-line interfaces, including but not limited to exception handling, input validation, and so on. It should also be user-friendly and easy to navigate.

1.5 Code quality (8 marks)

The remaining marks (8) will be awarded for the quality of your code and documentation, as covered throughout the semester in the Lectures and Labs.

• Keep your code neat and tidy; make sure it is properly indented throughout.

• Choose suitable names for variables and methods, respecting standard Java naming conventions.

• Comment your code as needed.

• Split your code into separate methods as appropriate; methods should not be too long.

You should also write Javadoc comments for the entire API of the BudgetManager class from Section 1.3, and submit the corresponding generated Javadoc file “BudgetManager.html” (see detailed submission instructions in Section 3). You do not need to write Javadoc comments for the other classes.

2 Report (28 marks)

For this part of the assignment, you should write a report detailing how you designed, implemented, and tested the program described in Section 1. The report should be typed into e.g. a Word document, and submitted as a PDF (see Section 3 for more details). Where appropriate in the report, you should refer to specific lecture slides (or parts of Lab worksheets), e.g. “as seen in Lecture 10, slides 32-34”.

2.1 OOP features (10 marks)

Over the course of the semester, you have learned a number of OOP features (e.g encapsulation) and principles (e.g. single responsibility principle). In your report, you should explain where you have incorporated these in your design and how you have done so; include a brief definition of the features/principles in question. Be as precise as possible, illustrating with small portions of code if necessary. Note that not all the features and principles we saw in the lectures need to be incorporated into your design; your report should only discuss those that are. This section should be one-and-a-half to two pages in length.

Good example: The Single Responsibility Principle states that every class in the program should have responsibility over a single functionality of the program; a class should do one thing. This principle is incorporated into our class design: all the classes have their own, separate, purpose. For instance, the Transaction class...

Bad example: Encapsulation and inheritance are two core features of OOP; they are used in many parts in my program.

2.2 Testing description (10 marks)

As covered throughout the Lectures and Lab sessions in this module, testing is an essential part of writing computer programs. In your report, you should include a description of how you tested the various parts of the program described in Section 1. Your testing may use the JUnit framework if you are familiar with it, or simply manually check cases in the main class. Your report should state clearly what functionalities you tested, and describe how you tested them, thinking carefully about possible corner cases. You may include some sample code if you wish. This section should be one-and-a-half to two pages in length (screenshots/code excluded).

2.3 AI-assisted user interface design and implementation (8 marks)

As stated above, you should use XipuAI to teach you how to build a command-line user interface for this program. You may use AI in any part of this process. For example, you may wish learning about basic concepts of user interfaces, exception handling, etc., or you might use AI for assistance in code-writing, and so on. In your report, you should explain how your user interface works. This should include details of which functionalities are included and how these are implemented in the interface, how the user should navigate the interface, what exception handling and user input tolerance mechanisms were included, and so on. You should explain your use of XipuAI by detailing clearly how it helped you create the interface, which aspects you used it for, and so on. Remember that you do not have to blindly accept all AI output as inherently correct: critical reflection on AI’s answers and suggestions will be welcome.

The marking for this section of the report will be broken down into 4 marks for the explanation of the user interface and 4 marks for your use of AI tools. This section should be no more than two pages in length, screenshots excluded. You should attach the entire transcript. of your conversation(s) with XipuAI in an appendix to the report (you can save the entire conversation for example by clicking the “Export” button in the interface below).

3 Submission instructions

In the dedicated “Coursework 3 submission” Assignment activity on the Learning Mall Online, you will need to submit the following two (2) documents.

• A single ZIP archive of your entire NetBeans project. Include all the resources your project needs to run. This file should be named “CPT206 CW3 Project studentId.zip”.

• The online Javadoc API documentation file of your BudgetManager class, as specified in Section 1.5. This is the “BudgetManager.html” file generated by your project. You do not need to rename this file.

• Your report from Section 2, including the appendix of your conversation(s) with XipuAI, typed into e.g. a Word document, and converted into a PDF file. This file should be named “CPT206 CW3 Report studentId.pdf”.

This assignment is individual work. Plagiarism (e.g. copying materials from other sources without proper acknowledgement) is a serious academic offence. Plagiarism and collusion will not be tolerated and will be dealt with in accordance with the University Code of Practice on Academic Integrity. Submitting work created by others, whether paid for or not, is a serious offence, and will be prosecuted vigorously. The use of generative AI for content generation is permitted only in the design and implementation of your application’s user interface, as detailed in Sections 1.4 and 2.3. No other use of generative AI for content generation is permitted on this assignment. Such a use would be considered in breach of the University Code of Practice on Academic Integrity, and dealt with accordingly. Individual students may be invited to explain parts of their code in person during a dedicated interview session, and if they fail to demonstrate an understanding of the code, no credit will be given for that part of the code.

Late submissions. The standard University policy on late submissions will apply: 5% of the total marks available for the component shall be deducted from the assessment mark for each working day after the submission deadline, up to a maximum of five working days, so long as this does not reduce the mark below the pass mark (40%); submissions more than five working days late will not be accepted.

This is intended to be a challenging task, and quite a step up from what you have been doing so far, so think about things carefully. We can - and will - discuss some aspects in the Lab sessions, and of course, as usual, you can ask me anything by email, during Office Hours, or in the LMO Forums. Good luck!