PROJECT: $AVE IT

Overview

$AVE IT is a desktop budget management application. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 10 kLoC.

Summary of contributions

  • Major enhancement: added the disjoint accounts feature

    • What it does: The disjoint accounts feature allows the user to better organise their expenditures in multiple accounts.

    • Justification: As the user may have taken on multiple roles/project that require them to manage expenses, they can create one account for each of their roles/projects, in addition to one for their personal expenses. This way, they can track all of their expenditures in this one application, while keep them organised in disjoint accounts.

    • Highlights:

      • This feature required major changed to the backend Storage package as the structure of the Model classes has changed significantly.

      • It was challenging to ensure that this feature works seamlessly with the UI. For example, when a different account is checked-out, multiple UI components are updated.

  • Minor enhancement: improved the find command

    • What it does: Allows the user to search for multiple keywords, a tag, or both together.

  • Minor enhancement: improved the ExpenditureListPanel UI component

    • What it does: Used polymorphism to allow expenditures and repeats to be displayed in the same list.

  • Code contributed: [RepoSense]

  • Other contributions:

    • Project management:

      • Managed releases v1.1 - v1.4 (3 releases) on GitHub

    • Enhancements to existing features:

      • Updated error messages of commands to be more informative and helpful to the user.

    • Documentation:

      • Added documentation for Account and Expenditure to the User Guide and Developer Guide

    • Community:

      • PRs reviewed: #6, #8, #15

      • Reported bugs and suggestions for other teams in the class (examples: #1, #2, #3)

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Disjoint Accounts (Jiang Jiahui)

This feature aims to help you better organise your expenditures by allowing you to separate them into disjoint accounts.

You can add any many accounts as you like:

acc add
Figure 1. Add account

View your list of accounts using the command acc list:

acc listed
Figure 2. List all accounts

Switch to a different account using the command, acc checkout ACCOUNT:

acc checkout CCA
Figure 3. Switch account to CCA
acc checkout Home
Figure 4. Switch account to Home

Refer to Account Commands for more details on commands, including renaming, deletion and clearing of data.

Expenditures (Jiang Jiahui)

This feature forms the basis of our application. Use it to track your daily expenses!

exp list
Figure 5. Example list of expenditures

Refer to Expenditure Commands for more details on how to add, edit, and delete expenditures.

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Disjoint Account (Jiang Jiahui)

The disjoint accounts feature aims to help users better organise their expenditures by allowing them to separate the expenditures into different accounts.

Rationale

The user may be involved in different projects or have different roles which require expenditure tracking. Disjoint accounts aim to provide a higher degree of organization than just organising by date or tag.

Implementation

Below is a simplified class diagram that shows how the Account class relates to other classes (interfaces not shown).

AccountClassDiagram
Figure 6. Simplified Account class diagram

Refer to Expenditure Implementation and Repeat Implementation for more details on these classes.

There are many commands that allow the user to add, delete, rename accounts and so on. Below is a sequence diagram that shows how a command to rename an account takes place.

AccountRenameSequenceDiagram
Figure 7. Sequence Diagram for execution of acc rename command

Design Consideration

This section contains some of our design considerations for the account feature.

Consideration: Storage of expenditures and repeats.

Alternatives

Pros

Cons

1. Store expenditures and repeats in the same list.

Fewer methods, since we can use the same method to add, edit or delete an expenditure/repeat.

Worse time complexity for some tasks which need to differentiate between expenditures and repeats.

2. [current choice] Store expenditures and repeats in separate lists.

Better time complexity for tasks such as calculation of total spending.

There needs to be double the number of getters, setters, methods to add, edit & delete the items.

Consideration: What to use for the backing list of the ListView UI component.

Alternatives

Pros

Cons

Exposing the repeat and expenditure lists in the accounts

Less troublesome when a repeat or expenditure command is executed.

More difficult to implement. Every time the active account is changed, the ListView has to be replaced as the backing list cannot be changed.

2. [current choice] Maintain a single list in the AccountList class as a backing list of the ListView.

There is no ambiguity as to which list is currently being displayed. This is safer as the lists in the accounts cannot be directly modified outside the Account class.

More troublesome when a repeat or expenditure command is executed, since both the active account and the list has to be updated.

Expenditure (Jiang Jiahui)

This is the most essential and basic feature of the application.

Rationale

The user can create expenditures to keep track of what they spend on, how much they have spent, and when it happens.

Implementation

Below is a class diagram that shows the Expenditure class and how it relates to other classes.

ExpenditureClassDiagram
Figure 8. Expenditure class diagram

The activity diagram below shows what happens when the user enters an expenditure add command.

ExpenditureActivityDiagram
Figure 9. Expenditure add activity diagram

Design Consideration

Consideration: Number of tags an expenditure can have

Alternatives

Pros

Cons

One expenditure can have multiple tags.

More flexibility for the user.

More difficult to implement. This also makes it impossible to calculate total spendings for each tag due to possible overlapping.

2. [current choice] An expenditure has exactly one tag.

This makes it possible for the user to see total spending per tag using the Report feature.

Less flexibility for the user.