PROJECT: IchiFund

Overview

This portfolio documents my contributions towards the project, IchiFund, which is part of an introductory software engineering module, CS2103T. My team (of 5) was tasked to morph or enhance an existing address book software. Our resulting product, IchiFund, is a desktop finance management application for students to manage transactions, budgets and loans. It is optimised for students that prefer using a CLI. My role was to develop the Repeaters component of the application.

Summary of contributions

  • Major enhancement: Developed the Model, Logic, Storage, and Ui infrastructure for repeaters.

    • Functionality: Provides the foundation on which features related to repeaters, in particular add, edit, delete and find, are built.

    • Justification: The ability to easily create, read, update and delete repeaters on the GUI of the application depends on properly establishing the infrastructure for repeaters.

    • Highlights: This enhancement demonstrates a deep understanding of the design pattern underlying the existing code.

  • Major enhancement: Implemented the synchronization of associated transactions whenever the repeaters are updated.

    • Functionality: When adding, editing and deleting repeaters, the list of associated transactions are automatically synchronized to the update.

    • Justification: Repeated transactions are tedious to handle if they were to be created one by one as separate transactions. With repeaters, the user only need to create, edit and delete a single transactions and all associated transactions will automatically be updated. This greatly reduces the amount of effort needed for users to manage repeated transactions.

    • Highlights: This enhancement required the implementation of an additional field in Transaction to allow for association between transactions and repeaters. In addition, additional functions were also implemented to synchronize the list of associated transactions whenever a repeater is added, created or deleted. This demonstrates the ability to implement features in conjunction with the work of other developers.

  • Minor enhancement: Added the ability to edit (PR #160), delete (PR #140) and find (PR #243) repeaters.

  • Code contributed: Click here to view the code I have contributed on the CS2103T tP Dashboard.

  • Other contributions:

    • Team:

      • Reported bugs and suggestions for other members in the team (examples: 276, 108, 24)

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Repeaters

There is sometimes a need to add the same transaction over and over again. Such is the case for recurring transactions such as phone bills and salaries. With our repeater feature, you can add these recurring transactions in a hassle free manner.

In the repeater tab, you can maintain a list of your repeaters. Each repeater is associated with a list of transactions, which are managed by the repeater. The image below gives an overview of the GUI of the feature. The associated transactions managed by each repeater are highlighted with the respective colored box.

rep

Creating repeater: add

Format: add de/DESCRIPTION a/AMOUNT [c/CATEGORY] [ty/TRANSACTION_TYPE] [so/MONTH_START_OFFSET] [eo/MONTH_END_OFFSET] sm/START_MONTH sy/START_YEAR em/END_MONTH ey/END_YEAR

You can use the add command to create a repeater. This also creates the transactions associated with the created repeater.

Duplicate repeaters, where both repeaters have exactly the same fields, are not allowed in IchiFund.

The optional arguments take the following default values if left unspecified.

Argument Default values

Category

"Uncategorised"

Type

"exp"

Month Start Offset

"-1" (Offset ignored)

Month End Offset

"-1" (Offset ignored)

Constraints:

  • No duplicate repeater currently exists.

  • Repeater end must not occur before repeater start.

  • Repeater start and end can span at most 60 months (5 years).

  • At least one of month start offset or month end offset must not be ignored.

Examples:

  • add de/Phone bills a/42.15 c/Utilities ty/exp so/3 eo/2 sm/1 sy/2019 em/12 ey/2020
    This creates a repeater titled "Phone bills" as an expenditure for utilities of $42.15 for every third day and second last day of the month, between January 2019 to December 2020. This also creates the transactions associated with the created repeater.

Editing repeater edit

Format: edit INDEX [de/DESCRIPTION] [a/AMOUNT] [c/CATEGORY] [ty/TRANSACTION_TYPE] [so/MONTH_START_OFFSET] [eo/MONTH_END_OFFSET] [sm/START_MONTH] [sy/START_YEAR] [em/END_MONTH] [ey/END_YEAR]

You can use the edit command to edit a repeater. This also edits the transactions associated with the edited repeater.

The repeater fields will only be updated where the arguments are specified.

Constraints:

  • No duplicate repeater currently exists.

  • Repeater end must not occur before repeater start.

  • Repeater start and end can span at most 60 months (5 years).

  • At least one of month start offset or month end offset must not be ignored.

Examples:

  • edit 1 a/31.34 c/Food ty/in so/1 eo/-1 sm/1 sy/2019 em/12 ey/2020
    This edits the first repeater in the current list into a $31.34 expenditure for every first day of the month, between January 2019 and December 2020. This also updates the transactions associated with the edited repeater.

Deleting repeater: delete

Format: delete INDEX

You can use the delete command to delete a repeater. This also deletes all transactions associated with the deleted repeater.

Examples:

  • delete 12
    Deletes the 12th repeater in the current list. This also deletes the transactions associated with the deleted repeater.

Finding repeater: find

Format: find [KEYWORDS]…​

You can use the find command to find repeaters whose description matches any of the (case-insensitive) given keyword(s). If no keyword is specified, then the search filter is cleared.

Examples:

  • find phone john
    This finds all repeaters whose description contains any of the keywords "phone" and "john".

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Repeaters

Repeaters allow for the convenient management of repeated transactions through a single Repeater entity. The list of associated transactions are automatically synchronized to updates in Repeaters. The following class diagram summarizes the details of the Repeater class:

RepeaterClassDiagram
Figure 1. Class Diagram from Repeaters Model

Adding Repeater

This feature allows the user to add a repeater in IchiFund. Adding a repeater also creates the transactions associated with the added repeater.

Implementation

The add command is facilitated by the Logic and Model components of the application. The process of executing an add command is illustrated in the sequence diagram below:

AddRepeaterSequenceDiagram
Figure 2. Sequence Diagram for AddRepeaterCommand

Below is an example usage scenario of how add behaves at each step.

Step 1: In the repeaters tab, the user executes add de/Phone bills a/42.15 c/Utilities ty/exp so/3 eo/2 sd/1 sm/1 sy/2019 ed/31 em/12 ey/2019 to add a repeater for phone bills with an amount of $42.15 on the third and second last day of every month between 1st January 2019 and 31st December 2019.

Step 2: LogicManager uses IchiFundParser#parserCommand() to parse the input from the user.

Step 3: IchiFundParser determines which command is being used and creates the respective AddRepeaterCommandParser parser with the user’s input as an argument.

Step 4: AddRepeaterCommandParser does a validation check on the user’s input.

Step 5: AddRepeaterCommandParser creates and returns an AddRepeaterCommand with the desired Repeater as an arugment.

Step 6: LogicManager calls AddRepeaterCommand#execute().

Step 7: AddRepeaterCommand checks for the following constraints:

  • The Repeater to be added does not already exist in the Model.

  • The end date of the Repeater to be added is no earlier than its start date.

  • The start date and and end date of the Repeater to be added span no more than 60 months.

Step 8: AddRepeaterCommand fetches the running RepeaterUniqueId counter tracked by the Model.

Step 9: AddRepeaterCommand creates the Repeater and sets its unique id as the fetched RepeaterUniqueId.

Step 10: AddRepeaterCommand increments the current RepeaterUniqueId counter in the Model.

Step 11: AddRepeaterCommand adds the newly created Repeater to the Model.

Step 12: AddRepeaterCommand creates the associated Transactions in the Model.

Step 13: AddRepeaterCommand returns a CommandResult to the LogicManager which is returned back to the user.

When creating a Repeater, AddRepeaterCommandParser fills in arguments unspecified by the user with default values, as shown in the activity diagram below:

RepeaterOptionalActivityDiagram
Figure 3. Activity Diagram for Optional Arguments in AddRepeaterCommandParser

Editing Repeater

This feature allows the user to edit a repeater in IchiFund. Editing a repeater also updates the transactions associated with the added repeater.

Implementation

The edit command is facilitated by the Logic and Model components of the application. Given below is an example usage scenario of how edit behaves at each step.

Step 1: In the repeaters tab, the user executes edit 1 a/37.24 so/-1 eo/4 to edit the repeater at the 2nd index for an amount of $37.25, occuring only at the fourth last day of every month.

Step 2: LogicManager uses IchiFundParser#parserCommand() to parse the input from the user.

Step 3: IchiFundParser determines which command is being used and creates the respective EditRepeaterCommandParser parser with the user’s input as an argument.

Step 4: EditRepeaterCommandParser does a validation check on the user’s input.

Step 5: EditRepeaterCommandParser creates an EditRepeaterDescriptor which contains the updated repeater information provided by the user.

Step 6: EditRepeaterCommandParser creates and returns an EditRepeaterCommand with the Index and EditRepeaterDescriptor as arguments.

Step 7: LogicManager executes EditRepeaterCommand#execute().

Step 8: EditRepeaterCommand checks for the following constraints:

  • The updated Repeater does not already exist in the Model.

  • The end date of the updated Repeater is no earlier than its start date.

  • The start date and and end date of the updated Repeater span no more than 60 months.

Step 9: EditRepeaterCommand creates a new Repeater using the original Repeater and the EditRepeaterDescriptor.

Step 10: EditRepeaterCommand replaces the original Repeater in the Model with the newly created Repeater.

Step 11: EditRepeaterCommand deletes all existing associated Transactions from the Model.

Step 12: EditRepeaterCommand creates the Transactions associated with the updated Repeater in the Model.

Step 13: EditRepeaterCommand returns a CommandResult to the LogicManager which is returned back to the user.

Deleting Repeater

This feature allows the user to delete repeater in IchiFund. Deleting a repeater also deletes the transactions associated with the deleted repeater.

Implementation

The delete command is facilitated by the Logic and Model components of the application. Given below is an example usage scenario of how delete behaves at each step.

Step 1: In the repeaters tab, the user executes delete 2 to delete the repeater at the 2nd index.

Step 2: LogicManager uses IchiFundParser#parserCommand() to parse the input from the user.

Step 3: IchiFundParser determines which command is being used and creates the respective DeleteRepeaterCommandParser parser with the user’s input as an argument.

Step 4: DeleteRepeaterCommandParser does a validation check on the user’s input.

Step 5: DeleteRepeaterCommandParser creates and returns a DeleteRepeaterCommand with the desired Index as an argument.

Step 6: LogicManager calls DeleteRepeaterCommand#execute().

Step 7: DeleteRepeaterCommand checks that a Repeater exists at the Index.

Step 8: DeleteRepeaterCommand retrieves the Repeater at the Index from the Model.

Step 9: DeleteRepeaterCommand deletes the Repeater from the Model.

Step 10: DeleteRepeaterCommand deletes all associated Transactions in the Model.

Step 11: DeleteRepeaterCommand returns a CommandResult to the LogicManager which is returned back to the user.

Finding Repeater

This feature allows the user to find repeaters in IchiFund. The search by matching provided keywords against repeater descriptions.

Implementation

The find command is facilitated by the Logic and Model components of the application. Given below is an example usage scenario of how find behaves at each step.

Step 1: In the repeaters tab, the user executes find phone husband to find all repeaters whose descriptions contain any of the keywords "phone" and "husband".

Step 2: LogicManager uses IchiFundParser#parserCommand() to parse the input from the user.

Step 3: IchiFundParser determines which command is being used and creates the respective FindRepeaterCommandParser parser with the user’s input as an argument.

Step 4: FindRepeaterCommandParser does a validation check on the user’s input.

Step 5: FindRepeaterCommandParser creates a RepeaterDescriptionPredicate which filters Repeaters based on whether a Repeater contains all the keywords provided by the user.

Step 6: FindRepeaterCommandParser creates and returns a FindRepeaterCommand with the RepeaterDescriptionPredicate as an arugment.

Step 7: LogicManager calls FindRepeaterCommand#execute().

Step 8: FindRepeaterCommand sets the RepeaterDescriptionPredicate as the filter for the repeater list in the Model.

Step 9: FindRepeaterCommand returns a CommandResult to the LogicManager which is returned back to the user.