By: AY1920S2-CS2103T-W12-3 Since: Feb 2020 Licence: MIT

1. About us

1.1. About Sharkie

Sharkie is an all-in-one desktop application for personal finance tracking designed for university students who would like to monitor their spending. It manages your incomes and expenses, organises your contacts and keeps track of debts your friends owe you, so that your loans always come with a money-back guarantee!

Sharkie is adapted from the AddressBook-Level3 project created by SE-EDU and is further developed into a finance tracking application by our awesome developer team!

1.2. About This Guide

This developer guide is written for anyone who wish to build on our application, Sharkie, or wish to know find out more about how Sharkie is implemented.

If you need help setting up your device to build on Sharkie, you find out more at the Setting Up guide below.

Note the following symbols and formatting used in this document:

Table 1. Symbols and formats used in this User Guide.

Symbol/
Format

Meaning

command

A grey highlight (called a mark-up) indicates that this is a command that can be typed into the command line and executed by the application.

Enter

This symbol indicates the enter button on the keyboard.

InformationIcon

This symbol indicates information.

TipIcon

This symbol indicates tips.

2. Setting up

Refer to the guide here.

3. Design

3.1. Architecture

ArchitectureDiagram
Figure 1. Architecture Diagram

The Architecture Diagram given above explains the high-level design of Sharkie. Given below is a quick overview of each component. Sharkie uses the same architecture design as Address Book 3 (AB3).

The .puml files used to create diagrams in this document can be found in the diagrams folder. Refer to the Using PlantUML guide to learn how to create and edit diagrams.

Main has two classes called Main and 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. The following class plays an important role at the architecture level:

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

LogicClassDiagram
Figure 2. Class Diagram of the Logic Component

How the architecture components interact with each other

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

ArchitectureSequenceDiagram
Figure 3. Component interactions for people delete 1 command

The sections below give more details of each component.

3.2. UI component

UiClassDiagram
Figure 4. 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, WalletTransactionPanel, WalletStatisticsPanel 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.

  • Listens for changes to Model data so that the UI can be updated with the modified data.

3.3. Logic component

LogicClassDiagram
Figure 5. Structure of the Logic Component

API : Logic.java

  1. Logic uses the SharkieParser class to parse the user command.

    • SharkieParser will check the command entered against a pattern defined in SharkieParser.

    • It refers to CliPrefix to determine whether the command entered is a people related command, a wallet related command or a global command.

    • If the command entered passes these checks, it then parses the command using the respective XYZCommandParser to retrieve the command to be executed.

  2. This results in a Command object which is executed by the LogicManager.

    • Each command has its own XYZCommand that inherits from Command, implementing different actions to be executed.

  3. The command execution can affect the Model (e.g. adding a person, adding a transaction, filtering a list of transactions, reminders etc.).

  4. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

    • The Ui processes the CommandResult and outputs the information to the ResultDisplay class.

  5. In addition, the CommandResult object can also instruct the Ui to perform certain actions, such as displaying help to the user.

    • Other Ui components are also updated on the successful obtaining of a CommandResult by Ui.

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

DeleteSequenceDiagram
Figure 6. Interactions Inside the Logic Component for the delete 1 Command
The lifeline for PeopleDeleteCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

3.4. Model component

ModelClassDiagram
Figure 7. Structure of the Model Component
ModelManagerClassDiagram
Figure 8. In-depth structure of the Model Manager
The ModelManager class diagram is drawn separately as it is too complicated to include all the details in the Model component diagram.

API : Model.java

The Model,

  • stores a UserPref object that represents the user’s preferences.

  • stores the Wallet data.

  • stores the Address Book data.

  • stores the User data.

  • exposes an unmodifiable ObservableList<Person> and an unmodifiable ObservableList<Transaction> that can be 'observed' e.g. the UI can be bound to these lists so that the UI automatically updates when the data in the respective lists change.

  • does not depend on any of the other three components.

The Wallet,

  • consists of a BudgetList.

  • consists of a TransactionList, which contains Income(s) and a TransactionList which contains Expense(s).

The AddressBook,

  • consists of a UniquePersonList.

The UserData,

  • consists of a User.

The Model package consists of four main packages: Person, Transaction, Reminder and Tag.

ModelPersonDiagram
Figure 9. In-depth structure of Person package in the Model Component

The diagram above shows how the Person package is implemented:

  • PeoplePredicate: PeopleNamePredicate, PeoplePhonePredicate, PeopleTagPredicate, PeopleEmailPredicate are implemented for the execution of people find command.

  • A User consists of a Name, a Phone and an Email.

  • A Person consists of a Name, a Phone, an Email, a TransactionList of Debt(s), a TransactionList of Loan(s) and a set of Tag(s).

ModelTransactionDiagram
Figure 10. In-depth structure of Transaction package in the Model Component
ModelTransactionClassDiagram
Figure 11. Transaction class diagram
The association between Transaction and Amount is not shown in Figure 10, “In-depth structure of Transaction package in the Model Component” to keep the diagram less messy. However, the association is shown in Figure 11, “Transaction class diagram”.

The diagram above shows how the Transaction package is implemented:

  • WalletPredicate: DateContainsKeywordsPredicate, DescriptionContainsKeywordsPredicate, TagContainsKeywordsPredicate, AmountContainsKeywordsPredicate are implemented for the execution of wallet find command.

  • The abstract class Transaction is extended by Income, Expense, Debt and Loan. A Transaction consists of a Description, an Amount, a Date and a Tag.

  • A Budget consists of a Year, a Month and an Amount.

ModelReminderClassDiagram
Figure 12. Reminder class diagram

The Reminder package is implemented for Sharkie's reminder feature. The diagram above shows how the Reminder package is implemented:

  • The Reminder consists of a User (the sender) and a Person (the receiver).

    • A Reminder object is created whenever the people remind or people remindall command is executed.

  • The ConfirmationEmail consists of a User.

    • The ConfirmationEmail is implemented to validate the user’s email address during user’s first login to Sharkie.

The Tag package only consist of a class, Tag and it does not depend on other components in the Model.

3.5. Storage component

StorageClassDiagram
Figure 13. Structure of the Storage Component

API : Storage.java

The Storage converts Model objects to saveable data and vice versa. It comprises four main parts: UserPrefsStorage, UserDataStorage, AddressBookStorage and WalletStorage. Each of these interfaces have a JSON-based implementation that convert their specific data to and from JSON.

The Storage component,

  • can save UserPref objects in JSON format and read it back.

  • can save UserData in JSON format and read it back.

  • can save the Address Book data in JSON format and read it back.

  • can save the Wallet data in JSON format and read it back.

3.6. Common classes

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

4. Implementation

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

4.1. People Owe Command

The people owe command is implemented in the class PeopleOweCommand.

This command can be accessed from Logic#execute(). It records a debt of an indicated Amount to the Person specified by the index.

The following activity diagram illustrates what happens when the user enters a people owe command:

OweActivityDiagram
Figure 14. Activity diagram of the activity of recording a debt

4.1.1. Implementation of people owe command

  1. When entering the debt command, the user will specify the Person using the index of the Person in the list shown in the GUI.

  2. The user should also specify the debt Description, Amount and optionally, the Date.

  3. The PeopleOweCommandParser will create a Debt object based on the details provided, and return the resulting PeopleOweCommand.

  4. When the LogicManager is executing the PeopleOweCommand, it will extract the indicated person from the list of Persons obtained from the Model via Model#getFilteredPersonList()

  5. A new Person with the added Debt is created.

  6. This new Person replace the initial Person at the indicated index via Model#setPerson() for immutability.

  7. The filteredPersons in the Model is then updated.

  8. CommandResult is returned.

The following sequence diagram summarizes what happens during the execution of a people owe command:

OweSequenceDiagram
GetPeopleOweCommandSequenceDiagram
Figure 15. Sequence diagram of the people owe command
The lifeline for PeopleOweCommand and PeopleOweCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.1.2. Design Considerations

Aspect: Keeping track of Debt of a Person.

  • Alternative 1 (current choice): Each Person has a list of Debt objects, each Debt object has Description, Amount and Date.

    • Pros: Able to record more information about a Debt.

    • Cons: Sharkie only allows the return of a Debt all at once, i.e., the user cannot return a Debt partially.

  • Alternative 2: Each Person has one Debt object.

    • Pros: Easier to store the Debt object, only have to keep track of the total debt Amount and the Date of the debt. The user can return any Amount to the Person, and Sharkie will just deduct the total Amount of debt accordingly.

    • Cons: Storing the Date is problematic, as it questions whether the Date of the first borrowing or latest borrowing should be stored. Furthermore, there is no breakdown of Debt details if the user wants to recall why he owed a Person money.

4.2. People Received Command

The people received command is implemented in the class, PeopleReceivedCommand.

This command can be accessed from Logic#execute(). It deletes the Loan(s) of the indicated Person (the Person with the specified index in the Address Book).

The following activity diagram illustrates what happens when the user executes a people received command:

ReceivedActivityDiagram
Figure 16. Activity diagram of recording the amount of money received

4.2.1. Implementation of people received command

  1. In PeopleReceivedCommand class, the list of Persons is obtained from the Model via Model#getFilteredPersonList() and the indicated person is extracted from the list.

  2. The list of Loans of the Person is extracted and modified based on the command entered by the user.

  3. A new Person with the modified list of Loans is created.

  4. This new Person replace the initial Person at the indicated index via Model#setPerson() and the filteredPersons in the Model is updated.

The following sequence diagram summarizes what happens during the execution of a people received command:

ReceivedSequenceDiagram
GetPeopleReceivedCommandSequenceDiagram
Figure 17. Sequence diagram of the people received command
The lifeline for PeopleReceivedCommand and PeopleReceivedCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.2.2. Design Considerations

Aspect: Deletion of Loan from the indicated person.

  • Alternative 1 (current choice): Creates a new Person with the modified list of Loans and use Model#setPerson() to replace the indicated Person with the new Person created.

    • Pros: Preserve the immutable property of Person.

    • Cons: Have to copy over all the attribute values, such as Name, Phone and more.

  • Alternative 2: Modify the list of Loans in the indicated Person directly.

    • Pros: Easier and can save time from copying the information from one Person to another.

    • Cons: Person loses the immutable property.

4.3. Transactions

The Transaction forms the basis for Sharkie’s monetary-related features. It contains a Description, Amount, Date and Tag.

There are currently four classes that inherit from this abstract class, namely Expense, Income, Debt and Loan.

TransactionClassDiagram
Figure 18. Class diagram of Transaction

Expense and Income can be created using the WalletExpenseCommand and the WalletIncomeCommand.

These commands can be accessed from Logic#execute(). It records an expense of an indicated Description, Amount, Date and Tag.

As the two commands are similar, it is sufficient to trace the WalletExpenseCommand. The following activity diagram illustrates what happens when the user enters a wallet expense command:

ExpenseActivityDiagram
Figure 19. Activity diagram of recording an expense

4.3.1. Implementation of wallet expense command

  1. When entering the expense command, the user will specify the Description, Amount and optionally, the Date and Tag.

  2. The WalletExpenseCommandParser will create an Expense object based on the details provided, and return the resulting WalletExpenseCommand that has a reference to the Expense created.

  3. The LogicManager then executes the command and adds the previously created Expense object to the Wallet model.

  4. CommandResult is returned.

The following sequence diagram summarizes what happens during the execution of a wallet expense command:

ExpenseSequenceDiagram
Figure 20. Sequence diagram of the wallet expense command
The lifeline for WalletExpenseCommandParser and WalletExpenseCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.3.2. Design Considerations

Aspect: Representing the Amount of a Transaction.

  • Alternative 1 (previous implementation): Amounts are stored in dollars as double.

    • Pros: Easier to implement.

    • Cons: Floats are inexact. Floating point errors may cause rounding errors or unexpected bugs(e.g. checking if an amount is equal to zero).

  • Alternative 2 (current implementation): Amounts are stored in cents as long.

    • Pros: Arithmetic involving amounts will be exact.

    • Cons: Conversion is needed between cents and dollars. All Sharkie programmers have to be aware of the necessary conversion else bugs may occur.

  • Alternative 3: Amounts are stored as the inbuilt BigDecimal class.

    • Pros: Arithmetic involving amounts will be exact.

    • Cons: BigDecimal is slower in performance and if many calculations are performed, runtime is considerably slower.

4.4. Wallet Edit Command

The edit command is implemented in the class, WalletEditCommand.

This command can be accessed from Logic#execute(). It edits the transaction, indicated by the index specified, with the new details supplied by the command.

The following activity diagram illustrates what happens when the user executes a wallet edit command:

WalletEditActivityDiagram
Figure 21. Activity diagram of the editing a transaction

4.4.1. Implementation of wallet edit command

  1. When entering the wallet edit command, the user have to specify at least one of Description, Amount, Date or Tag. Multiples can be inputted as well.

  2. WalletEditCommandParser is executed to create an EditTransactorDescriptor to hold the values to edit the transaction with.

  3. WalletEditCommandParser then passes the editTransactorDescriptor to create a WalletEditCommand.

  4. In WalletEditCommand class, the list of transactions is obtained from the Model via Model#getFilteredTransactionsList() and the indicated transaction is extracted from the list.

  5. The transaction selected is modified based on the field to edit and the new details entered by the user, which are stored in editTransactorDescriptor

  6. A new transaction modified from the transaction selected is created with createEditedTransaction method in WalletEditCommand

  7. This new transaction replace the initial transaction at the indicated index via Model#setTransaction() and the filteredTransactions in the Model is updated.

The following sequence diagram summarizes what happens during the execution of a wallet edit command:

WalletEditSequenceDiagram
Figure 22. Sequence diagram of the wallet edit command
The lifeline for WalletEditCommand, WalletEditCommandParser and EditTransactionDescriptor should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.4.2. Design Considerations

Aspect: Choosing which transaction to edit from the list of transactions.

  • Alternative 1 (current choice): Get the index from the list of transactions currently displayed, and not original index in the full transactions list, which can be displayed by wallet list command.

    • Pros: Easy to see which transaction is to be edited.

    • Cons: Filtered list needs to be constantly updated.

  • Alternative 2: Always edit based on the index from original list, which can be displayed by wallet list command.

    • Pros: Index is always consistent.

    • Cons: Harder to remember which index represents which transaction.

4.5. Wallet Budget Command

The budget command is implemented in the class, WalletBudgetCommand.

This command can be accessed from Logic#execute(). It adds a budget using the parameters as specified by the user.

The following activity diagram illustrates what happens when a user executes the wallet budget command:

WalletBudgetActivityDiagram
Figure 23. Activity diagram of the execution of wallet budget command

4.5.1. Implementation of wallet budget command

  1. In WalletBudgetCommand class, the Budget produced by WalletBudgetCommandParser is examined to determine if it is a default budget, or if it is a normal budget.

    1. If the Budget is a default budget, the BudgetList is updated in the Model via Model#setDefaultBudget(). This sets the default budget as the one given.

    2. If the Budget is not a default budget, the BudgetList is updated in the Model via Model#setBudget(). This adds the budget given to a list of budgets with their Month and Year specified.

  2. The list of Budget in the Wallet is modified based the arguments input by the user.

  3. If a Budget with the same arguments given already exists, it will be overwritten by the one given.

  4. A CommandResult is returned at the end of the execution.

The following sequence diagram summarizes what happens during the execution of a wallet budget command:

WalletBudgetSequenceDiagram
Figure 24. Sequence diagram of the wallet budget command
The lifeline for WalletBudgetCommandParser and WalletBudgetCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.5.2. Design Considerations

Aspect: Selection of Budget to set: default or specific month / year

  • Alternative 1 (current choice): If the month and year of the budget is specified, the specific Budget will be set. Otherwise, the default Budget will be set.

    • Pros: Easy to differentiate during command processing whether we want a default Budget or a specific one.

    • Cons: All Budget except default Budget all contain a redundant isDefault boolean

  • Alternative 2: Allow the user to specify if they want a default Budget set, or a specific Budget instead.

    • Pros: Clearer way to distinguish between default Budget and specific Budget

    • Cons: Requires more prefixes / suffixes to be added to Parser in order to parse extra arguments.

4.6. Logging

We are using java.util.logging package for logging. The LogsCenter class is used to manage the logging levels and logging destinations.

  • The logging level can be controlled using the logLevel setting in the configuration file (See Section 4.7, “Configuration”)

  • The Logger for a class can be obtained using LogsCenter.getLogger(Class) which will log messages according to the specified logging level

  • Currently log messages are output through: Console and to a .log file.

Logging Levels

  • SEVERE : Critical problem detected which may possibly cause the termination of the application

  • WARNING : Can continue, but with caution

  • INFO : Information showing the noteworthy actions by the App

  • FINE : Details that is not usually noteworthy but may be useful in debugging e.g. print the actual list instead of just its size

4.7. Configuration

Certain properties of the application can be controlled (e.g user prefs file location, logging level) through the configuration file (default: config.json).

5. Documentation

Refer to the guide here.

6. Testing

Refer to the guide here.

7. Dev Ops

Refer to the guide here.

Appendix A: Product Scope

Target user profile:

  • has a need to record expenses and income

  • has a need to keep to a certain budget every month

  • wants to view statistic of spending

  • has a need to record debts and loans

  • want to be reminded of his/her own debts

  • wants to remind his/her friends to pay back their debts

  • has a lot of friends to keep track of in contact book

  • prefer desktop apps over other types

  • can type fast

  • prefers typing over mouse input

  • is reasonably comfortable using CLI apps

Value proposition:

  • records expenses/debts faster than a typical mouse/GUI driven app

  • visual display of data with diagrams instead of just text

Appendix B: User Stories

Priorities: High (must have) - * * *, Medium (nice to have) - * *, Low (unlikely to have) - *

Priority As a/an …​ I want to …​ So that …​

* * *

university student that buys a lot of stuff

keep track of my spending

I do not overspend

* * *

student with fixed monthly allowance

track my spendings in a month

I will make sure I save money every month

* * *

person with bad mental calculation

auto deduct money I owe from money the person owes me

I don’t need to do the math myself

* * *

user

find a person by name

locate details of persons without having to go through the entire list

* * *

computer science student

type instead of click

it is more convenient

* * *

student that always goes out with friends

split shared spendings

I make sure everyone pays back

* * *

poor university person who borrows money from many people

know who I owe money to

I can pay them back when I have money

* * *

person with a lot of friend’s

keep track of who owes me what on which day

I can ask them to pay me back

* * *

calculative person

keep track of how much exactly my friends owe me

I can get all my money back

* * *

student who needs to pay bills

get reminded of when to pay them

I don’t get my utilities cut/chased out of house etc.

* * *

student with tight budget

set a budget and be notified when nearing it

I won’t overspend

* * *

thrifty student

set savings goals

I can have achievable, trackable savings

* * *

unmotivated person

get motivation to spend less/save more

I have the willpower to manage my finances

* *

user

hide private contact details by default

minimize chance of someone else seeing them by accident

* *

a student who lives far from school

keep track of how much i spend on transport

I know whether to get concession

* *

friend

have my friend track how much I owe them

do not have to keep track of it myself

* *

student who travel with friends

keep track of how much each person spent in the trip

there won’t be any money issue during the trip

* *

student that always forget to pay my friend back

set a deadline and reminder

I will pay my friend back

* *

forgetful student

send people automated reminders when they owe me money

I won’t lose any money

* *

a lazy person

I can ask for my money back from a few friends in a click

I can save time asking them one by one

* *

student who does not dare to request money from friends

send notifications to my friends

I can get my money back

* *

student with no control

know if I hit my budget

I will be guilty and thus try and control myself

* *

student who does part time job

track how much I earn in a month

I’m proud of myself

* *

student who prefers visual data

visualise my income/spendings in a graph/chart

it is easier to keep track of my expenditures

* *

student that needs to explain their spendings to their parents

show them the chart of my everyday spendings

It is convenient and more visual

* *

organised student

categorise my spendings

I know the proportions of my spendings

* *

student with a huge wardrobe

keep track of my expenditure on clothing

I can control my shopaholic tendencies

* *

student on diet

track how much I spend on food

I would control myself from spending too much on food

*

rich student

keep track of what I bought

I can show off to my friends

*

rich student who always lends people money

take note of who owes me money

I can track them and ask them for it back

*

someone with few friends

keep track of who I paid for or who paid for me first

I know who are my friends, and the frequency I go out with them

*

tech-savvy loan shark

I want to conveniently record who owes me money

I can remind them to pay back through email

*

tech-savvy loan shark

I want a convenient way to calculate interest rate

I don’t have to do it manually

Appendix C: Use Cases

C.1. Wallet Tab

(For all use cases below, the System is the Wallet and the Actor is the User, unless specified otherwise)

Use case: UC1 - Recording an expense

MSS

  1. User requests to add an expense into the wallet.

  2. Wallet adds the expense and displays the expense in the list of expenses.

    Use case ends.

Extensions

  • 1a. The amount keyed in by the user is invalid.

    • 1a1. Wallet shows an error message.

    • 1a2. User re-enters the expense.

      Steps 1a1-1a2 are repeated until the amount keyed in by the user is correct.

      Use case resumes at step 2.

Use case: UC2 - Recording an income

MSS

  1. User requests to add an income into the wallet.

  2. Wallet adds the income and displays the income in the list of incomes.

    Use case ends.

Extensions

  • 1a. The amount keyed in by the user is invalid.

    Steps 1a1-1a2 of recording an expense (UC1) are repeated until the amount keyed in by the user is valid.

Use case resumes at step 2.

Use case: UC3 - Setting budget

MSS

  1. User requests to set a budget.

  2. Wallet sets the amount keyed in as the budget of the month indicated.

    Use case ends.

Extensions

  • 1a. The amount keyed in by the user is invalid.

    Steps 1a1-1a2 of recording an expense (UC1) are repeated until the amount keyed in by the user is valid.

    Use case resumes at step 2.

  • 1b. The amount keyed in by the user has no date attached to it.

    • 1b1. Wallet automatically assigns the budget entered as the default budget of each month.

      Use case ends.

Use case: UC4 - Deleting a transaction

Preconditions: The transaction that the user wants to delete exists in the wallet.

MSS

  1. User requests to delete a specific transaction in the wallet.

  2. Wallet deletes the transaction and displays the list of remaining transactions.

    Use case ends.

Extensions

  • 1a. The transaction’s index keyed in by the user is invalid.

    • 1a1. Wallet shows an error message.

    • 1a2. User re-enters the index.

      Steps 1a1-1a2 are repeated until the index keyed in is valid.

      Use case resumes at step 2.

Use case: UC5 - Editing a transaction

Preconditions: The transaction that the user wants to edit exists in the wallet.

MSS

  1. User requests to edit a specific transaction in the wallet.

  2. Wallet edits the transaction and shows the list with the edited transaction.

    Use case ends.

Extensions

  • 1a. The transaction’s index keyed in by the is invalid.

    Steps 1a1-1a2 of deleting an transaction (UC4) are repeated until the index keyed in by the user is valid.

    Use case resumes at step 2.

  • 1b. The user did not indicate the field to edit.

    • 1b1. Wallet shows an error message.

    • 1b2. User re-enters the edit command.

      Steps 1b1-1b2 are repeated until the edit command keyed in is valid.

      Use case resumes at step 2.

Use case: UC6 - Finding a transaction

MSS

  1. User keys in a keyword.

  2. Wallet lists out the transactions that contain the keyword.

    Use case ends.

Extensions

  • 1a. The keyword entered by the user does not exist in the wallet.

    • 1a1. Wallet shows an empty list.

      Use case ends.

Use case: UC7 - Listing all transactions

MSS

  1. User enters the list command.

  2. Wallet lists out all the transactions.

    Use case ends.

C.2. People Tab

(For all use cases below, the System is the Address Book and the Actor is the User, unless specified otherwise)

Use case: UC8 - Adding a person

MSS

  1. User requests to add a person into the address book.

  2. Address book adds the person and displays the person in the list of people.

    Use case ends.

Extensions

  • 1a. The person’s details keyed in by the user is invalid.

    • 1a1. Address book shows an error message.

    • 1a2. User re-enters the person’s details.

      Steps 1a1-1a2 are repeated until the details keyed in is correct.

      Use case resumes at step 2.

Use case: UC9 - Sending reminder to a friend

MSS

  1. User requests to send a reminder to a friend.

  2. Address book sends a reminder to the friend.

    Use case ends.

Extensions

  • 1a. The person’s index keyed in by the user is invalid.

    • 1a1. Address book shows an error message.

    • 1a2. User re-enters the index.

      Steps 1a1-1a2 are repeated until the index keyed in is valid.

      Use case resumes at step 2.

  • 1b. Address book shows that the friend does not owe the user money.

    Use case ends.

Use case: UC10 - Recording the money the user owes

Preconditions: The friend, who user owes exists in the address book.

MSS

  1. User enters the amount borrowed from a friend.

  2. Address book records the amount, which the user owes the friend.

    Use case ends.

Extensions

  • 1a. The person’s index keyed in by the user is invalid.

    Steps 1a1-1a2 of sending reminder to a friend (UC9) are repeated until index keyed in by the user is valid.

    Use case resumes at step 2.

  • 1b. The amount keyed in by the user is invalid.

    • 1b1. Address book shows an error message.

    • 1b2. User re-enters the amount.

      Steps 1b1-1b2 are repeated until the amount keyed in is correct.

      Use case resumes at step 2.

Use case: UC11 - Recording the money the user lends

Preconditions: The friend, who user lends exists in the address book.

MSS

  1. User enters the amount lent to a friend.

  2. Address book records the amount, which the user lends to the friend.

    Use case ends.

Extensions

  • 1a. The person’s index keyed in by the user is invalid.

    Steps 1a1-1a2 of sending reminder to a friend (UC9) are repeated until the index keyed in by the user is valid.

    Use case resumes at step 2.

  • 1b. The amount keyed in by the user is invalid.

    Steps 1b1-1b2 of recording the money the user owes (UC10) are repeated until the amount keyed in by the user is valid.

    Use case resumes at step 2.

Use case: UC12 - Deleting a person

Preconditions: The person, who user wants to delete exists in the address book.

MSS

  1. User requests to delete a specific person in the address book.

  2. Address book deletes the person and shows the list of the remaining people.

    Use case ends.

Extensions

  • 1a. The person’s index keyed in by the user is invalid.

    Steps 1a1-1a2 of sending reminder to a friend (UC9) are repeated until the index keyed in by the user is valid.

    Use case resumes at step 2.

Use case: UC13 - Editing a person

Preconditions: The person, who user wants to edit exists in the address book.

MSS

  1. User requests to edit a specific person in the address book.

  2. Address book updates the indicated person’s detail and show the list of people with the edited person.

    Use case ends.

Extensions

  • 1a. The person’s index keyed in by the user is invalid.

    Steps 1a1-1a2 of sending reminder to a friend (UC9) are repeated until the index keyed in by the user is valid.

    Use case resumes at step 2.

  • 1b. The person’s new details keyed in by the user is invalid.

    Steps 1a1-1a2 of adding a person (UC8) are repeated until the details keyed in by the user is valid.

    Use case resumes at step 2.

Use case: UC14 - Finding a person

MSS

  1. User keys in a keyword.

  2. Address book lists out the people, who contain the keyword in their names.

    Use case ends.

Extensions

  • 1a. The keyword entered by the user does not exist in the address book.

    • 1a1. Address book shows an empty list.

      Use case ends.

Appendix D: Non Functional Requirements

  1. Sharkie should work on any mainstream OS as long as it has Java 11 or above installed.

  2. Sharkie should be able to hold up to 100 persons and 100 transactions without a noticeable sluggishness in performance for typical usage.

  3. University students with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.

  4. Sharkie should be for a single user.

  5. Sharkie needs to be developed incrementally with high cohesion and utilising CS2103T coding standards for maintainability.

  6. The data used by Sharkie should be stored locally and should be in a human editable file.

  7. The Sharkie JAR file size should be less than 100Mb.

Appendix E: Glossary

Address book

Sharkie’s address book that holds information pertaining to friends / peers / acquaintances of the user that the user has entered

CLI

Command line interface

Cohesion

A measure of how strongly-related and focused the responsibilities of a component are

Debt

The amount of money which the user owes a person in the address book.

Extensions

"Add-on"s to MSS that describe exceptional/alternative flow of events.

GUI

Graphical User Interface

Loan

The amount of money which the user lends to a person in the address book.

Mainstream OS

Windows, Linux, Unix, OS-X

MSS

Main Success Scenario, the most straightforward interaction for a given use case

Private contact detail

A contact detail that is not meant to be shared with others

Transaction

Income and expense

Wallet

Sharkie’s wallet, that holds information pertaining to the user’s expenditure and income

Appendix F: Product Survey

F.1. Money Lover

Pros / Good Features

  • Wallet

    • Multiple wallets to further organise spending/income

  • Transaction

    • Attach images to transactions

    • Add location data to transactions

    • Add recurring transactions (monthly, weekly, etc)

    • Option to exclude certain expenses/incomes from statistics

    • Search for transactions by amount, date, description, category, location

  • Debt

    • Set reminders to self on when to pay back debts

  • Budget

    • Set custom date range for budget

    • Set budget for specific categories (e.g. food, clothes)

    • Calculate recommended daily spending

  • Statistics

    • View statistics for custom date ranges

  • NFR

    • Cross-platform (syncs between devices)

    • Appealing, clean UI

Cons / Bad Features

  • Transaction

    • Unable to create custom tags/categories for transactions

  • Debt

    • Unable to tag debts to a specific contact (no underlying address book)

  • NFR

    • Requires network

    • GUI-reliant (slow input)

    • Certain features locked behind paywall, advertisements

Link to Product: https://web.moneylover.me

F.2. Spendee

Pros / Good Features

  • Wallet

    • Can import .csv files to add data more quickly

  • Transaction

    • Attach images to transactions

    • Create custom tags for transactions

    • Add recurring transactions (monthly, weekly, etc)

    • Search for transactions by amount, date, description, category

    • Can also filter by multiple categories at once

  • Budget

    • Calculate recommended daily spending

  • Statistics

    • View statistics for custom date ranges

  • NFR

    • Cross-platform (syncs between devices)

    • Appealing, clean UI

Cons / Bad Features

  • Debt

    • Unable to tag debts to a specific contact (no underlying address book)

  • NFR

    • Requires network

    • GUI-reliant (slow input)

    • Certain features locked behind paywall, advertisements

Link to Product: https://app.spendee.com

Appendix G: Instructions for Manual Testing

Given below are instructions to test the app manually.

These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing.

For commands that require <index> input, if an index of 0 is provided, an error message will be returned indicating that the command is invalid as it was stated in the User Guide that index should be positive. If the index provided is larger than the number of people or transactions on the list, the error returned will state that the index provided is invalid because there person or transaction does not exist in the list. Thus, different error messages will be returned even though both errors pertains to the wrong index provided.

G.1. Manual Testing on Global Features

G.1.1. Launch and Shutdown

  1. Initial launch

    1. Download the jar file and put the jar file in an empty folder.

    2. Open a command window. Run the java -version command to ensure you are using Java 11.

    3. Launch the jar file using the java -jar command (do not use double-clicking).
      Expected: Shows an "Enter User Data" window. The window size may not be optimum.

  2. Entering user data

    1. Enter a dummy name, phone and a valid email. If you do not wish to use your own email, you can get a temporary email from temp-mail.org.

    2. Retrieve and enter the PIN number sent to the email. If it is not in the inbox, please check the junk mail.
      Expected: Your user data is saved.

  3. Saving window preferences

    1. Resize the window to an optimum size. Move the window to a different location. Close the window.

    2. Re-launch the app using the java -jar command (do not use double-clicking).
      Expected: The most recent window size and location is retained.

  4. Exiting the application

    1. Click on the close button at the top right corner on the window.
      Expected: All windows of the application is closed.

    2. Enter exit command in the command box and press Enter.
      Expected: Same as previous.

G.2. Manual Testing on Wallet Tab

  1. Recording an expense

    1. Prerequisites: None.

    2. Test case: wallet expense n/Meal $/3.50
      Expected: An expense named Meal with $3.50 with default tag Misc recorded under the current date is added to the transaction list. The statistics panel will also update with the expense entered.

    3. Test case: wallet expense n/Meal $/3.50 d/02/02/2020
      Expected: An expense named Meal with $3.50 with default tag Misc recorded under the date 02 FEB 2020 is added to the transaction list. The statistics panel will not update with this expense.

    4. Test case: wallet expense n/Meal $/3.50 t/Food
      Expected: An expense named Meal with $3.50 with tag Food recorded under the current date is added to the transaction list. The statistic panel will also update with the expense entered, under the custom tag given.

    5. Test case: wallet expense n/Meal $/asdf
      Expected: The expense is not recorded. Error details shown in result display.

    6. Other incorrect expense commands to try:

      • wallet expense,

      • wallet expense 1,

      • wallet expense $/x,

      • wallet expense n/Meal
        Expected: Similar to previous.

  2. Recording an income

    1. Prerequisites: None.

    2. Test case: wallet income n/Teaching Assistant Job $/100
      Expected: An expense named Teaching Assistant Job with $100.00 with default tag Misc recorded under the current date is added to the transaction list.

    3. Test case: wallet income n/Teaching Assistant Job $/100 d/02/02/2020
      Expected: An expense named Teaching Assistant Job with $100.00 with default tag Misc recorded under the date 02 FEB 2020 is added to the transaction list.

    4. Test case: wallet income n/Teaching Assistant Job $/100 t/Job
      Expected: An expense named Teaching Assistant Job with $100.00 with tag Job recorded under the current date is added to the transaction list.

    5. Test case: wallet income n/Teaching Assistant Job $/asdf Expected: The income is not recorded. Error details shown in result display.

    6. Other incorrect expense commands to try:

      • wallet income,

      • wallet income 1,

      • wallet income $/x,

      • wallet income n/Teaching Assistant Job
        Expected: Similar to previous.

  3. Setting a budget

    1. Prerequisites: None.

    2. Test case: wallet budget $/800
      Expected: A budget of $800 is set as the default budget for Sharkie. The UI should update to display your total expenditure over the set budget, assuming you have no budget set for the current month.

    3. Test case: wallet budget $/800 m/02 y/2020
      Expected: A budget of $800 is set as the budget for FEB 2020. The UI should update to display the total expenditure over the set budget if the current date is within the month you have selected. It will override the default budget set.

    4. Test case: wallet budget $/0
      Expected: A budget of $0 is set as the default budget. Sharkie will assume that there is no budget set as default, and the UI will reflect this.

    5. Test case: wallet budget $/asdf
      Expected: The budget will not be set. Error details will show in the result display.

    6. Other incorrect budget commands to try:

      • wallet budget,

      • wallet budget 1,

      • wallet budget $/800 m/02,

      • wallet budget $/800 y/2020,

      • wallet budget $/800 m/a y/b,

      • wallet budget $/-800
        Expected: Similar to previous.

G.2.1. Listing all transactions

  1. Listing all the transactions in the wallet.

    1. Prerequisites: The transactions list must not be empty.

    2. Test case: wallet list
      Expected: All transactions in wallet listed out.

G.2.2. Editing a transaction

  1. Editing a specific transaction.

    1. Prerequisites: The transaction to be edited exist in the wallet. At least 1 field to be edited must be inputted. The new details provided to edit the transaction with must be different from the corresponding details in the old transaction.

    2. Test case: wallet edit 1 n/Chicken Rice
      Expected: The first transaction is now updated with new description Chicken Rice. A success message shown in the result display.

    3. Test case: wallet edit 1 n/Dinner $/12.00 d/02/02/2020 t/food
      Expected: The first transaction is now updated with new description Dinner with amount $12.00, recorded under the date 02/02/2020 with tag Food. A success message shown in the result display.

    4. Test case: wallet edit 0 n/Chicken Rice
      Expected: The transaction is not edited. Error details shown in the result display.

    5. Other incorrect edit commands to try:

      • wallet edit,

      • wallet edit 1,

      • wallet edit 1 n/,

      • wallet edit 1 $/,

      • wallet edit 1 d/,

      • wallet edit 1 t/,

      • wallet edit 1 d/yyyy/mm/dd, (where the order of day month and year is not correct)

      • wallet edit 1 d/x, (where x is not a date)

      • wallet edit x n/Dinner $/12.00 d/02/01/2020 (where x is larger than the transaction list size),

      • wallet edit x $/12.00 (where x is a negative number),

      • wallet edit x $/12.00 (where x is a non-integer),

      • wallet edit 1 n/Dinner $/x (where x is greater 92233720368547758.07),

      • wallet edit 1 n/Dinner $/x (where x has more than 2 decimal places) or

      • wallet edit 1 n/Dinner $/x (where x is not a number).
        Expected: Similar to previous

G.2.3. Finding transactions

  1. Finding transactions containing the <keyword> provided.

    1. Prerequisites: The transaction list must not be empty. The keyword can only be either of type [n/<description>], [d/<date>], [$/<amount>], or [t/<tag>]. At least 1 keyword to search with must be inputted.

    2. Test case: wallet find n/chicken duck
      Expected: All transactions with description containing either chicken or duck are displayed. A success message shown in the result display.

    3. Test case: wallet find $/3 12
      Expected: All transactions with amount in the range of $3.00 to $3.99 or $12.00 to $12.999 are displayed. A success message shown in the result display.

    4. Test case: wallet find d/20/12/2020 30/12/2020
      Expected: All transactions with date falling on 20/12/2020 or 30/12/2020 are displayed. A success message shown in the result display.

    5. Test case: wallet find t/food shopping
      Expected: All transactions with tag containing either food or shopping are displayed. A success message shown in the result display.

    6. Test case: wallet find n/Chicken d/20/12/2020
      Expected: Find command do not run. Error details shown in the result display.

    7. Other incorrect find commands to try:

      • wallet find,

      • wallet find n/,

      • wallet find $/,

      • wallet find d/,

      • wallet find t/,

      • wallet find n/Dinner $/12.00 d/02/01/2020 t/food

      • wallet find $/x (where x is a negative number),

      • wallet find $/x (where x is a non-integer),

      • wallet find $/x (where x is greater 92233720368547758.07),

      • wallet find d/x (where x is not a date),

      • wallet find d/yyyy/mm/dd (where date is in the wrong format)
        Expected: Similar to previous

G.2.4. Deleting a transaction

  1. Deleting a transaction.

    1. Prerequisites: The transaction which you want to delete exists in the transactions list.

    2. Test case: wallet delete 1
      Expected: First transaction is deleted from the list. Details of the deleted contact shown in the result display.

    3. Test case: wallet delete 0
      Expected: No transaction is deleted. Error details shown in the result display.

    4. Other incorrect delete commands to try:

      • wallet delete,

      • wallet delete x (where x is not a number),

      • wallet delete x (where x is larger than the person list size),

      • wallet delete x (where x is a negative number) or

      • wallet delete x (where x is a non-integer value)
        Expected: Similar to previous.

G.2.5. Clearing all transactions

  1. Clear all the data in the wallet, including income, expense and budget.

    1. Prerequisites: There must be transactions or budget data in the wallet.

    2. Test case: wallet clear
      Expected: All transactions and budget data in wallet is deleted.

G.3. Manual Testing on People Tab

G.3.1. Managing contacts

  1. Adding a person

    1. Test case: people add n/John Doe p/91234567 e/John@example.com
      Expected: A person named John Doe with phone number 91234567 and email John@example.com is added to the contact.

    2. Test case: people add n/John Doe p/91234567
      Expected: No person is added. Error details shown in the result display.

    3. Other invalid people add commands to try:

      • people add,

      • people add n/Invalid! p/99999999 e/John@example.com,

      • people add n/John Doe p/123 e/John@example.com,

      • people add n/John Doe p/123 e/invalid,

      • people add n/John Doe e/John@example.com,

      • people add p/91234567 e/John@example.com,

      • people add n/John Doe,

      • people add p/91234567 or

      • people add e/John@example.com
        Expected: Similar to previous.

  2. Editing the details of a person

    1. Prerequisites: The person whom you want to edit exists in the person list.

    2. Test case: people edit 1 n/April Tan p/91234567 e/April@example.com
      Expected: The first person name, phone number and email will be changed to April Tan, 91234567 and April@example.com respectively.

    3. Test case: people edit 0 n/John Doe p/91234567 e/John@example.com
      Expected: No person is edited. Error details shown in the result display.

    4. Other valid people edit commands to try:

      • people edit 1 n/Bob p/88888888,

      • people edit 1 n/Cate e/cate@example.com,

      • people edit 1 p/66666666 e/cate@example.com,

      • people edit 1 n/Alice,

      • people edit 1 p/99999999 or

      • people edit 1 e/email@example.com,
        Expected: Similar to (b).

    5. Other invalid people edit commands to try:

      • people edit,

      • people edit 1,

      • people edit 1 n/Invalid!,

      • people edit 1 p/123,

      • people edit 1 e/invalid,

      • people edit x n/Something (where x is larger than the person list size),

      • people edit x n/Somthing (where x is a negative number) or

      • people edit x n/Something (where x is a non-integer value)
        Expected: Similar to (c).

  3. Finding a person

    1. Prerequisites: The person whom you want to find exists in the person list.

    2. Test case: people find n/Alex Bernice
      Expected: People who `are have Alex or Bernice in their name (case insensitve) will be listed.

    3. Test case: people find t/debt
      Expected: People whom you owe money to will be listed.

    4. Test case: people find t/loan
      Expected: People whom you lend money to will be listed.

    5. Test case: people find n/Alex p/91234567
      Expected: No person found. Error details shown in the result display.

    6. Other valid people find commands to try:

      • people find p/93210283,

      • people find p/9321 9927,

      • people find e/@example,

      • people find e/irfan@example.com,

      • people find p/phone or

      • people find t/debt loan
        Expected: Similar to (b).

        people find p/phone is a valid command even though phone is not a valid phone number. However, no person will be listed since no one has phone as their phone number.

    7. Other invalid people find commands to try:

      • people find d/invalidTag
        Expected: Similar to (d).

  4. Listing everyone

    1. Test case: people list
      Expected: Everyone in the contacts will be listed.

  5. Deleting a person while all persons are listed

    1. Prerequisites: List all persons using the people list command. The person who you want to delete exists in the person list.

    2. Test case: people delete 1
      Expected: First contact is deleted from the list. Details of the deleted contact shown in the result display.

    3. Test case: people delete 0
      Expected: No person is deleted. Error details shown in the result display.

    4. Other invalid people delete commands to try:

      • people delete,

      • people delete x (where x is larger than the person list size),

      • people delete x (where x is a negative number) or

      • people delete x (where x is a non-integer value)
        Expected: Similar to previous.

  6. Deleting everyone

    1. Test case: people clear
      Expected: The list of people will be empty.

If you have deleted everyone in the addressbook, and would like to retrieve some sample data to test Sharkie, simply delete data/addressbook.json.

G.3.2. Recording the flow of money

  1. Recording the money you owe a person

    1. Prerequisites: The person whom you owe exists in the person list.

    2. Test case: people owe 1 n/Breakfast $/5.00
      Expected: A debt named Breakfast with $5.00 is added into the debt list of the first person.

    3. Test case: people owe 1 n/Breakfast $/5.00 d/02/02/2020
      Expected: A loan named Breakfast with $5.00, recorded under the date 02/02/2020 is added into the debt list of the first person. Total amount of money, which you lent to the first person is shown in the result display.

    4. Test case: people owe 0 n/Breakfast $/5.00
      Expected: The loan is not recorded. Error details shown in the result display.

    5. Other invalid people owe commands to try:

      • people owe,

      • people owe 1,

      • people owe 1 n/Laksa,

      • people owe 1 $/5.00,

      • people owe n/Laksa $/5.00,

      • people owe x n/Breakfast $/12.00 (where x is larger than the person list size),

      • people owe x n/Breakfast $/12.00 (where x is a negative number),

      • people owe x n/Breakfast $/12.00 (where x is a non-integer),

      • people owe 1 n/Breakfast $/x (where x is a negative number),

      • people owe 1 n/Breakfast $/x (where x is greater 92233720368547758.07),

      • people owe 1 n/Breakfast $/x (where x has more than 2 decimal places) or

      • people owe 1 n/Breakfast $/x (where x is not a number).
        Expected: Similar to previous

  2. Recording the money you returned to a person

    1. Prerequisites: The person whom you returned to exists in the person list.

    2. Test case: people returned 1 i/1
      Expected: The first debt of the first person is deleted from the debt list. Remaining amount of debt, which have yet settled by the first person is shown in the result display.

    3. Test case: people returned 0 i/1
      Expected: No debt is deleted. Error details shown in the result display.

    4. Other invalid people returned commands to try:

      • people returned,

      • people returned 1,

      • people returned i/1,

      • people returned x i/1 (where x is larger than the person list size),

      • people returned x i/1 (where x is a negative number),

      • people returned x i/1 (where x is a non-integer value),

      • people returned 1 i/x (where x is larger than the debt list size),

      • people returned 1 i/x (where x is a negative number or zero) or

      • people returned 1 i/x (where x is a non-integer value)
        Expected: Similar to previous

  3. Recording the money you lend to a person

    1. Prerequisites: The person whom you lend to exists in the person list.

    2. Test case: people lend 1 n/Dinner $/12.00
      Expected: A loan named Dinner with $12.00 is added into the loan list of the first person.

    3. Test case: people lend 1 n/Dinner $/12.00 d/02/02/2020
      Expected: A loan named Dinner with $12.00, recorded under the date 02/02/2020 is added into the loan list of the first person. Total amount of money, which you lent to the first person is shown in the result display.

    4. Test case: people lend 0 n/Dinner $/12.00
      Expected: The loan is not recorded. Error details shown in the result display.

    5. Other invalid people lend commands to try:

      • people lend,

      • people lend 1,

      • people lend 1 n/Chicken Rice,

      • people lend 1 $/12.00,

      • people lend n/Chicken Rice $/12.00,

      • people lend x n/Dinner $/12.00 (where x is larger than the person list size),

      • people lend x n/Dinner $/12.00 (where x is a negative number),

      • people lend x n/Dinner $/12.00 (where x is a non-integer),

      • people lend 1 n/Dinner $/x (where x is a negative number),

      • people lend 1 n/Dinner $/x (where x is greater 92233720368547758.07),

      • people lend 1 n/Dinner $/x (where x has more than 2 decimal places) or

      • people lend 1 n/Dinner $/x (where x is not a number).
        Expected: Similar to previous

  4. Recording the money you received from a person

    1. Prerequisites: The person whom you received from exists in the person list.

    2. Test case: people received 1 i/1
      Expected: The first loan of the first person is deleted from the loan list. Remaining amount of loan, which have yet settled by the first person is shown in the result display.

    3. Test case: people received 0 i/1
      Expected: No loan is deleted. Error details shown in the result display.

    4. Other invalid people received commands to try:

      • people received,

      • people received 1,

      • people received i/1,

      • people received x i/1 (where x is larger than the person list size),

      • people received x i/1 (where x is a negative number),

      • people received x i/1 (where x is a non-integer value),

      • people received 1 i/x (where x is larger than the loan list size),

      • people received 1 i/x (where x is a negative number or zero) or

      • people received 1 i/x (where x is a non-integer value)
        Expected: Similar to previous

G.3.3. Sending reminders

  1. Reminding a specific person about the unsettled loan(s).

    1. Prerequisites: Connected to the Internet. Your firewall or antivirus programme (if any) allows the connection to STMP port 587. The person who you want to remind exists in the person list. The person has at least one loan in the loan list. The email of the person to be reminded is a valid email (You can generate an email from temp-mail.org).

    2. Test case: people remind 1
      Expected: A reminder is sent to the first person’s email. A carbon copy (CC) of the reminder is sent to you. A success message shown in the result display.

    3. Test case: people remind 0
      Expected: No reminder is sent. Error details shown in the result display.

    4. Other invalid people remind commands to try:

      • people remind,

      • people remind x (where x is larger than the person list size),

      • people remind x (where x is a negative number) or

      • people remind x (where x is a non-integer value)
        Expected: Similar to previous

  2. Reminding all people about the unsettled loan(s).

    1. Prerequisites: Connected to the Internet. Your firewall or antivirus programme (if any) allows the connection to STMP port 587. At least one person in the list has at least one loan. The email(s) of the people to be reminded are valid email(s) (You can generate an email from temp-mail.org).

    2. Test case: people remindall
      Expected: A reminder is sent everyone, who has unsettled loan. A carbon copy (CC) of each of the reminder is sent to you. A list of people reminded is shown in the result display, along with the success message.

Appendix H: Effort

Overview
Our application, Sharkie, is considerably different from what AB3 has implemented. We incorporated the address book features that were previously available in AB3, but we wanted to add expense tracking features as the main part of our project. As such, we had to expand a lot on the features that AB3 implemented and also had to create our own models and implementations.

These are based off the foundations that AB3 had already put in place, but the entire team needed to work together to expand on these features to create Sharkie.

Challenges
The team encountered a few issues during the development process of Sharkie. The more notable ones are:

  • Initial brainstorming and filtering of ideas
    At the start of the project, ideation and brainstorming came up with a bunch of features that we wanted to implement in Sharkie. We came up with many different ideas and ways to implement our commands and features, however, it was messy as we were unsure and unclear of how each of us wanted to implement our features. We sat down for a few meetings to discuss our implementation and our thought processes, ensuring that everyone was on the same page before starting the development process.

  • Wallet model
    Since we wanted an expense tracker for Sharkie, we required some proper way of storing our data. We decided to adapt from AB3’s address book system, following their saving of data and storing of user details, implementing it in our Wallet model.

  • Commands
    We also adapted AB3’s command system using their XYZParser and XYZCommand implementations, making our application easier to develop since we were using the same implementation as their Logic.

  • Reminder feature
    One of the more prominent features that we added that was completely not part of AB3 was our reminder feature. This feature had nothing similar to it in AB3, and had to be implemented from scratch in order to make it work with our program.

  • User interface
    We decided early on that we wanted to redo the user interface from AB3, as it would not only be more asthetically pleasing, but also tie in well to the features that we wanted to be implemented. Daniel did the main UI implementation using JavaFX and CSS, and along the way the entire team chipped in to fix the many different bugs that arose due to the UI. Threading errors, wrong values being displayed etc. were all fixed after careful testing and fixing by the team.

Conclusion
The team believes that we have put in a lot of equal effort on all parts of the project, from the documentation to the coding of the project itself. We believe that our product is significantly different from AB3 and we are happy with what we have achieved across the semester with CS2103T.