We store every single Transaction added by the user into an ObservableList<Transaction>, which is a list object in TransactionList. We used an ObservableList to easily reflect changes to the list by any other component of ExpenseLa using the list.

These are the ways of implementing either a positive or negative Transaction:

These two commands will indicate whether the transaction is positive or negative.

Indicating whether it is a recurring transaction or not will depend if rc/ is present in the input

When inserting a new Expense/Income, the AddCommandParser will determine which object to initialise depending on whether the "i/" CLI syntax is present. Afterwhich, the AddCommandParser will parse the values of the transaction depending on whether the respective CLI Syntaxes are present.

The following sequence diagram shows how the add transaction operation works:

Figure 9. Sequence diagram of how adding a new Transaction is processed depending on syntax.

Transaction are normally instantiated by AddCommandParser#parse(String args), which attempts to parse the various parameters supplied in args and return either a positive or negative Transaction. The following conditions will cause a ParseException to be thrown by the parser:

We will demonstrate how a Transaction is added into ExpenseLa below:

Step 1. The user executes the command add n/Pizza a/20.5 d/2020-02-02 to insert a negative transaction with its Name set to "Pizza", its Amount set to "20.50" and the Date set to 02 Feb 2020. The input is now checked and an attempt to parse each parameter occurs:

Since the user input is valid, the Transaction is successfully created and inserted into the transaction list. The transaction list now contains 1 Transaction object.

Step 2. The user executes add i/ n/Salary a/3000 d/2020-02-03 r/Monthly Salary c/income rc/ to indicate his monthly pay, to insert a positive Transaction.

Again, since the input is valid, the positive Transaction is successfully added into the transaction list. The transaction list now contains 2 Transaction objects.

The following activity diagram summarizes what happens when the user executes a command to add a new Transaction:

There are many different ways to implement how a transaction is added into ExpenseLa. In this section, we will justify why we chose to implement it the way we did.

Edit mechanism utilizes Logic operations with the EditCommand class in place of Command, and a unique EditCommandParser class. The following methods are the implementation for edit operations:

Command example: edit 1 n/[NAME] a/[AMOUNT] r/[REMARK] will edit the name, amount and remark of transaction of index 1 with the respective inputs.

Below is an example usage scenario for editing a transaction and explanation of how the edit mechanism behaves at each step:

Step 1. The user starts up the application with an initial list loaded from a sample transaction list.

Step 2. The user inputs edit 1 n/Laksa Noodle a/6.00 to edit the transaction (with index 1) name to "Laksa Noodle" and value to "6". Input is parsed by EditCommandParser#parse() which creates an EditCommand.

Step 3. EditCommand#execute() creates a new transaction that reflects the changes and gets the index of current transaction to be edited.

Step 4. EditCommand#execute() replaces original transaction in the list with the eddited transaction.

The following activity diagram gives an overview of what ExpenseLa shows the user when executing edit command:

This subsection explores some alternative designs considered for certain aspects of the feature’s implementation.