MoneyGoWhere - Developer Guide

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,

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

After forking the repo, the documentation will still have the SE-EDU branding and refer to the AY1920S1-CS2103T-F13-3/main repo.

If you plan to develop this fork as a separate product (i.e. instead of contributing to AY1920S1-CS2103T-F13-3/main), you should do the following:

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).

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

When you are ready to start coding, we recommend that you get some sense of the overall design by reading about Section 2.1 Architecture.

The up and down key mechanism is facilitated by the logic component of MoneyGoWhere. Whenever a user inputs a command, it is stored internally in a list in CommandHistory component of Storage. CommandHistory has an internal index to keep track of its current position in the list.

Additionally, it implements the following operations:

The index is initially set to -1, to indicate that there has been no user input. Whenever a user inputs a command, the command is stored at the end of the list and the index is set to the size of the list, to indicate that there are no commands beyond after this point.

Calling getPrevCommand() will cause the index to decrement by 1 and show the user input command stored at that index. When the index is currently 0, or the first user input, pressing the up key will cause the index to result in -1. This returns the empty string, since there are no commands before this point. Any further up key press will have the same outcome, but the index will stay at negative one.

Calling getNextCommand() will cause the index to increment by 1 and the user input at that index will be returned. If the index is currently the last possible value, the last user input, pressing the down key will cause the index to increment by 1, which is outside the list, the empty string will be returned. Any further down key press will have the same outcome but the index will stay at the list size or one after the last possible index.

The following sequence diagram shows how the up/down key mechanism works:

The following steps explain the sequence diagram:

To summarize what determines the output when the user presses the down key:

The following steps explain the activity diagram:

The sequence diagram and activity diagram for getPrevCommand() are similar to the sequence and activity diagram of getNextCommand() as shown above. The only difference is whether it returns the next command or the previous command.

Find is supported by having a Predicate implemented for every field in Spending. Predicates are added based on valid input entered by the user. The FindCommandParser class stores these predicates, which are combined using Java 8 streams with an AND operation to form a more specific search query.

The sequence diagram below demonstrates how the find command is executed:

The following steps explain Figure 11, “Sequence diagram for an example find command”:

To summarise what happens when the user uses the find command, the following activity diagram is shown below:

The following steps explain Figure 12, “Activity diagram for an example find command”:

Listed in the table below are the design considerations for the find command.

Based on Table 1, “Design considerations for find command”, Alternative 1 was chosen as it was the easiest to implement and obeys the Open-Closed Principle (OCP) of the SOLID principles. Although Alternative 2 enables checking of the related objects directly, it has poor abstraction and changes in the function require prior knowledge of the structure of the entire code, making it difficult to implement.

The sorting feature is supported by SpendingComparator, a custom comparator to facilitate different sort ordering, and implements the following operation:

This operation is exposed in the Model interface as Model#updateSortedSpendingList(comparator).

At a high level view, SpendingComparator and SortField interacts in the manner shown below.

As shown in Figure 13, “High-level view of package interaction”, SortCommand has an association to SortField and a dependency to SpendingComparator.

The sequence diagram below demonstrates how the sort command is executed:

The following steps explain Figure 14, “Sequence diagram for an example sort command”:

The following activity diagram summarises what happens when the user uses the sort command:

The following steps explain Figure 15, “Activity diagram for an example sort command”:

Based on Table 2, “Design considerations for sort command”, Alternative 1 was chosen as it was the easiest to implement and it does not violate Single Responsibility Principle (SRP) of the SOLID framework. The only downside of this approach is that changing any field classes may require modifying SpendingComparator.

In contrast, for Alternative 2, manipulating the internal elements of the list directly is dangerous and can cause unintended side effects. There was also a huge difference for the method design for sort, and Alternative 1 was the easier approach to avoid side effects in Alternative 2.

In this feature, a reminder is constructed with following two key information as attributes.

With the given deadline from users, the following two attributes are created further in the reminder constructor.

The purpose of the above two attributes are for sorting reminders based on the number of days between current date and their deadline in ascending order. These two attributes are also utilized in formatting how a reminder should be displayed on the UI components.

The following class diagram illustrates the summary of the reminder class.

First of all, for the user to add reminders into MoneyGoWhere, the following command is made available.

In this command, the parameter values lead by the prefixes are String values and parser will convert these values into acutual Date and ReminderMessage objects later on.

Below is the activity diagram describing the steps take by MoneyGoWhere when it receives AddReminderCommand.

To illustrate how a reminder is added to the Model component when the user enters AddReminderCommand, the sequence diagram is shown below.

The following are the brief explanation of Figure 18, “Sequence diagram when a new reminder is added to the model component.”

In order for users to delete unwanted reminders, the following command is implemented in MoneyGoWhere application.

Following is the activity diagram which indicates the series of actions performed by MoneyGoWhere when it receives DeleteReminderCommand.

Moreover, the following sequence diagram summarizes the interactions between different components when the user enter DeleteReminderCommand.

The following are the brief explanation of Figure 20, “Sequence diagram while user attempt to remove a reminder”

Alternative 1 from the above table, is currently implemented in MoneyGoWhere since it is efficient for the application to access user’s data from a single storage file.

The following Architecture Diagram summarizes how different components in MoneyGoWhere application interact with each other while storing a reminder from the valid user input with the current implementation.

The import feature allows our users to import data from a comma-separated values (Csv) files. It allows users to add their spending in bulk.

Given below is the Sequence Diagram for interactions within the Logic component for the execute("import p/validSpending.csv")

The Import Feature has one main component, which is the ImportCommand.java file. This file contains the main logic behind the feature. The ImportCommand#readSpendingFromCsv() method utilises the FasterXML/jackson library to read in Csv files and convert it into maps of objects. The maps will then be processed and parsed into Spending objects which will be added into a Spending list. Those maps that do not pass the parse conditions will then be thrown as an exception and its message will be saved inside an error list. After all the maps are processed, the application will then go through the valid spending list and save them by calling the Model#addSpending() method. Following that, the application will then prints an output, showing the result of the command execution.

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

When a user calls the import command and inputs a valid Csv file, the application will read and parses all the data inside the file and save them to the SpendingBookList and moneygowhere.json.

In order for data to be imported into MoneyGoWhere, it must be in a properly formatted Csv file. There should be 5 columns specified for Name, Cost, Date, Tag and Remark

Header Constraints

Cell Formatting

Alternative 1 was chosen as it gives a much better performance as opposed to alternative 2. At first alternative 2 was chosen as it was easier to implement. However, performance issues was detected when importing more than 50 spending and when importing more than 1000 spending, the whole application stops responding.

Hence, alternative 1 was implemented and now the application could handle large amount of spending without a noticeable sluggishness in performance.

The export feature allows our users to export their spending into a comma-separated values(Csv) files. It allows users to export their spending allowing the spending data to be portable.

Given below is the Sequence Diagram for the interactions withing the Logic component for the execute("export p/Documents")

The export feature has one main component, which is the ExportCommand.java file. This file contains the main logic behind the feature. The 'ExportCommand#execute()' method utilises the FasterXML/jackson library to read in the .json file where the application keeps the spending data. After the data has been read successfully, it is converted and written into moneygowhere.csv file. This file will be created at wherever the user specifies. After the data has been successfully exported, the application will then prints an output, showing the result of the command execution.

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

When a user calls the export command and inputs a valid folder path, the application will convert all the spending data into a Csv file and export it to moneygowhere.csv

For the current statistics feature, there are 2 main commands that the user can execute.

The StatsCommandParser differentiates these 2 commands based on whether a valid date range is provided as illustrated in the diagram below.

The implementation of the Statistics feature can be split into 2 phases, preparation and execution. Given below is an explanation of how the Statistics mechanism behaves at each phase.

For the current graph feature, there are 2 main commands that the user can execute.

The GraphCommandParser differentiates these 2 commands based on whether a valid date range is provided as illustrated in the diagram below.

The implementation of the Graph feature can be split into 2 phases, preparation and execution. Given below is an explanation of how the Graph mechanism behaves at each phase.

The current Budget component keeps track of three variables:

The budget amount and the month the budget is set are saved in the save file, whereas the sum is not. Upon initialization, if a save file is found it will automatically set the monthly budget based on the save file’s options. Once the save file is loaded, the program will check today’s month. If the month has changed, the budget’s set month will change to the current month, and the budget amount will carry over. Once the month has been set, it will go through all spending available and sum up all the spending that are in the set month. It will then keep track of this sum.

Once done initializing, users can set a new monthly budget by executing the budget command. The sequence diagram below demonstrates how the budget command is executed:

The figure above shows the sequence of events that occur to set the monthly budget:

Budget also keeps track of the sum of all spending in order to show the user how much budget the user has left. Initially, it has totaled up all spending in the save file, and then the value is modified when the add, delete and edit commands are called.

The following sequence diagram demonstrates how Budget modifies its value when the add command is used:

The diagram above shows what happens when an addCommand is being executed. It focuses only on the components that affect Budget.

When adding a new Spending the following steps happen:

The same applies to delete commands, instead of adding to the sum, it is subtracting from the sum. As well as edit command, which utilizes both add and delete.

A combination of the two was chosen. During the initialization phase, we read through all spending available, but we handle add, delete and edit commands using option 1.

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

These operations are exposed in the Model interface as Model#commitSpendingBook(), Model#undoSpendingBook() and Model#redoSpendingBook() 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 VersionedSpendingBook will be initialized with the initial spending book state, and the currentStatePointer pointing to that single spending book state.

Step 2. The user executes delete 5 command to delete the 5th Spending in the spending book. The delete command calls Model#commitSpendingBook(), causing the modified state of the spending book after the delete 5 command executes to be saved in the spendingBookStateList, and the currentStatePointer is shifted to the newly inserted spending book state.

Step 3. The user executes add n/David …​ to add a new Spending. The add command also calls Model#commitSpendingBook(), causing another modified spending book state to be saved into the spendingBookStateList.

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

The following sequence diagram shows how the undo operation works:

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

Step 5. The user then decides to execute the command list. Commands that do not modify the spending book, such as list, will usually not call Model#commitSpendingBook(), Model#undoSpendingBook() or Model#redoSpendingBook(). Thus, the SpendingBookStateList remains unchanged.

Step 6. The user executes clear, which calls Model#commitSpendingBook(). Since the currentStatePointer is not pointing at the end of the SpendingBookStateList, all spending book 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: