Ryan Tay Jia Jian - Project Portfolio for DeliveryMANS

1. Introduction

DeliveryMANS is a delivery management system that allows administrators of delivery centres to manage their deliveries effectively and efficiently. There are 4 management contexts to DeliveryMANS which are order, customer, deliverymen and restaurant where each context will manage their individual parts. I am in charge of the customer side of the system and have implemented an automated tagging system to tag the customer’s favourite cuisine automatically.

This document will include a summary of my coding contributions and an excerpt of the user guide and developer guides that I have documented.

2. Summary

This section is a summary of the feature implemented, code contributions and documentations made to the project.

2.1. Feature - Automated tagging system

When the user adds an order, the tags are sent to the customer and the system will display the top two appearing tags on the UI. If there are new orders added, the system will evaluate all the tags of that customer and determine which are the top two tags.

This feature allows the user to spend less time to find the trend and spend more time to put the trend data to use.

2.2. Code contributed

Implementation of basic context switching functions - #53
Improvement to context switching functions based on feedback from team members - #117
Implementation of automated tagging system - #187

2.3. Documentation contributed

Edit Developer Guide to be suitable for the project DeliveryMANS - #84

3. Contributions to the User Guide

This section of the document is an excerpt from our DeliveryMANS - User Guide focusing on the customer side of commands that I am tasked to implement.

3.1. Customer commands

These are commands pertaining to customer context of DeliveryMANS. The screenshot below shows how the customer context will look like in DeliveryMANS.

This is a customer and its information. Each card will display the customer’s username, favourite cuisine, name, phone number, address and the number of orders the customer has made.

3.1.1. Adding a customer: `add`

This command allows you to add a new customer to the customer list. USERNAME, NAME, PHONE and ADDRESS are necessary to a customer.

The USERNAME of customer cannot be changed after adding.

Format: add u/USERNAME n/NAME p/PHONE ad/ADDRESS

Example: add u/JohnDoe n/John Doe p/91234567 ad/311, Clementi Ave 2, #02-25

3.1.2. Editing a customer: `edit`

This command allows you to edit an existing customer in the customer list. The index of a customer needs to be provided while the information to edit are optional.

Format: edit INDEX [n/NAME] [p/PHONE] [a/ADDRESS]

Example: edit 1 n/John Woe p/97654321

Example use case

You want to change John Doe’s phone number but his address stays the same.
Simply type in edit 1 p/97654321 into the command line and press enter.

The result box will display that the edit is successful and John Doe’s phone number has changed.

Requirements

The index INDEX provided must be within the customer list size and be greater than or equals to 1.

3.1.3. Deleting a customer: `delete`

This command allows you to delete an existing customer in the customer list. The index of a customer needs to be provided.

Format: delete INDEX

Example: delete 1

Requirements

The index INDEX provided must be within the customer list size and be greater than or equals to 1.

3.1.4. Viewing a customer’s order history: `history`

This command allows you to view a customer’s order history. The index of a customer needs to be provided.

Format: history INDEX

Example: history 1

Example use case

You want to view John Doe’s order history.
Simply type in history 1 into the command line and press enter.

John Doe’s order history will be listed on the right panel.

Requirements

The index INDEX provided must be within the customer list size and be greater than or equals to 1.

4. Contributions to the Developer Guide

This section is an excerpt from our DeliveryMANS - Developer Guide focusing on the implementation I have made on the application.

4.1. Automated tagging of customer

Tags determine the customer’s favourite cuisine. It is helpful to the user as having this information will enable the user to make better analysis on the current trend of food. Although we can opt for the user to manually add in tags, it might be problematic once the number of customers in the database gets too large for a single user to handle. Thus, this feature aids the user by automatically tagging the customer based on the customer’s order history.

4.1.1. Implementation

The Tag of the Customer is related to the Tag of the Restaurant. If an Order has been added to the database, the Tag of the Restaurant will be added to the Tag of the Customer. If the Customer has multiple Orders, the Tag that will be shown on the CustomerCard will be the highest two Tags. This is the main process on how the application automatically tags the customers.

An activity diagram below shows the automated tagging process when adding an order:

Figure 1. Activity diagram of tagging process

Another function called changeMainTag() is used to change the main Tags of the Customer to show on the CustomerCard. The activity diagram below shows how the application determines the top two Tags:

Figure 2. Activity diagram of changing Customer's main Tags

4.1.2. Design considerations

Aspect: Method of editing Customer's Tags

Alternative 1 (current choice): Adding, deleting and editing of Order will edit the Tags in Customer.
- Pros: Only the commands that add, delete or edit an Order will require editing the Customer's Tags.
- Cons: Creates more dependency between Customer and Command classes.
Alterative 2: Customer storing a list of Orders and iterate through that list to get the number of Tags.
- Pros: Editing Customer's Tags only happen in the Customer object itself and doesn’t need to depend on information from other objects.
- Cons: Every single change to any Order has to be reflected on Customer's Order list. Including edits to Orders made in Deliverymen and Restaurant context. This makes Customer have a lot of dependency with other classes.

We chose to go with the first alternative as Customer class will have lesser dependency with other classes when editing tags. In addition, displaying the Customer's order history will only require Customer to access the OrderDatabase to get the list of orders. Both of these requirements together still makes the Customer class have lesser dependency with other classes compared to implementing the second alternative that makes the Customer class have dependencies with every Order related classes.

Aspect: Method of storing Tags

Alternative 1 (current choice): Using a map to store the Customer's Tags where key is the Tag and value is the number of tags.
- Pros: Faster access of Tags in the map and getting the number of a certain Tag only takes O(1) time.
- Cons: More memory is needed to store the information. A map to store all Tags and a set to store the main Tag(s) to display on CustomerCard.
Alternative 2: Using a list that stores all Tags that are in Customer.
- Pros: The list is capable of storing all of the Tags that Customer has.
- Cons: The list needs to be iterated through to determine the top Tag(s) of Customer.

We chose to go with alternative 1 as we believe speed is more important to the user and sacrificing memory space is the better choice.