PROJECT: FoodZoom

Hello there! My name is Julius Sander, and I am a Year 2 Computer Science student in National University of Singapore. This is a report of my contributions to my most recent team project, FoodZoom.

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 Rahul Rajesh, Julius Sander, Monika Monuela, Koh Chi Hao and Tan Jin Ying.

FoodZoom’s core functionality includes:

  • Users being able to track food orders (visualise on a map) they have from customers

  • Managing deliverymen and assigning orders to them

  • Analysis of orders to display relevant statistics (order history, trending food etc.) to users

Ui
Figure 1. FoodZoom Home page

Summary of Contributions

Given below are contributions that I made to this application.

  • Major enhancement: Added deliverymen into the application.

    • What it does: Managers can add, delete or assign order deliveries to the deliverymen with this feature. Managers can also see and monitor the activity of the deliverymen from the main screen.

    • Justification: This feature provides managers the ability to manage deliveryman independently from orders, giving them added control over their order deliveries.

    • Highlights: This enhancement adds new commands into the application, and requires in-depth analysis of design analysis with regards to information storage.

  • Minor enhancement: Added IDs to resources for storage. This provides the application an ability to save and load complex associations between resources in the application.

  • Code contribution: RepoSense

  • Other contributions:

    • Project Management:

      • Manual & automated testing of application on major features

    • Community:

      • Regular Pull Request reviews (see here)

      • Extensive reviews of major features with non-trivial comments (#131, #50)

      • Reported bugs and gave suggestions for other group’s project ( Issue #136, Issue #134, Issue #130, Issue #126, Issue #123, Issue #121, Issue #118, Issue #109 )

    • Tools:

      • Integrated Github plugins (Coveralls, Travis) into the project, providing a seamless process to integrate code changes.

Contributions to User Guide

Given below are some of my contributions to the User Guide. They showcase my ability to write clear documentation targeting end-users.

Adding a delivery man : /deliveryman add [Since v1.2]

Allows you to add a delivery man to the list of delivery men
Format: /deliveryman add n/NAME

Examples:

  • /deliveryman add n/John Smith

Listing all delivery men : /deliveryman list [Since v1.2]

Lets you see the list of all delivery men in that were added for chronological order
Format: /deliveryman list

Deleting a delivery man : /deliveryman delete [Since v1.2]

Allows you to delete the specified delivery man from the list of delivery men
Format: /deliveryman delete INDEX

  • Deletes a delivery man at the specified INDEX.

  • Deliveryman that already have orders assigned cannot be deleted.

Examples:

  • /deliveryman list
    /deliveryman delete 2
    Deletes the 2nd delivery man in the list of delivery men.

  • /deliveryman find n/tom
    /deliveryman delete 1
    Deletes the 1st delivery man in the results of the find command.

Selecting a deliveryman : /deliveryman select [Since v1.4]

Allows you to select the specified deliveryman from the list of deliverymen.
Format: /deliveryman select INDEX

  • Select an deliveryman at the specified INDEX.

  • Renders a new view for the selected deliveryman - use /home to return the original view

Examples:

  • /deliveryman list
    /deliveryman select 2
    Selects the 2nd deliveryman in the list of deliverymen.

  • /deliveryman find n/david
    /deliveryman select 1
    Selects the 1st deliveryman in the results of the find command.

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.

Storage component

The following diagram shows how the Storage component is structured.

StorageClassDiagram
Figure 2. Structure of the Storage Component

API : Storage.java

The Storage component,

  • can save UserPref objects in json format and read it back.

  • can save the FoodZoom data in xml format and read it back.

    • FoodZoom allows deliverymen and users to be stored separately to prevent duplication of data while retaining object associations.

  • can save the Users' data in xml format and read it back.

The following diagram depicts the sequence diagram of how StorageManager saves changes every time a change is made in FoodZoom.

StorageSequenceDiagram
Figure 3. Interactions inside the Storage component for whenever ModelManager.saveFoodZoom(orderBook, deliverymenList) is called.

Design considerations

Aspect: Implementation of file storage structure for FoodZoom

This concerns the implementation of how application data is stored in a reloadable file.

  • Alternative 1: Use two separate files for the storage of FoodZoom data

    • Pros:

      • This solution presents a better separation of concerns between deliverymen and orders. This means that corruption of one file would not affect the other.

    • Cons:

      • It is more difficult to manage JXML marshalling from two separate files.

  • Alternative 2 (current choice): Use a single file to the storage of deliverymen and orders

    • Pros:

      • Coupling of deliverymen and orders allows more cohesion, as information like id for a deliveryman’s orders would be unusable without knowing the orders.

    • Cons:

      • Corruption of one file would mean corruption of all application data.

Add deliveryman feature

Current Implementation

The add deliveryman command allows the Manager to add deliveryman into FoodZoom. It ensures that the newly-added deliveryman is not a duplicate of an existing deliveryman.

The following diagram shows the sequence flow from the LogicManager to the ModelManager when a user enters a /deliveryman add command:

DeliverymanAddCommandSequenceDiagram

Figure 3.5.1.1 Sequence Diagram for deliveryman add command

From Figure 3.5.1.1:

  1. When LogicManager receives the execute command from the App, it calls the parseCommand method in OrderBookParser.

  2. OrderBookParser will receive /deliveryman as the command and instantiate DeliverymanCommandParser to parse the rest of the command.

  3. If the arguments specified in the add command are valid, a DeliverymanAddCommand would be created and returned back to the LogicManager.

  4. LogicManager would proceed to call execute of the DeliverymanAddCommand.

  5. A new deliveryman would be added and a successful CommandResult would be returned and displayed.

FoodZoom’s deliveryman is only stored with names currently, and can be search and listed only with names.

These names are checked against validations with the Name model, and this is a compulsory field for a deliveryman to be added. If the provided command either does not have a name, or is an invalid Name, a ParseException would be thrown.

Design Considerations

Implementation of DeliverymanAddCommandParser

This concerns the implementation and organization of a DeliverymanAddCommand

  • Alternative 1 (current choice): DeliverymanCommand is parsed first, then as a DeliverymanAddCommand.

    • Pros: Better modularization for all commands relating to Deliveryman

    • Cons: More complicated file & package organization

  • Alternative 2: DeliverymanAddCommand is parsed straight from OrderBookParser

    • Pros: Easier to manage file structure

    • Cons: Poor modularization of related Command classes.

Implementation of DeliverymanAddCommand

This concerns how deliverymen data is stored with relation to orders.

  • Alternative 1 (current choice): Deliverymen are stored in separate file

    • Pros: Allows for greater flexibility in how deliverymen interact with other resources like order/routes - better separation of concerns.

    • Cons: Harder to implement & maintain

  • Alternative 2: Deliverymen are stored in the same file as Order

    • Pros: Easier to implement & maintain

    • Cons: Deliveryman can only be accessed & treated as parts of an Order