Ng Hoi Ying - Project Portfolio

PROJECT: Makan Book

Overview

Makan Book is a restaurant guide and application for diners in National University of Singapore (NUS). It is not just a restaurant list, more importantly is that the Makan book allows user to create personal account, which provide more feature to optimizing their dining experience. For example, user can create a jio to invite other user to join his dinner, or find a free time between user to arrange a meal. Also,user can find a good restaurant base on other users' rating and review. After his meal, user can even rate and write review for the restaurant, which everyone can see, to share his experience. Also, if the user is eating in a group, or with friend, they can create a debt, to clearly mark down who and how much other own you or you own them.

Summary of contributions

Major enhancement: added the ability to add/accept/delete/clear a debt between user
- What it does: allows user to keep debt record. A debt need to be confirm by both user to ensure the accuracy. Also, auto-balancing is implemented as to simplified the record. The record store in both user is the same.
- Justification: This feature improves the product significantly because it allows users to keep track on who and how much they owns people and who and how much owns them, it effectively solve a common problem between diner on payment splitting. Beside, the auto-balancing improve the usability as user can prevent the troublesome for keeping track on multiple debt with other user. Also, the storage to both user keep the same recording which greatly reduce the confusion.
- Highlights: This enhancement required an in-depth knowledge of the whole design, and good communication with other group member as it highly depends on other member’s feature (e.g.login/logout and group).
Minor enhancement: added 5 listing command that allows the user to list different type of debts (credit debts, debit debts, debt requests received, debt requests sent, all debts)
Minor enhancement: added selectRestaurant and selectOther command that allows the user to select item on list panel by command.
Minor enhancement: Modify the GUI to match the needs of the Makan Book.
- What it does: allows ist panel auto refresh when user data changed, added sub menu bar to allow user choosing different type of item to show on list panel, added auto update after user logout(empty the list panel and replace browser panel with notLoggedInPage).
- Justification: The feature improve the product usability the GUI change with user’s need, and simplified the listing process as the user can list everything with a simple click instead of finding/memorising and typing all different listing command. This enhancement also prevent the user privacy leakage and improve the security of the product as it no longer showing the user’s information after logout.
- Highlights: This enhancement required understanding on the GUI and knowledge of JavaFx.
Code contributed: [here]
Other contributions:
- Project management:
  - Managed releases v1.1 - v1.4 (4 releases) on GitHub
  - Wrote additional tests for debt feature to increase coverage by more than 6% (Pull requests #305, #308, #312, #326) *
- Documentation:
  - Update Readme.adoc, add mockup UI to match the project: #38
  - Did cosmetic tweaks to existing contents of the User Guide: #218
- Community:
  - Helped other members on implementation and debugging.
  - PRs reviewed (with non-trivial review comments) for other member.
  - Reported bugs and suggestions for other teams in the class: #141, #152, #155

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.

Sent add debt request: `addDebt`

User(Creditor) send a debt request to another user with specific amount. Record will be created between two users with a Pending status.
Format: addDebt u/USERNAME amt/AMOUNT

Examples:

addDebt u/katespades amt/4.30

Sent add debt request to a group `addGroupDebt`

User(Creditor) send a debt request to all other users in the group with specific amount. with amount will split equally to everyone in the group. Record will be created between with a Pending status.
Format: addGroupDebt g/GROUP amt/AMOUNT

Examples:

addGroupDebt g/CS2103 amt/4.30

Sent clear debt request: `clearDebt`

User(Creditor) clear amount between users. If the amount is equal to the debt, the status will change to Cleared. Otherwise, the amount will be balanced off from the debt.
Format: clearDebt u/NAME amt/AMOUNT

Examples:

clearDebt u/katespades amt/4.30

Accept debt request: `acceptDebtRequest`

Unique ID is generate for each debt, even though the input parameters are the same. This is to ensure that mutiple debts can be recorded and differentiated.

User(Debtor) accept request from another user(Creditor). The debt status will change from Pending to Accepted. If there are any other accepted debt between this two users, the debt will balanced off as one debt record.
Format: acceptDebtRequest u/NAME amt/AMOUNT id/ID
ID is unique and should copy from the Debt Card in UI when you test it

Examples:

acceptDebtRequest u/katespades amt/4.30 id/18103013460314(copy from UI)

Delete debt request: `deleteDebtRequest`

User(Debtor) delete/reject request send by other user if it is a wrong request.
Format: deleteDebtRequest u/USERNAME amt/AMOUNT id/ID
ID is unique and should copy from the Debt Card in UI when you test it

Examples:

deleteDebtRequest u/Kate123 amt/4.30 id/18103013460314(copy from UI)

List all creditor of the login user in list panel.
Format: listCreditor

List all debtor of the login user in list panel.
Format: listDebtor

List all debt request received by login user from other user in list panel.
Format: listDebtRequestReceived

List all debt request sent by login user to other user in list panel.
Format: listDebtRequestSent

List all debt history(regardless of status) of the login user in list panel. Format: listDebtor

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.

Payment Splitting Feature

Current Implementation

The payment splitting feature allow user to keep record for their debts, especially for gathering. Creditor can use the addDebt to create a request to debtor, or addGroupDebt to create a request to all other members in a group. A record of this debt will be made with a "pending" status and store to both user.

Debtor can then use the acceptDebtRequest to accept the request from creditor, which the status will be changed to "accepted", or reject and delete the request by deleteDebtRequest, which the the debt record will be deleted and removed from the storage. If the debt has been repaid, the creditor can use the clearDebt to mark the debt as "cleared". Only the user who initialized the debt(creditor) can clear the debt, and only the other user(debtor) can accept or delete the debt. An accepted debt needed to be confirmed by both users.

How the feature is implemented

The Debt class store creditor, debtor, amount, status and id(timestamp). The creditor and debtor must be a user, amount should be larger than zero, there are four status - PENDING, ACCEPTED, CLEARED and BALANCED and the id is a 15 digits long string to identify the debt. Debts are stored as an XML element under users.xml with all the above attributes mentioned as a string.

Why it is implemented that way

The debt is under PENDING when it is created, it is treated as a request to the debtor. The debtor needs to accept and make it to a ACCEPTED debt. The ACCEPTED debt need to be confirm by both side because we want to ensure its accuracy. Also, only the user who initialize the debt(creditor) can clear the debt to prevent the debtor clear or delete it for self benefit.

Alternatives considered.

Alternative 1: The debt can create by one user and do not need to be accepted

Pros:
- Easy to store
- Easy to mange
Cons:
- Lost accuracy
- Not fair to user

Alternative 2: The debt store separately instead of under user

Pros:
- Easy to store
- Easy to retrieve
- Easy to implement
Cons:
- Cannot achieve confirmation by user
- It is cumbersome to user

Add Debt

Prerequisites:
- User is logged in.
- Input debtor name should correspond to a valid user.
- Input amount should be larger than zero, less than a hundred million and less than two decimal places.
  1. Add Debt to a valid user with valid amount
    
    Test case: addDebt u/katespades amt/12
    Expected: A debt request of 12.000000 SGD to katespades is sent
  2. Add Debt to a invalid user with valid amount
    
    Test case: addDebt u/test123 amt/12
    Expected: Input user not exist.
  3. Add debt to a valid user with invalid amount
    
    Test case: addDebt u/katespades amt/99999999999
    Expected: Input amount must be larger than zero and less than a hundred million.

Add Group Debt

Prerequisites:
- User is logged in.
- Input group name should correspond to a valid group.
- User is a accepted user for the correspond input group.
- Input amount should be larger than zero, less than a hundred million and less than two decimal places.
  1. Add debt to a valid group with valid amount
    
    Test case: addGroupDebt g/2103 amt/12
    Expected: A debt request of 12.000000 SGD to other member in 2103 is sent

Accept Debt Request

Prerequisites:
- User is logged in.
- Input creditor name should correspond to a valid user.
- A PENDING debt exist between user(as a debtor) and input creditor, with amount and debt id match the input amount and debt id.

Unique ID is generate for each debt, even though the input parameters are the same. This is to ensure that mutiple debts can be recorded and differentiated.

Accept a debt request received
1. Test case: acceptDebtRequest u/meena567 amt/12 id/18111216484190
  Expected: Debt request(ID: 18111216484190) from meena567 of 12.000000 SGD has been accepted.
Accept a non-existent debt request received
1. Test case: acceptDebtRequest u/meena567 amt/18 id/110111216482190 (random id and amount)
  Expected: Input debt not exist.

Delete Debt Request

Prerequisites:
- User is logged in.
- Input creditor name should correspond to a valid user.
- A PENDING debt exist between user(as a debtor) and input creditor, with amount and debt id match the input amount and debt id.

Unique ID is generate for each debt, even though the input parameters are the same. This is to ensure that mutiple debts can be recorded and differentiated.

Delete a debt request received
1. Test case: deleteDebtRequest u/meena567 amt/12 id/18111216484190
  Expected: Debt request(ID: 181112172248904) from meena567 of 3.000000 SGD has been deleted.
Delete a non-existent debt request received
1. Test case: deleteDebtRequest u/meena567 amt/18 id/110111216482190 (random id and amount)
  Expected: Input debt not exist.

Clear Debt

Prerequisites:
- User is logged in.
- Input debtor name should correspond to a valid user.
- An ACCEPTED exist between user(as a creditor) and input debtor.
- Input amount should be larger than zero, less than the amount of corresponding debt.
  1. Clear Debt to a valid user with valid amount
    
    Test case: clearDebt u/katespades amt/7
    Expected: katespades’s debt of 7.000000 SGD is cleared.
  2. Clear Debt to a invalid user(not your debtor) with valid amount
    
    Test case: clearDebt u/chelchia amt/3
    Expected: There are no debt between you and input user
  3. Add debt to a valid user with invalid amount
    
    Test case: clearDebt u/katespades amt/0
    Expected: Input amount should be larger than zero.