Overview

$aveNUS is a Command Line Interface (CLI) financial planning application that my team and I designed for CS2103T (Software Engineering) module in School of Computing, National University of Singapore (NUS).

In this project, we morphed the sample address book application into $aveNUS, an application that allows NUS students to track their financial spending with regards to food purchases. Additionally, the application provides them with the best food recommendations within their current budget as well as a savings feature to track their savings.

The table below provides a quick summary of the symbols and formatting used in this portfolio.

code

A grey highlight with monospaced font indicates a command that can be typed into the command box of the application.

name

A blue highlight with monospaced font indicates a reference to the codebase. This could be a component, class, method, attribute or file name.

A green tick indicates the expected result that you should see after executing a command in the application.

A lightbulb indicates tips and tricks that might be useful to the user.

A blue information symbol indicates additional information for that section that is good to know.

A red exclamation mark symbol indicates important pointers to take note.

Summary of contributions

In this section, I will provide a summary of the contributions I have made to the team project. These include features which I have implemented as well as other project-related contributions.

Major enhancement: Savings Feature

I conceptualised and added the Savings feature and all of its related commands.

What it does

It allows users to track their saving habits. Users can transfer money from their $aveNUS wallets into their savings account using the save command. In addition, users can transfer money from their savings account and into their $aveNUS wallets using the withdraw command.

Users can then track their savings and withdrawals made from the Savings History Panel of the application’s GUI. The savings of a user is displayed with a green tag, while the withdrawals are displayed as a negative sum of money, and in a red tag.

Justification

In university, students are keen to have savings in their lives even after they graduate. They would like to graduate with at least a certain amount of money in their savings so that they can either pay for their student loans, or return the amount they borrowed from their parents to pay off their tuition fees. To do this, they have to start saving from the time they step into university.

With the savings feature encompassed into the expenditure tracking application of $aveNUS, the application serves as a one-stop application for them to efficiently plan their finances when they are in school. The green tags for savings added, provides a more encouraging display to motivate users to save more. The red tags for the withdrawals made by the user is intentionally harsher, to serve as a warning to the users when they make a withdrawal.

Highlights

I had to implement new classes such as ReadOnlySavingsHistory, SavingsHistory, ReadOnlySavingsAccount, SavingsAccount, Savings, CurrentSavings and SavingsHistoryList. These classes had to be implemented across the multiple components within the application architecture to support the Savings feature, allowing me to better understand the project’s architecture.

A persistent storage functionality to keep track of the user’s savings and withdrawals, was also implemented in this savings feature. This allowed me to understand how data can be saved from a user’s input into a Jackson file.

I also learnt to write unit and integration tests for automated testing within the Savings feature.

Finally, working on the feature gave me the opportunity to interact more in depth with the application’s GUI, so as to effectively present the savings history data to the user.

Other enhancements added: History Retrieval and Restricted Display in Savings History

I assisted my team mate in enhancing his command history feature, allowing users to review the 10 latest commands that they have typed using the history command.

In addition, I conceptualised the restricted viewing of Savings History and added the classes related to the feature.

What it does

Users can retrieve the 10 most recently typed commands by using the history command.

Users can also request to view only their savings/withdrawals in the Savings History Panel. This is done using the show command that I have implemented.

Justification

The history feature allows the user to conveniently refer to the list of commands he/she typed previously without the hassle of scrolling through his past commands one-by-one using the "UP" or "DOWN" keys. This speeds up input as well, since users can simply copy and paste a command that was typed much earlier. This is especially useful since this application is a Command-Line application.

On the other hand, the restricted view feature allows users to view only their savings/withdrawals. Thus, this allows them to track the savings/withdrawals they have made so far and decide if they have been withdrawing too much or saving too little.

Highlights

I had to work closely with my other team members to implement the history feature as we worked on implementing different parts of it.

The restriction of the user’s savings history panel display, also involved the change of certain commands that affected other commands in the application. An example would be CommandResult class, which is used by multiple components within the application.

Code contributions

Project Code Dashboard | Pull Request

Other contributions

  • Project Management:

    • Adding users stories to share the problems we aim to solve

    • Idealised and conceptualised the addition of the Savings feature

    • Managed the integration of code by merging Pull Requests and ensuring compatibility

    • Opened issues when enhancements could be made by team members [Issue #202, #140]

    • Opened issues when bugs were found [Issue #133]

    • Fixed bugs after they were found [PR #159, #297]

  • Enhancements to existing features:

    • Updated the GUI by introducting the Savings History Panel and Savings History Cards to enable the display of the user’s savings history. [PR #177]

  • Documentation:

    • Updated User Guide

      • Added into the User Guide the instructions to use the Savings feature. [PR #301]

      • Update UI images in the User Guide [PR #217]

      • Update other general commands found in the application [PR #173]

    • Updated Developer Guide

      • Added into the Developer Guide information regarding the Savings feature. [PR #188, #191, #320]

      • Update User Stories and set standard for User Stories formatting. [PR #67]

      • Update other general commands found in the application [PR #173]

    • Community:

      • PRs reviewed (with non-trival review comments) [PR #323, #305, #238, #179]

      • Reviewed the Developer Guide of other teams with my team members [ Example here]

Contributions to the User Guide

This section shows the additions that I have made to the User Guide to provide information about how the Savings feature works.

I wrote the descriptions and commands for the savings feature, including commands for v2.0. My description of the save command is replicated below while my full write-ups can be found here.

Transfer money from user’s wallet into savings account: save

The user can save an amount of money from the user’s wallet, into his/her savings account.

Format: save AMOUNT
Example: save 10

Note:
AMOUNT must be a non-negative integer or a non-negative double with 2 decimal places.

Make sure you have money in your wallet before you save! You cannot save money without having money in your wallet.

You will see a success message and the amount of money you have saved in your savings account. You will be able to view your savings in the savings history tab. The savings will appear GREEN.

SavingsAdded
Figure 1. Example savings display when "Savings" is clicked as shown after savings are made.
SavingsSuccessMessage
Figure 2. Example success message that appears after keying a successful saving.

I also wrote the descriptions for the history command. This is replicated below.

Viewing previously typed commands: history

Shows the user’s previously typed commands in the Results Display.
The user can view up to 10 previously typed commands.

Format: history
Example: history

This command only allows you to see previously typed commands. Any commands done through the buttons on the menu pane will not be shown.

You will see a list of commands that you have previously typed in the Results Display.

HistoryUI
Figure 3. Example of view of $aveNUS after user inputs history. History of previously typed command appears in the Results Display as shown.
A message stating that "You have not entered any commands." is displayed if you have not input any commands prior to the call to history.
The history command will only display previous commands with no duplicate commands.
Eg. typing history twice will only result in a display of history only ONCE in the Results Display.

Contributions to the Developer Guide

This section shows the additions that I have made to the Developer Guide to show the implementation and design considerations for the Savings feature.

I described the design of the Savings feature and the implementation of commands that allow users to interact with the Savings feature. My write-up for the save command is replicated below while my overview of the Savings feature can be found here.

Making a saving in $aveNUS

When a user requests for a saving to be made in the application by calling the save AMOUNT command, the following processes will occur internally within the application:

  • The AMOUNT specified by the user is deducted from the user’s wallet.

  • The AMOUNT specified by the user is added into the user’s saving account.

  • The saving is reflected in the savings history.

If the user enters an AMOUNT that is negative, a ParseException is thrown. This exception is thrown from ParserUtil#parseSavings(savings).
Deduction of savings amount from user’s wallet

A Savings object is instantiated in the SaveCommand with the user’s input. It contains information about how much Money was saved, and the TimeStamp of the savings made. The Money object contains the amount of savings made, and the TimeStamp object contains the time and date the saving was made by the user.

When SaveCommand#execute() is called, model#depositInSavings(savingsAmount) is called. Within the Model of $aveNUS, the user’s wallet is checked. If the user attempts to save more money than he/she has in his/her wallet, they will be prompted that the command is invalid.

If the check passes, the saving amount is deducted from the user’s account within the Model.

Adding of savings amount into user’s savings account.

Subsequently after the savings amount is deducted from the wallet, savingsAccount#addToSavings(savings) is called in the Model class. This method call will result in the addition of the savings into the SavingsAccount.

Adding of the savings into the user’s saving history

After the savings is added into the user’s savings account, model#addToHistory(savingsAmount) is called, and the details of the savings are added into the SavingsHistoryList, found within the SavingsHistory object.

The following sequence diagram shows how the making of a saving works:

SaveSequenceDiagram

The following activity diagram summarises what happens when a user executes a SaveCommand:

SaveActivityDiagram
Design Considerations

Detailed below are the design considerations taken into account when engineering the model#depositInSavings(savingsAmount) function.

Table 1. Design considerations of the model#depositInSavings(savingsAmount) function.
Alternative 1 (Chosen Implementation) Alternative 2

Make CurrentSavings a standalone class that does not extend Savings class

  • Pros:

    • CurrentSavings can have its own set of methods that make it unmodifiable. Savings on the other hand is modifiable internally.

    • More efficient as the number of method calls to retrieve the value of the user’s savings is reduced.

  • Cons:

    • Does not maintain good abstraction of CurrentSavings since logically, it is a type of savings.

Make CurrentSavings extend the class Savings

  • Pros:

    • Maintains better abstraction since in reality, a current saving is a type of savings.

  • Cons:

    • Decreases the efficiency of getting the value of the savings, since it would mean increase coupling of classes, i.e. calling methods from Savings and Money classes to obtain the savings amount.

    • Savings is a modifiable class internally. Better data integrity will be ensured if the CurrentSavings remain a view-only class.