IchiFund - Developer Guide

There are two aspects to consider in implementing separate parsing:

In our implementation, we first separate the parsing of commands for different features by delegating them to their respective FeatureParser parsers. The main parser, IchiFundParser, keeps track of all FeatureParser objects, as well as the FeatureParser that is currently in use.

This is illustrated in the object diagram below:

When IchiFundParser parses a command, it first checks whether it is a global command (e.g. help, exit). Otherwise, it passes the command to currentParserManager, which checks if it is a valid command, and passes the arguments to the appropriate Parser.

What remains is determining when to change currentParserManager. Here, we support 3 modes of tab switching:

Users can switch between tabs using specific commands (tx, rep, budget, loan, analytics).

These commands are global commands that are directly recognised by IchiFundParser, which changes currentFeatureParser and the index stored.

Much like the Model data, MainWindow listens to changes to the index through FeatureParserIndexListener. Whenever the value of the index changes, the listener triggers an event to change the tab throw the invalidated() method shown in the code snippet below:

The InvalidationListener constructed from the above code is added to an ObservableValue in MainWindow that tracks the index of the current FeatureParser used, and changes to the appropriate tab using the value of the index stored.

Users can also switch tabs using the shortcut keys Ctrl + 1 to Ctrl + 5. Upon using the shortcut keys, the following handler is triggered:

When handleShowTransaction() is called, currentFeatureParser in IchiFundParser, is set to TransactionFeatureParser, which has a tabIndex of zero. Other handler methods are similar to handleShowTransaction, with the only difference being the index passed to Logic.

The control flow of handleShowTransaction() is illustrated with more details in the sequence diagram below:

As the different FeatureParser objects have different values for tabIndex, a different index is passed, and a different FeatureParser is set as currentFeatureParser.

Users can switch tabs by clicking on the tabs shown in Figure 9, “Feature Tabs in IchiFund”. This triggers a handler, shown in the following code snippet:

The control flow for this handler is similar to that of the shortcut keys.

In designing the specific commands for tab switching, we considered an alternative implementation for passing information about tab switching to Ui.

While Alternative 2 is much simpler to implement, we chose Alternative 1 as we prioritised preserving the independence of Logic from Ui.

This feature is managed by TaskManager. The role of TaskManager is to maintain a list of all active Task.

The LogicManager holds an instance of the TaskManager. When the LogicManager#execute() is called, the following chain of operations occurs:

The transactions in IchiFund are represented using the Transaction class. While users are able to edit transactions, objects of the Transaction class are immutable in the internal structure. The following class diagram summarizes the details of the Transaction class:

In addition, the list of transactions is subject to a filter created by an immutable TransactionContext. TransactionContext keeps track of the Month, Year, Category (optional) and TransactionType (optional) in the current filter. Naturally, this implies that a filter for Month and Year is always applied to the list of transactions. The TransactionContext is also used to fill in optional fields that are not specified by the user when adding transactions.

We summarise the role of the TransactionContext class in the following conceptual class diagram:

We encountered two major decisions when implementing our model for transactions. Here, we discuss the alternatives we considered, as well as the rationale for the current implementation.

We omit the details of parsing facilitated by IchiFundParser, TransactionFeatureParser and FilterTransactionCommandParser. Instead, we immediately delve into the details of FilterTransactionCommand#execute.

As prefaced in Section 4.2.1, “Overview of the Transactions Model”, the filter command interacts with TransactionContext to filter the list of transactions exposed to the UI component. Following the creation of FilterTransactionCommand, the execution of the command results in the following chain of events:

Step 1: FilterTransactionCommand retrieves the current TransactionContext from the model.

Step 2: FilterTransactionCommand creates a new TransactionContext, facilitated by TransactionContextBuilder

Step 3: FilterTransactionCommand sets the new context in model as the newly created TransactionContext.

Step 4: ModelManager retrieves a Predicate<Transaction> from the new TransactionContext.

Step 5: ModelManager filters the list of transactions using the Predicate<Transaction>.

The above sequence of events is shown in greater detail in the following sequence diagram:

We omit the details of parsing facilitated by IchiFundParser, TransactionFeatureParser and AddTransactionCommandParser. Instead, we immediately delve into the details of the AddTransactionCommand#execute.

As prefaced in Section 4.2.1, “Overview of the Transactions Model”, AddTransactionCommand interacts with TransactionContext to generate a Transaction to be added to the model. The execution of an AddTransactionCommand results in the following sequence of events:

Step 1: AddTransactionCommand retrieves the current TransactionContext from the model.

Step 2: AddTransactionCommand generates a new Transaction based on the arguments and TransactionContext

Step 3: AddTransactionCommand adds the new Transaction to the model.

Step 4: ModelManager automatically sorts the list of transactions.

Step 5: AddTransactionCommand calls model to execute updateTransactionContext

Step 6: ModelManager updates TransactionContext such that the new Transaction is shown.

To create a new Transaction, AddTransactionCommand fills in the missing arguments using values obtained from TransactionContext, or default values. This is illustrated in the activity diagram below:

The above activity diagram shows the decision flow for a general optional argument. However, some optional arguments are never stored in TransactionContext, and some are always stored. The following table describes the particular details for each optional argument.

After adding the Transaction, a new TransactionContext is created such that the new Transaction is displayed on the list of transactions. Specifically, the Month and Year filters are set to the Month and Year of the new Transaction respectively, and the Category and TransactionType filters are removed if necessary.

In implementing the add and filter commands, we had to decide on the underlying data structure for the list of transactions. Currently, we store all transactions in a single iterable list. Given the use of a mandatory month and year filter, a natural alternative would be to store each month’s worth of transactions in a list, and stores these lists in another list, forming a multi-level list.

Ultimately, we decided to avoid disrupting the existing architecture, and instead focus our efforts on developing more features to better address the needs of the target user profile.

However, moving forward, we recognise that the current architecture severely lacks scalability, especially given the constantly growing number of transactions we expect users to create. Hence, we eventually intend to switch to a multi-level list.

The execution of the edit command is similar to the delete commands in other components. The following sequence of steps describes the behaviour of EditTransactionCommand at each step:

Step 1: The user executes edit 2 de/Lunch to change the description of the Transaction in the 2nd index to "Lunch".

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

Step 3: IchiFundParser redirects the input to TransactionFeatureParser.

Step 4: TransactionFeatureParser determines which command is being used and creates the respective EditTransactionCommandParser parser with the user’s input as an argument.

Step 5: EditTransactionCommandParser does a validation check on the user’s input.

Step 6: EditTransactionCommandParser creates an EditTransactionDescriptor which contains the updated description information provided by the user.

Step 7: EditTransactionCommandParser creates and returns an EditTransactionCommand with the Index and EditTransactionDescriptor as arguments.

Step 8: LogicManager calls EditTransactionCommand#execute().

Step 9: EditTransactionCommand checks if the Index is too large, and retrieves the appropriate Transaction to be deleted from the Model.

Step 10: EditTransactionCommand checks that the Transaction is not created from a Repeater.

Step 11: EditTransactionCommand creates a new Transaction using the original Transaction and the EditTransactionDescriptor.

Step 12: EditTransactionCommand replaces the original Transaction in the Model with the newly created Transaction.

Step 13: EditTransactionCommand calls Model#updateTransactionContext with the newly created Transaction as an argument.

Step 14: EditTransactionCommand returns a CommandResult to the LogicManager which is returned back to the user.

The execution of the delete command is similar to the delete commands in other components. The following sequence of steps describes the behaviour of DeleteTransactionCommand at each step:

Step 1: The user executes delete 2 to delete the Transaction in the 2nd index.

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

Step 3: IchiFundParser redirects the input to TransactionFeatureParser.

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

Step 4: DeleteTransactionCommandParser does a validation check on the user’s input before creating and returning a DeleteRepeaterCommand with desired Index as an argument.

Step 5: LogicManager calls DeleteTransactionCommand#execute()

Step 6: DeleteTransactionCommand checks if the Index is too large, and retrieves the appropriate Transaction to be deleted from the Model.

Step 7: DeleteTransactionCommand checks that the Transaction is not created from a Repeater.

Step 8: DeleteTransactionCommand deletes the Transaction from the Model.

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

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:

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:

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:

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:

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.

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.

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.

When the user input the add command in the Budget tab, the following chain of operations occurs:

This process is further illustrated in the following sequence diagram:

Analytical data in IchiFund is represented using the Data class. Objects of the Data class are immutable in the internal structure. The following class diagram summarizes the details of the Data class:

In addition, analytical data associated with a command is initially stored in a Report. Using polymorphism, this report is initialised as either a TrendReport or a BreakdownReport depending on the command that was executed. The following class diagram summarizes the details of the Report class:

After the user inputs the expenditure command in the Analytics tab, the following chain of operations occurs:

Step 1: The IchiFundParser will delegate the parsing of the command to AnalyticsFeatureParser if the current active tab is Analytics.

Step 2: The AnalyticsFeatureParser will delegate the parsing of the arguments to ExpenditureTrendCommandParser.

Step 3: ExpenditureTrendCommandParser#parse() will take in a String input consisting of the arguments.

Step 4: This arguments will be tokenized and the respective models for each argument are created.

Step 5: If the parsing of all arguments are successful, a new ExpenditureTrendCommand is returned back to LogicManager.

Step 6: The LogicManager executes ExpenditureTrendCommand#execute().

Step 7: The model is updated with the List of Data from the newly created TrendReport.

The above sequence of events is shown in greater detail in the following sequence diagram:

The details of the fill trend report interactions have been omitted from the diagram above, and are shown in the following separate sequence diagram:

In addition, this activity diagram shows the action sequence for one iteration of the internal for-loop for the execution of the fillExpenditureTrendReport method of an ExpenditureTrendCommand.

When the user input the income command in the Analytics tab, the following chain of operations occurs:

Step 1. The IchiFundParser will delegate the parsing of the command to AnalyticsFeatureParser if the current active tab is Analytics.

Step 2. The AnalyticsFeatureParser will delegate the parsing of the arguments to IncomeTrendCommandParser.

Step 3. IncomeTrendCommandParser#parse() will take in a String input consisting of the arguments.

Step 4. This arguments will be tokenized and the respective models for each argument are created.

Step 5. If the parsing of all arguments are successful, a new IncomeTrendCommand is returned back to LogicManager.

Step 6. The LogicManager executes IncomeTrendCommand#execute().

Step 7. The model is updated with the List of Data from the newly created TrendReport.

When the user input the balance command in the Analytics tab, the following chain of operations occurs:

The following activity diagram shows the action sequence for one iteration of the internal for-loop for the execution of the fillBalanceTrendReport method of an BalanceTrendCommand.

When the user input the breakdown command in the Analytics tab, the following chain of operations occurs:

Step 1. The IchiFundParser will delegate the parsing of the command to AnalyticsFeatureParser if the current active tab is Analytics.

Step 2. The AnalyticsFeatureParser will delegate the parsing of the arguments to BreakdownCommandParser.

Step 3. BreakdownCommandParser#parse() will take in a String input consisting of the arguments.

Step 4. This arguments will be tokenized and the respective models for each argument are created.

Step 5. If the parsing of all arguments are successful, a new BreakdownCommand is returned back to LogicManager.

Step 6. The LogicManager executes BreakdownCommand#execute().

Step 7. The model is updated with the List of Data from the newly created BreakdownReport.

When the user input the catrank command in the Analytics tab, the following chain of operations occurs:

Step 1. The IchiFundParser will delegate the parsing of the command to AnalyticsFeatureParser if the current active tab is Analytics.

Step 2. The AnalyticsFeatureParser will delegate the parsing of the arguments to CategoryRankingCommandParser.

Step 3. CategoryRankingCommandParser#parse() will take in a String input consisting of the arguments.

Step 4. This arguments will be tokenized and the respective models for each argument are created.

Step 5. If the parsing of all arguments are successful, a new CategoryRankingCommand is returned back to LogicManager.

Step 6. The LogicManager executes CategoryRankingCommand#execute().

Step 7. The model is updated with the List of Data from the newly created BreakdownReport.

When the user input the mthrank command in the Analytics tab, the following chain of operations occurs:

Step 1. The IchiFundParser will delegate the parsing of the command to AnalyticsFeatureParser if the current active tab is Analytics.

Step 2. The AnalyticsFeatureParser will delegate the parsing of the arguments to MonthlyExpenditureRankingCommandParser.

Step 3. MonthlyExpenditureRankingCommandParser#parse() will take in a String input consisting of the arguments.

Step 4. This arguments will be tokenized and the respective models for each argument are created.

Step 5. If the parsing of all arguments are successful, a new MonthlyExpenditureRankingCommand is returned back to LogicManager.

Step 6. The LogicManager executes MonthlyExpenditureRankingCommand#execute().

Step 7. The model is updated with the List of Data from the newly created TrendReport.

When the user input the exprank command in the Analytics tab, the following chain of operations occurs:

Step 1. The IchiFundParser will delegate the parsing of the command to AnalyticsFeatureParser if the current active tab is Analytics.

Step 2. The AnalyticsFeatureParser will delegate the parsing of the arguments to ExpenditureRankingCommandParser.

Step 3. ExpenditureRankingCommandParser#parse() will take in a String input consisting of the arguments.

Step 4. This arguments will be tokenized and the respective models for each argument are created.

Step 5. If the parsing of all arguments are successful, a new ExpenditureRankingCommand is returned back to LogicManager.

Step 6. The LogicManager executes ExpenditureRankingCommand#execute().

Step 7. The model is updated with the List of Data from the newly created TrendReport.

This feature allows the user to add a loan in IchiFund. Adding a loan also creates the default values associated with the added loan.

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

Step 1: The user executes add a/42.15 d/Utilities sd/1 sm/1 sy/2019 ed/31 em/12 ey/2019 to add a loan for utilities with an amount of $42.15 taken on 1st January 2019 and to be returned on 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 AddLoanCommandParser parser with the user’s input as an argument.

Step 4: AddLoanCommandParser does a validation check on the user’s input before creating and returning an AddLoanCommand with desired Loan as an argument.

Step 5: LogicManager uses AddLoanCommand#execute() to add the Loan and the associated Loans into the Model which is handled by ModelManager. In doing so, it also fetches the LoanId counter tracked by the Model, sets it as the created Repeater's unique id, and increments the counter in the Model by 1.

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

This feature allows the user to pay off a marked loan in IchiFund by index.

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

Step 1: The user executes pay 2 to pay off the loan in 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 PayLoanCommandParser parser with the user’s input as an argument.

Step 4: PayLoanCommandParser does a validation check on the user’s input before creating and returning an PayLoanCommand with desired Index as an argument.

Step 5: LogicManager uses PayLoanCommand#execute() to delete the Loan from the Model which is handled by ModelManager.

Step 6: PayLoanCommand returns a CommandResult to the LogicManager which is returned back to the user.