Koh Chi Hao - Project Portfolio

Project: FoodZoom

Hello there! I am Koh Chi Hao. I am currently studying at National University of Singapore (NUS) in School of Computing and majoring in Computer Science. As of right now, I am studying my second year of study. This portfolio serves the purpose of documenting what I have contributed to the project and my roles in it.

Overview

FoodZoom is a desktop food delivery management application designed for food businesses to streamline their delivery process. FoodZoom is responsive and quick, allowing managers to plan routes for order delivery and dispatch them to delivery men using the Command Line Interface (CLI). The delivery men can also use this application to view their delivery routes and increase their efficiency. FoodZoom is built by 5 computer science student namely Koh Chi Hao, Rahul Rajesh, Julius Sander, Monika Manuela Hengki and Tan Jin Ying. The picture below shows the home page of FoodZoom.

Summary of Contribution

Given below are sections I contributed to the application. They showcase my ability to write and manage the code within the project.

Major enhancement: added the ability to sign up, login and logout for the user.
- What it does: It allows the user the sign up for the application when they first use it. Subsequently, they can login into the application to create orders and dispatch them. At the end of the day, they can easily log out from the application to protect the details.
- Justification: This feature improves the security of the application as it allows only the manager of the shop to use the application and no one else. As such, the application will be protected against random people from the shop attempting to foil the data.
- Highlights: This enhancement will affect all the current and future commands because only certain commands can be used when the user is not logged in. As such, when commands in the future are implemented, they are required to be place under either authorised or unauthorised commands.
Minor enhancement:
- Implemented major UI changes when user log in and log out.
- Updated status bar with username after the user log in.
- Add /order done command.
Code contribution: RepoSense
Other contributions:
- Project management:
  - Managed release for v1.1, v1.2, v1.2.1, v1.3
- Documentation:
  - Update DeveloperGuide to remove and update all non-relevant stuff (Pull requests #90)
- Community:
  - Review weekly Pull Requests
  - Contributed to CS2103T forum discussion (questions I posted)
  - Reported bugs and suggestions for other projects ( #186, #188, #189, #194, #198, #200, #206, #207)

Contributions to User Guide

This section shows my contributions to User Guide for the project. It showcases my ability to write user-centric documentation.

Sign up for a new manager account so that the manager can use the application. Once you sign up, you will be automatically logged into the application. Since the managers using the application is working for one stall, they will have access to that stall data and see the same home screen

Format: /signup n/NAME u/USERNAME pw/PASSWORD

Examples:

/signup n/John Doe u/johndoe pw/johndoepassword

Login into the application so that the manager can use the application. Once you login, you can use the authenticated commands. Since the managers using the application is working for one stall, they will have access to that stall data and see the same home screen

Format: /login u/USERNAME pw/PASSWORD

Examples:

/login u/manager pw/password

Logout from system : `/logout` `[Since v1.3]`

Logout from the application.

Format: /logout

Mark an order as completed : `/order done` `[Since v1.4]`

Mark an order as completed. Format: /order done ORDER_INDEX

Mark ORDER_INDEX as completed.
The index refers to the index number shown in the orders list.
The index must be a positive integer 1, 2, 3, … and must be within the number of displayed orders.
There must be only 1 order index.
Only ongoing orders can be marked as completed.

Examples:

/order list
/deliveryman list
/assign d/2 o/1
/order done 1 Mark order number 1 as completed.

After you mark an order done:

Figure 1. Order status changed to Completed after the order is marked as done

Contributions to Developer Guide

This section shows my contributions to Developer Guide for the project. It showcases my ability to write a technical document and the technical aspect of my contribution to the project.

Current Implementation

The /login command allows the Manager to login into the FoodZoom application and use authenticated commands like /order add, /order edit, /order list, … .Basically all the /order commands and /deliveryman commands. The only commands that can be used without logging in are /signup, /login, /help and /history. The format of this command is /login u/[USERNAME] pw/[PASSWORD].

In our current implementation, the /login command inherits from Command class. 2 components, Logic and Model are involved in the execution of this command. The Logic class is responsible for parsing the user input and the Model class deals with storing the UserSession and checking if the user is logged in or not.

Below is a sequence diagram that illustrates how these 2 components interact when the /login command is executed:

Figure 3.1.1.1 Sequence diagram to illustrate Logic component interactions for /login.

Figure 3.1.1.2 Sequence diagram to illustrate Logic and Model component interactions for /login.

As shown above, execution of the /login command comprises of the following steps:

LogicManager invokes the parseCommand method of OrderBookParser, taking in user inputs as arguments.
During the parseCommand method call, an instance of LoginCommandParser will be created with the keyword /login is matched. LoginCommandParser then extracts the remaining user inputs and a LoginCommand instance will be returned provided that the user’s input is correct.
LoginCommand then invokes isRegisteredUser method which belongs to ModelManager class. The ModelManager will the invoke IsRegisteredUser method in UsersList to check if the user is in the list of users.
After checking if the user is in the list, if it returns true then storeUserInSession method will be invoked to store the User object inside UserSession. The execute method will then return a CommandResult with success login message.
If the user is not in the list, execute method will just return a CommandResult with failure to login message.

Design Considerations

Alternative 1 (current choice): Check if user is in users list.
- Pros: Easy to implement.
- Cons: Not necessary to implement users list because there will only be 1 user.
Alternative 2: Automatic login even after application is opened more than once.
- Pros: User do not need to login multiple times after application is re-opened.
- Cons: Difficult to implement because it requires caching user details locally.

Alternative 1 (current choice): Create a unique user list to store all the user and create a users.xml to store locally.
- Pros: Easy to implement and you can make sure that there is only unique users.
- Cons: Not necessary because there would only be 1 user using the application.
Alternative 2: Store user session inside User class
- Pros: Easy to handle login session.
- Cons: Would break the SRP (Single Responsibility Principle) because User class should only be about the user and nothing to do with login at all.

Aspect: Checking if user is logged in

Alternative 1 (current choice): Check if user is logged in after command is parsed
- Pros: It is easy to implement and it doesn’t violate the SRP because it wouldn’t make sense to check if the user is logged in inside a method that is supposed to be parsing the user input.
- Cons: User is able to type authenticated commands like /order add and receive a parse exception which is the incorrect behavior.
Alternative 2: Check if user is logged in before command is parsed
- Pros: It is easy to implement.
- Cons: It breaks the SRP because parseCommand method should only be used to parse commands and not check for user logged in status.