Savee - Developer Guide

By: Team T09-4 Since: Aug 2018 Licence: MIT

1. Setting up
2. Design
3. Implementation
4. Documentation
5. Testing
6. Dev Ops
Appendix A: Suggested Programming Tasks to Get Started
- A.1. Improving each component
- A.2. Creating a new command: remark
Appendix B: Product Scope
Appendix C: User Stories
Appendix D: Use Cases
Appendix E: Non Functional Requirements
Appendix F: Glossary
Appendix G: Product Survey
Appendix H: Instructions for Manual Testing

1. Setting up

1.1. Prerequisites

JDK 9 or later

JDK 10 on Windows will fail to run tests in headless mode due to a JavaFX bug. Windows developers are highly recommended to use JDK 9.
IntelliJ IDE

IntelliJ by default has Gradle and JavaFx plugins installed.
Do not disable them. If you have disabled them, go to File > Settings > Plugins to re-enable them.

1.2. Setting up the project in your computer

Fork this repo, and clone the fork to your computer
Open IntelliJ (if you are not in the welcome screen, click File > Close Project to close the existing project dialog first)
Set up the correct JDK version for Gradle
1. Click Configure > Project Defaults > Project Structure
2. Click New… and find the directory of the JDK
Click Import Project
Locate the build.gradle file and select it. Click OK
Click Open as Project
Click OK to accept the default settings
Open a console and run the command gradlew processResources (Mac/Linux: ./gradlew processResources). It should finish with the BUILD SUCCESSFUL message.
This will generate all resources required by the application and tests.

1.3. Verifying the setup

Run the seedu.planner.MainApp and try a few commands
Run the tests to ensure they all pass.

1.4. Configurations to do before writing code

1.4.1. Configuring the coding style

This project follows oss-generic coding standards. IntelliJ’s default style is mostly compliant with ours but it uses a different import order from ours. To rectify,

Go to File > Settings… (Windows/Linux), or IntelliJ IDEA > Preferences… (macOS)
Select Editor > Code Style > Java
Click on the Imports tab to set the order
- For Class count to use import with '*' and Names count to use static import with '*': Set to 999 to prevent IntelliJ from contracting the import statements
- For Import Layout: The order is import static all other imports, import java.*, import javax.*, import org.*, import com.*, import all other imports. Add a <blank line> between each import

Optionally, you can follow the UsingCheckstyle.adoc document to configure Intellij to check style-compliance as you write code.

1.4.2. Updating documentation to match your fork

After forking the repo, the documentation will still have the SE-EDU branding and refer to the se-edu/addressbook-level4 repo.

If you plan to develop this fork as a separate product (i.e. instead of contributing to se-edu/addressbook-level4), you should do the following:

Configure the site-wide documentation settings in build.gradle, such as the site-name, to suit your own project.
Replace the URL in the attribute repoURL in DeveloperGuide.adoc and UserGuide.adoc with the URL of your fork.

1.4.3. Setting up CI

Set up Travis to perform Continuous Integration (CI) for your fork. See UsingTravis.adoc to learn how to set it up.

After setting up Travis, you can optionally set up coverage reporting for your team fork (see UsingCoveralls.adoc).

Coverage reporting could be useful for a team repository that hosts the final version but it is not that useful for your personal fork.

Optionally, you can set up AppVeyor as a second CI (see UsingAppVeyor.adoc).

Having both Travis and AppVeyor ensures your App works on both Unix-based platforms and Windows-based platforms (Travis is Unix-based and AppVeyor is Windows-based)

1.4.4. Getting started with coding

When you are ready to start coding,

Get some sense of the overall design by reading Section 2.1, “Architecture”.
Take a look at Appendix A, Suggested Programming Tasks to Get Started.

2. Design

2.1. Architecture

Figure 1. Architecture Diagram

The Architecture Diagram given above explains the high-level design of the App. Given below is a quick overview of each component.

The .pptx files used to create diagrams in this document can be found in the diagrams folder. To update a diagram, modify the diagram in the pptx file, select the objects of the diagram, and choose Save as picture.

Main has only one class called MainApp. It is responsible for,

At app launch: Initializes the components in the correct sequence, and connects them up with each other.
At shut down: Shuts down the components and invokes cleanup method where necessary.

Commons represents a collection of classes used by multiple other components. Two of those classes play important roles at the architecture level.

EventsCenter : This class (written using Google’s Event Bus library) is used by components to communicate with other components using events (i.e. a form of Event Driven design)
LogsCenter : Used by many classes to write log messages to the App’s log file.

The rest of the App consists of four components.

UI: The UI of the App.
Logic: The command executor.
Model: Holds the data of the App in-memory.
Storage: Reads data from, and writes data to, the hard disk.

Each of the four components

Defines its API in an interface with the same name as the Component.
Exposes its functionality using a {Component Name}Manager class.

For example, the Logic component (see the class diagram given below) defines it’s API in the Logic.java interface and exposes its functionality using the LogicManager.java class.

Figure 2. Class Diagram of the Logic Component

Events-Driven nature of the design

The Sequence Diagram below shows how the components interact for the scenario where the user issues the command delete 1.

Figure 3. Component interactions for delete 1 command (part 1)

Note how the Model simply raises a FinancialPlannerChangedEvent when the Financial Planner data are changed, instead of asking the Storage to save the updates to the hard disk.

The diagram below shows how the EventsCenter reacts to that event, which eventually results in the updates being saved to the hard disk and the status bar of the UI being updated to reflect the 'Last Updated' time.

Figure 4. Component interactions for delete 1 command (part 2)

Note how the event is propagated through the EventsCenter to the Storage and UI without Model having to be coupled to either of them. This is an example of how this Event Driven approach helps us reduce direct coupling between components.

The sections below give more details of each component.

2.2. UI component

Figure 5. Structure of the UI Component

API : Ui.java

The UI consists of a MainWindow that is made up of parts e.g.CommandBox, ResultDisplay, PersonListPanel, StatusBarFooter, WelcomePanel etc. All these, including the MainWindow, inherit from the abstract UiPart class.

The UI component uses JavaFx UI framework. The layout of these UI parts are defined in matching .fxml files that are in the src/main/resources/view folder. For example, the layout of the MainWindow is specified in MainWindow.fxml

The UI component,

Executes user commands using the Logic component.
Binds itself to some data in the Model so that the UI can auto-update when data in the Model change.
Responds to events raised from various parts of the App and updates the UI accordingly.

2.3. Logic component

Figure 6. Structure of the Logic Component

API : Logic.java

Logic uses the FinancialPlannerParser class to parse the user command.
This results in a Command object which is executed by the LogicManager.
The command execution can affect the Model (e.g. adding a record) and/or raise events.
The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

Given below is the Sequence Diagram for interactions within the Logic component for the execute("delete 1") API call.

Figure 7. Interactions Inside the Logic Component for the delete 1 Command

2.4. Model component

Figure 8. Structure of the Model Component

API : Model.java

The Model,

stores a UserPref object that represents the user’s preferences.
stores the Financial Planner data.
exposes an unmodifiable ObservableList<Record> that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
exposes an unmodifiable ObservableList<Limit> that can be observed
contains a FilteredList<Record> of all records in the current month which is updated automatically and has listeners bound to it that will notify the Ui of any changes
does not depend on any of the other three components.

As a more OOP model, we can store a Tag list in Financial Planner, which Record can reference. This would allow Financial Planner to only require one Tag object per unique Tag, instead of each Person needing their own Tag object. An example of how such a model may look like is given below.

2.5. Storage component

Figure 9. Structure of the Storage Component

API : Storage.java

The Storage component,

can save UserPref objects in json format and read it back.
can save the RecordList data in xml format and read it back.
can save the LimitList data in xml format and read it back.

2.6. Common classes

Classes used by multiple components are in the seedu.planner.commons package.

3. Implementation

This section describes some noteworthy details on how certain features are implemented.

3.1. Undo/Redo feature

3.1.1. Current Implementation

The undo/redo mechanism is facilitated by VersionedFinancialPlanner. It extends FinancialPlanner with an undo/redo history, stored internally as an financialPlannerStateList and currentStatePointer. Additionally, it implements the following operations:

VersionedFinancialPlanner#commit() — Saves the current financial planner state in its history.
VersionedFinancialPlanner#undo() — Restores the previous financial planner state from its history.
VersionedFinancialPlanner#redo() — Restores a previously undone financial planner state from its history.

These operations are exposed in the Model interface as Model#commitFinancialPlanner(), Model#undoFinancialPlanner() and Model#redoFinancialPlanner() respectively.

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.

Step 1. The user launches the application for the first time. The VersionedFinancialPlanner will be initialized with the initial financial planner state, and the currentStatePointer pointing to that single financial planner state.

Step 2. The user executes delete 5 command to delete the 5th person in the financial planner. The delete command calls Model#commitFinancialPlanner(), causing the modified state of the financial planner after the delete 5 command executes to be saved in the financialPlannerStateList, and the currentStatePointer is shifted to the newly inserted financial planner state.

Step 3. The user executes add n/Mala … to add a new record. The add command also calls Model#commitFinancialPlanner(), causing another modified financial planner state to be saved into the financialPlannerStateList.

If a command fails its execution, it will not call Model#commitFinancialPlanner(), so the financial planner state will not be saved into the financialPlannerStateList.

Step 4. The user now decides that adding the record was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undoFinancialPlanner(), which will shift the currentStatePointer once to the left, pointing it to the previous financial planner state, and restores the financial planner to that state.

If the currentStatePointer is at index 0, pointing to the initial financial planner state, then there are no previous financial planner states to restore. The undo command uses Model#canUndoFinancialPlanner() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo.

The following sequence diagram shows how the undo operation works:

The redo command does the opposite — it calls Model#redoFinancialPlanner(), which shifts the currentStatePointer once to the right, pointing to the previously undone state, and restores the financial planner to that state.

If the currentStatePointer is at index financialPlannerStateList.size() - 1, pointing to the latest financial planner state, then there are no undone financial planner states to restore. The redo command uses Model#canRedoFinancialPlanner() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.

Step 5. The user then decides to execute the command list. Commands that do not modify the financial planner, such as list, will usually not call Model#commitFinancialPlanner(), Model#undoFinancialPlanner() or Model#redoFinancialPlanner(). Thus, the financialPlannerStateList remains unchanged.

Step 6. The user executes clear, which calls Model#commitFinancialPlanner(). Since the currentStatePointer is not pointing at the end of the financialPlannerStateList, all financial planner states after the currentStatePointer will be purged. We designed it this way because it no longer makes sense to redo the add n/David … command. This is the behavior that most modern desktop applications follow.

The following activity diagram summarizes what happens when a user executes a new command:

3.1.2. Design Considerations

Aspect: How undo & redo executes

Alternative 1 (current choice): Saves the entire financial planner.
- Pros: Easy to implement.
- Cons: May have performance issues in terms of memory usage.
Alternative 2: Individual command knows how to undo/redo by itself.
- Pros: Will use less memory (e.g. for delete, just save the person being deleted).
- Cons: We must ensure that the implementation of each individual command are correct.

Aspect: Data structure to support the undo/redo commands

Alternative 1 (current choice): Use a list to store the history of financial planner states.
- Pros: Easy for new Computer Science student undergraduates to understand, who are likely to be the new incoming developers of our project.
- Cons: Logic is duplicated twice. For example, when a new command is executed, we must remember to update both HistoryManager and VersionedFinancialPlanner.
Alternative 2: Use HistoryManager for undo/redo
- Pros: We do not need to maintain a separate list, and just reuse what is already in the codebase.
- Cons: Requires dealing with commands that have already been undone: We must remember to skip these commands. Violates Single Responsibility Principle and Separation of Concerns as HistoryManager now needs to do two different things.

3.2. Auto Complete Feature

3.2.1. Current Implementation

The autocomplete mechanism is facilitated by the NewAutoCompletionBinding class. It represents the binding of the autocomplete window to the CommandBox and is the component that manages the interactions between the text input and the contents of the autocomplete list that is displayed in the window. This feature observes the text input in the CommandBox and displays a list of words in another window under the CommandBox for the user to select and complete his current focus text - the word he is currently typing.

The key components in this class are the autoCompletionPopup and the caretChangedListener that perform the key functionalities.

caretChangedListener is an observer that checks the caret in the command box and is triggered whenever the caret changes its position, whether a character is typed or the caret is moved using the arrow keys. When triggered, it reads the text in the command box and checks the position of the caret, then extracts the current word of target to be completed as well as the current input text and the prefix of the current word if any. Extraction is done by tracing back from the caret position and as well as tracing forward. Any characters that are not a whitespace and are not separated by a whitespace are considered to be the same word as the current word to be completed. The text before and after the word to completed are also saved so they will not be lost upon completion.

This listener passes the extracted String input to the CustomSuggestionProvider through updateSuggestions.

CustomSuggestionProvider reads the word to be competed and the input text. It trims and splits the input text and find the index of the word to completed. It reads the first input first as it is the key command word and performs a different operation on the input string depending on the command word as well as any possible following parameters.

Functions which are supported by autocomplete will parse the input individually through the different private methods available in CustomSuggestionProvider. Once it has decided which set of texts to be the new word suggestion bank, it calls the CustomSuggestionProvider#updateSuggestions overloaded method to update the SuggestionProvider.

After updating the SuggestionProvider, NewAutoCompletionBinding#SetUserInput calls onUserInputChanged which is responsible for updating the suggestions list according to what the word to be completed is. As this class was tweaked from the library implementation, the threading involved in this method will not be detailed. It updates the list of suggestions by comparing the user input word to the list of suggestions and passes the resultant list to the autoCompletionPopup which will proceed to display the list of text in the popup below the command box.

Now back to the autoCompletionPopup, whenever the user highlights a selected word input and selects it, the autoCompletionPopup#setOnSuggestion is triggered and will try to complete the word with the selected text and once completed, it hides the popup and sets the caret to the end of the newly completed word.

The following sequence diagram shows how the auto completion operation works:

3.2.2. Design Considerations

Aspect: Method to Update Suggestion Bank to use for comparison to input word

Alternative 1 (current choice): Use listeners to the caret in the command box
- Pros: Accurate parsing of input and able to detect which word is currently in focus.
- Cons: Difficult to correctly parse text, as need to avoid whitespaces. Also led to many index array exceptions that can occur when checking the input.
Alternative 2: Use text listeners in the command box
- Pros: Simple to implement, similar to library implementation. Safe and minimal room for errors.
- Cons: Cannot autocomplete by word, can only complete the last word input in the command box. Unable to perform completion for texts before the last word.

Aspect: Method to compare input word to Suggestion Bank to obtain displayed list of words

Alternative 1 (current choice): Check if suggestion bank word begins with input word
- Pros: Simple, straightforward autocomplete for users. Users that are already good at typing and spelling will have a breeze using this implementation.
- Cons: Smaller range of completion texts as users need to accurately type the first few letters before getting a an expected completion suggestion.
Alternative 2: Check if suggestion bank word contains input word e.g type tag → suggests findtag
- Pros: User can type whichever word is convenient to them to obtain a suggestion they desire. Users who may not know the full spelling of a word and only partially will enjoy this.
- Cons: Range of texts displayed may be excessive and not appealing to all users.

3.3. List history feature

3.3.1. Current Implementation

The list mechanism is facilitated by ModelManager. It represents an in-memory model of the FinancialPlanner and is the component which manages the interactions between the commands and the VersionedFinancialPlanner. ListCommand calls ModelManager#updateFilteredRecords and passes in different predicates depending on the argument mode.

This feature has only one keyword list but implements 3 different argument modes to allow users to access multiple versions of the same command. The three argument modes are as listed below:

No Argument mode — Requires no arguments and returns the entire list of records in the FinancialPlanner.
Single Argument mode — Requires a single date and returns all records containing that date
Dual Argument mode — Requires 2 dates, a start date and an end date. It returns all records containing dates within the time frame of start date and end date, inclusive of both start date and end date The mechanism that facilitates these modes can be found in the ListCommandParser#parse. Below is a overview of the mechanism:
1. The input given by the user is passed to ArgumentTokeniser#tokenise to split the input separated by prefixes which returns a ArgumentMultiMap which contains a map with prefixes as keys and their associated input arguments as the value.
2. The string associated with d/ is then passed into ListCommandParser#splitByWhitespace for further processing and returns an array.
3. The argument mode is determined by the size of this array and the elements are further processed into Date objects, before creating and returning a ListCommand object.

The ListCommand has two constructors which makes use of overloading to reduce code complexity, one with no argument and the other one with 2 Date arguments.

The following sequence diagram shows how the list operation works:

For simplicity, interactions with the UI is not shown in the diagram above.
The update of the UI RecordListPanel is done through the event system. FilteredList is a type of ObservableList implemented by the Java 8 API and it will propagate any changes to the list to any listeners listening to it. This listener is present in RecordListPanel and will update the UI list automatically.

3.3.2. Design Considerations

Aspect: Data structure to support listing of records

Alternative 1 (current choice): Uses a FilteredList that is tracked by the UI. FilteredLIst is a wrapper around the ObservableList<Record> that is stored in UniquePersonList which allows for any changes in the observable list to be propagated to the filtered list automatically.
- Pros: Easy to implement
- Cons: May take a significantly longer time to list records if there are many records spanning across a large timeframe.
Alternative 2: Implement a HashMap with Date as the key and Record as the value.
- Pros: Allows for constant time complexity to access any elements. Hence, listing records can potentially be faster.
- Cons: Current UI implementation relies on FilteredList. In order for UI to be compatible with the new data structure, the UI may need to change its implementation to ObservableMap instead. Alternatively, one can utilise a HashMap to first generate the list and pass the list reference into FilteredList. However, there is a need to code a filter function.

3.4. Sort records feature

3.4.1. Current Implementation

The sort mechanism is facilitated by ModelManager. It extends FinancialPlanner with a component that sorts the internal list of records. SortCommand calls ModelManager#sortFilteredRecordList and passes in the category to be sorted by and the sort order.

This feature has one keyword sort and takes in arguments of either category or order of sort. Keywords are not case sensitive.

Category can be either of the following keywords: name, date, money, moneyflow

Order can be either of the following keywords: desc - descending, asc - ascending

This feature has 2 different kind of modes as follows:

Single Argument Mode - Input argument can be either the category or the order of sort
- If category specified, records are sorted in ascending order of that category
- If order specified, records will be sorted by name in the specified order
Duo Argument Mode - Input arguments must contain only 1 category and only 1 order, and can be input in no particular order

The input given by the user is passed to SortCommandParser to split the input separated by whitespaces to ensure there is either only one or two arguments input by the user. These arguments are stored in an array of strings and the size of the array determines the mode of the command.

The strings are compared to two sets of strings containing the supported categories and orders of the function. The string of the category and a boolean representing whether the records are to be reversed will then be passed to ModelManager to sort the records.

Since the displayed list in the UI is a FilteredList which is a wrapper for the underlying list UniqueRecordList structure, sorting the internal list of records in versionedFinancialPlanner will post an event that notifies the UI to update the displayed list.

The following sequence diagram shows how the sort operation works:

3.4.2. Design Considerations

Aspect: Method of sorting data

Alternative 1 (current choice): Sort the observable array list in the underlying data structure in UniqueRecordList
- Pros: Easy to implement, sorting will be permanent, user need not sort again with every following command
- Cons: Not very intuitive, user may not have intended to modify the underlying data arrangement instead only want to sort the data just this once for viewing
Alternative 2: Sort the FilteredList of records obtained after filtering the underlying array list
- Pros: Does not allow the user to alter the arrangement of the underlying data, and only obtains a sorted version of the read only data.
- Cons: Unable to sort a FilteredList as it does not support it, implementations could instead use SortedList but it will not be able to perform the filtering function

3.5. View summary feature

This feature allows the user to view a summary table of all their financial activity within a period of time. There are 3 different ways the user can view the summary, one is summary by date which means the summary of each day in the period will be provided, summary by month or summary by category.

The corresponding command required for this feature is summary and the user will have to supply 2 dates and a compulsory parameter mode which determines whether they are viewing summary by date, by month or by category. This feature involves most components of FinancialPlanner with the exception of Storage. It can also be broadly split into 2 phases, the logic phase which generates the summary and the UI phase which allows users to view the summary in a table.

As shown below, SummaryByDateCommand, SummaryByCategoryCommand, SummaryByMonthCommand is a type of SummaryCommand and thus inherits from SummaryCommand. The rationale behind this design choice is that code shared by these classes can be placed in SummaryCommand for code reuse. This makes it easier for future developers to easily extend this functionality.

Figure 10. Class diagram showing the inheritance from SummaryCommand

Also, these commands utilise their own version of summary lists which is also inherited from the parent class SummaryList as shown below. Below details the logic phase.

When the user types in the command "summary date d/1-1-2018 12-12-2018", the command is passed from LogicManager to FinancialPlannerParser. In here, the system chooses which parser to use and calls its parse method which is polymorphic, meaning that every parser has the same function but use different implementation.
In this class, based on the mode parameter given, the system chooses a SummaryCommand to instantiate and pass the reference back to the Logic Manager. The various checks for the validity of the parameters also occur during this stage.
After the SummaryCommandObject is created, SummaryByDateCommand#execute is called. The responsibility of SummaryByDateCommand is a manager that has retrieves information from model and passes it to other components. SummaryByDateCommand gets the filtered list from Model using Model#getFilteredRecordList and passes it to the constructor of SummaryByDateList. The creates SummaryList object which is then passed into a ShowSummaryTableEvent before triggering the event.
The entire logic process is the same for SummaryByMonthCommand and SummaryByCategoryCommand but uses different lists.

The sequence diagram below details the sequence of program executions for the logic phase.

Figure 11. Sequence diagram for high level interactions in logic phase

The next phase of the program execution is performed in the UI components.

MainWindow will listen for the ShowSummaryTableEvent and render all Main UI panels invisible before rendering StatsDisplayPanel visible.
It then calls the handler function in StatsDisplayPanel which will create tabs and call the constructor of SummaryDisplay.
Within the constructor of SummaryDisplay, the table is created and the SummaryList is converted into a Ui friendly list.

3.5.1. Design Considerations

Aspect: Method of generating the summary

Alternative 1 (current choice): Generate the summary list whenever the summary command is called.
- Pros: Easier to implement and maintain. Sufficient for the intended target audience of FinancialPlanner.
- Cons: This requires looping through each record in the filtered record list obtained from the Model. To aid in the time complexity, the internal implementation of SummaryList was done using hash maps instead which allowed for constant time random access.. However, the initial filtering is close to linear time complexity which could slow down the app if many records are inside. Also, the list had to be created every time summary is called which could be slow if the command is called multiple times.
Alternative 2: Morph the record list into a record hash map of record lists instead
- Pros: A hash map allows for constant random access to a record list of a particular date assuming the key for the hash map is using dates. Thus, the filtering function does not need to loop through as many records and the time taken would be lower especially when the database in the application is large.
- Cons: Might be too specific to only 1 type of category like categorising by date. If any other types are required, another map may have to be added. This implementation may make the system rigid and hard to modify in the future.
Alternative 3: Cache the summary list in financial planner
- Pros: By caching the summary list in the financial planner and assigning a boolean variable along with information on the filter predicate to it to determine if it is modified, we can reduce the number of times summary list is recreated every time the summary command is called. When the summary command is called, it checks the boolean variable to see if summary list needs to be modified. If it doesn’t need to be regenerated, the system will simply read directly from ModelManager.
- Cons: This implementation involves tracking of the state of the summary list. If it is not done systematically, it may have some hidden bugs which can be hard to test. Also, if the sequence of commands is as follows, summary, add, summary, the time required is still long.

3.5.2. Aspect: Method of switching UI panels

Alternative 1(current choice): Disable all UI panels within the Main UI placeholder before enabling the desired one
- Pros: Easy to implement and apply it to other newly created panels. To make use of the current implementation, the panel can simply be the children of the main Ui placeholder and its event handler can be placed in main window.
- Cons: Might be inefficient when there are many panels or many switching as the same process must be repeated for all panels. However, this is unrealistic and it is unlikely that there are a lot of UI panels for it to make a significant impact.
Alternative 2: Track which UI panel is visible and only hide that panel
- Pros: Might have some benefits if the amount of resources available is low
- Cons: Slightly harder to implement but unlikely to have visible benefits.

3.6. View category breakdown feature

3.6.1. Current Implementation

This feature allows the user to view a pie chart breakdown o f all expenses and all income within a date range which the user can specify.

The corresponding command required for this feature is stats.For this feature, users have to enter 2 dates, one starting date and one ending date. This feature is facilitated by a few key components of FinancialPlanner, Logic, Model, UI and function executions can be split into 2 phases, the Logic phase and the UI phase. The detailed execution sequence of functions used for Logic phase are as shown below.

Figure 12. Sequence diagram for high level interactions in logic phase

Consider the situation where the user enters "stats d/1-1-2018 12-12-2018":

When user enters the command, the LogicManager recognises the command and calls the FinancialPlannerParser to process the new command as shown above.
The FinancialPlannerParser will then search for the stats keyword required and once it is found, the rest of the command minus the keyword is passed in as a parameter to StatisticCommandParser.
The StatisticCommandParser will then parse the arguments and create a new StatisticCommand object before returning its reference. The activity diagram below details the mechanism within the StatisticCommandParser#parse method.

Figure 13. Activity diagram for details in StatisticCommandParser

Once StatisticCommand#execute is called, it will then search through the in-memory data of FinancialPlanner and return a list containing all records within the date range and including both the start dates and end dates. This functionality is facilitated by the ModelManager which is the class that manages all interactions between Logic and Model component, by`ModelManager#updateFilteredRecords`. The command then retrieves the filteredList from ModelManager and passes it into the constructor of CategoryStatisticsList.
In this constructor, it will loop through all the records in the list and add them into an internal map. The internal data structure in CategoryStatisticsList is a hash map, to aid in the adding process, however it only outputs lists and not the map. This functionality is facilitated by CategoryStatisticsList#addToCategoryStatistics which checks whether the record is in the map.
If the record is not present, it creates a new CategoryStatistic object and adds that to the map. If the record is present, the record is then added to the existing CategoryStatistic object.
The flow of control returns to StatisticCommand and StatisticCommand calls the read function of CategoryStatisticsList to obtain a read-only list and passes it into an event constructor before posting the event ShowPieChartStatsEvent.

After the event is posted, the execution proceeds to the UI phase where there is a listener in MainWindow listening to this event. This is facilitated by the event system in FinancialPlanner. The sequence diagram below details the program flow of the functions executed in UI phase for creating the pie chart for total expense.

Figure 14. Sequence diagram for high level interactions in UI phase

When the event is caught by the listener in MainWindow, MainWindow looks through all children of the MainWindow#mainUiPanelPlaceholder and executes the hide function in them. This will make all children hidden from view in the UI which ensures that the UI is displayed correctly.
As shown above, the function StatsDisplayPanel#handleShowPieChartDataEvent is called which will call the constructor of MixedPieChartData. The detailed execution details within this class is as shown in the activity diagram below.

Figure 15. Activity diagram for details in MixedPieChartDataList

The program flow is then as shown above where the CategoryBreakdown is created and instantiated with 2 lists, one being expenseLabelData and other being expenseLegendData. In the current implementation, whenever stats is called, 2 tabs will be created, one for total income and one for total expense. Thus, the same program sequence after construction for CategoryBreakdown is also repeated for total income.

The sequence diagram below details the program flow after the constructor of CategoryBreakdown class is called.

Figure 16. Sequence diagram for creation of pie charts

Note that the CustomLegend class is located within the CustomPieChart class which inherits from the JavaFX PieChart class. This legend class can only be accessed within CustomPieChart for security purposes.

3.6.2. Design Considerations

Aspect: Data structure to support statistic command

Alternative 1 (current choice): The pie chart breakdown is regenerated from the filtered list every time this command is called.
- Pros: Reduce overhead during normal operations like adding, deleting and editing if we do not have to update the statistics in real time.
- Cons: If the command is called multiple times, this process could be repeated many times which may make the app sluggish when there are many records.
Alternative 2: Use a data structure to store the statistic information when there is mutation of data
- Pros: Since the statistics are constantly updated, whenever the command is called, system can read directly and not have to recompute.
- Cons: Adds overhead to usual operations. Benefits may not be visible if the command is not called frequently.

3.7. View current month’s breakdown

This feature does not require user to type any command into the command box or update manually. It provides information about the category breakdown for the current month, presenting income and expense statistics together in one panel. In addition, to improve usability, accelerators were assigned to the menu bar and HOME key is the corresponding accelerator for this feature.

The current implementation of this feature closely follows the observer design pattern. Whenever the system detects changes to the underlying list, like adding, deleting or editing records, it updates a listener which is attached to the FilteredList recordsInCurrentMonth present in ModelManager. To check if the current month is the same as the cached month, the listener will run a check by creating a separate DateIsWithinIntervalPredicate and comparing it with the current Predicate of the filtered list. This listener will then process changes in the list and compute a CategoryStatisticsList before passing it into the constructor of UpdateWelcomePanelEvent. Then the event is triggered, and the corresponding listener on the UI side is called.

The program flow on the UI side is similar to that of viewing category breakdown of a time period with the exception that tabs are not created.

The accelerators and the menu bar is connected to the UI component and will trigger MainWindow#handleHome whenever the accelerator HOME key or Home is selected using the menu.

3.8. Find records by tag feature

3.8.1. Current Implementation

The findtag mechanism is also facilitated by ModelManager. FindTagCommand calls ModelManager#updateFilteredRecords and passes in different predicates depending on the input by the user.

This feature has only one keyword findtag and a single working mode which takes in any number of input arguments. The input given by the user is passed to FindTagCommandParser#parse to split the desired tags the user wants to search by into an array of strings. The array of strings is passed into TagsContainsKeywordsPredicate to create the predicate for updateFilteredRecordList required in ModelManager.

In TagsContainsKeywordsPredicate, to compare for a match, every keyword in the array is compared against the set of tags of each record and as long as any tag matches any of the keywords, the predicate will evaluate to true and allows the FilteredList to filter out the records that do not fulfil the predicate.

FindTagCommandParser returns a FindTagCommand object which calls updateFilteredRecordList to set the new predicate and obtain a new filteredRecords based on the predicate, which will also trigger an event for the UI to read in and display the new records.

The following sequence diagram shows how the limit operation works:

3.9. Limit features

Limit features' storage:
- The limit features are based on the data type Limit, which includes two Date s and one moneyFlow. When entering only one date, the parser will let the date be both dateStart and dateEnd. It is equivalent to entering two same dates.
- DateStart will always be earlier than or equal to dateEnd.
- The limit storage is based on the Date . More than one limit for the same period of time is not allowed.
Limit features’s check:
- Whenever the user change the recordList information, including adding a record, deleting a record and editing a record, all the limits will be checked automatically by calling the function autoLimitCheck().
- The autoCheckLimit() function will look through all the records, calculate the total money for each limit , generate a string which contains all the exceeded limits' information and print the string out to warn the user.
- To get the output, the function will execute a loop, which will execute the isExceeded(), getTotalSpend() and generateLimitOutput() for every limit and combine all the limits' output into one string.
Limit features' MoneyFlow:
- Unlike the moneyFlow used by addCommand, the limit moneyFlow input can only be normal real number, which does not have "-" or "+" in front of the number. For example, m/500.
- After user input the normal real number, the parser will add a "-" at the beginning of the real number, which makes it a normal moneyFlow.
- If user input wrong form of limit moneyFlow, the program will throw an error.
Limit features' parsers:
- All the limitCommand Parsers are similar to each other. However, there are some differences between different commands. Detailed information will be provided in specific commands.
  1. The input given by the user is passed to ArgumentTokeniser#tokenise to split the input separated by prefixes.
  2. This returns a ArgumentMultiMap which contains a map with prefixes as keys and their associated input arguments as the value.
  3. The string associated with m/ will be checked. If the form is correct. If the form is wrong, the program will throw an error, otherwise it will be constructed as a MoneyFlow type.
  4. The string associated with d/ is then passed into xxxLimitCommandParser#splitByWhitespace for further processing and returns an array. This string will be split into two strings and each of them will be constructed as a Date type variable. If there is only one date string, this date will be set to both dateStart and dateEnd.
  5. After parsing the two dates, the parser will check whether the dateStart is earlier than dateEnd.
  6. Lastly a new limit will be generated with the dateStart, dateEnd and money and return the xxxLimitCommand with the limit.
Monthly Limit:
- The addMonthlyLimit command is to add a continuous limit always for the current month. The limit will always check the spend of the month according to the current time. For example, if the limit was set to be 200 at April, the limit will check the total spend for April. When the time comes to May, the limit will no longer check April, instead, the limit will check the total spend of May until the last second of May.
- The user will input only the money they want to set.
- The parser will make the limit with a special date 01-01-9999, which is not likely to be used.
- Once the monthly limit is going to be checked, the function generateThisMonthLimit() will be called, which will generate a temporary limit according to the current date. Then use this temporary limit to do the limit check and generate output.