PROJECT: Restaurant Management System

homepage

Overview

My name is Ang Wei Ming and I am a Year 2 student majoring in Information Security at National University of Singapore. Over the past 12 weeks I have been working on a project for the twinned module CS2113T/CS2101 with my team. The following is my portfolio for this project that we have completed.

This portfolio serves to provide an insight on the Restaurant Management System (RMS) project such as the purpose of this project, as well as the various features that our team has developed. Also stated are the different roles of each team members in the project and more importantly the contributions that I have made to the code and documentations.

Project Description

As frequent customers of restaurants, our team realized that most restaurants around the world are using inefficient systems to manage their restaurants. This includes taking orders on papers, calculating daily revenues at the end of the day, or even having a manual clocking machine for employees starting or ending their shift. Even if a restaurant uses alternative systems to mitigate such issues, they are usually segregated, causing the restaurant manager to maintain different systems all at once. All these can affect the way the restaurant is being run and possibly affect the quality of food and service negatively.

Therefore, our team decided to develop an All-in-One application called Restaurant Management System (RMS) that is able to handle the different processes within a running restaurant efficiently.

Restaurant Management System (RMS) is a CLI* based desktop application that can be used within a restaurant to perform various tasks such as listing menu items, order taking, as well as keeping track of members and employees. Restaurant managers will also be able to oversee the different processes more efficiently through a statistics feature.

* Command Line Interface. Refers to an user interface where an end user enters commands into the application by typing instead of clicking.

Features

Ui

Employee feature

Manage employees working in the restaurant by adding their information into the application. Employees will have to use the application to clock in when the shift starts and clock out when it ends.

Member feature

Customers of the restaurant can opt to sign up as a member in the application and will be able to accumulate points that can be used to offset future orders made with the application.

Members are also sorted into different tiers according to the points accumulated

Restaurant managers will use this feature to list new items on the menu or make adjustments to the menu such as pricing and this set of menu can then be used when taking orders.

Order feature

Cashiers can take customers' orders and this order information such as the sales revenue and the items ordered will be stored in the application. Additionally, orders can be tagged to a customer if he/she is a member.

Statistics feature

Able to display the statistics for the different features.

  • Employee statistics will show the attendance of their clocking and the current on duty personnel.

statsemp

  • Member statistics shows the number of new members over a period of time and the number of members in each member tier.

statsmember

  • Menu statistics tells us the sales of each menu items as well as the most and least popular items for each categories in the menu (e.g. mains or beverages).

statsmenu

  • Order statistics displays the total number of orders and the revenue for day, month and year, along with the revenue for the past 12 months.

statsorder

Team roles

  • Ang Wei Ming

    • In charge of the statistics feature.

  • Lim Kian Hong

    • In charge of the employee feature.

  • Pham Quang Minh

    • In charge of the order feature as well as code testing.

  • Salsabil Tasnia

    • In charge of the menu feature.

  • Tay Kang Ming

    • In charge of the member feature and the overall project coordination.

Summary of contributions

This section describes in details the various contributions I made to the code base as well as the documentations of the project. Depending on the type of contribution, it is split into different sections.

Major Enhancements

I added the statistics feature for all the different information stored in the application.

  • What it does: As described in the features sections of this portfolio, the statistics feature allows restaurant managers to view the overview statistics of the menus, orders, members and employees

  • Justification: This feature will be able to let the restaurant managers understand how the restaurant is currently performing and how much it is earning. It also allows the manager to keep track of their members and employees

  • Highlights: Data displayed under the different statistics commands have to be easy to understand as well as useful to the restaurant managers. It required thinking from a perspective of a restaurant manager to understand what kind of information he/she would want to see. This implementation was challenging because apart from the thought process, I had to make use of the limited data the other features were able to provide.

  • Credits: https://github.com/nusCS2113-AY1819S1/addressbook-level3

  • Code contributed: Project Reposense Page

Other Contributions

  • Enhancements to existing features:

    • Updated the GUI font: #94

    • Updated the GUI size: #112

  • Code Integration

    • Helped to integrate my team member’s codes during the start of the project when we worked without the Travis CI (Continuous Integration) tool

  • Documentation:

  • Community:

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.

Statistics

View Employee Statistics

Displays the employee statistics overview
Overview consists of the number of employees in the system, current on duty employees and all the employees' recent 3 activity
Format: statsemp

Examples:
statsemp

View Member Statistics

Displays the member statistics overview
Overview consists of the number of new member signups on the current day, month and year. It also includes the number of members in each member tier.
Format: statsmember

Examples:
statsmember

View Menu Statistics

Displays the menu statistics overview without any parameters or with optional parameters f/ or t/ to set date range for calculation of statistics
Overview consists of the number of sales for all the menu items in the system. Including menu items that was deleted but still exists in an order.
Bestsellers and least popular items are also displayed. Format: statsmenu [f/MMDDYYY] [t/MMDDYYY]

Examples:

  • statsmenu

  • statsmenu f/01122017 t/31122017

  • statsmenu f/01012017

  • statsmenu f/31122018

View Order Statistics

Displays the order statistics overview
Overview consists of the number of sales as well as the revenue for the current day, month and year
Past 12 monthly revenue are also displayed here. Format: statsorder

Examples:
statsorder

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

StorageClassDiagram
Figure 1. Structure of the Storage Component

API : StorageFile.java

The Storage component,

  • This component saves the RMS data in an XML format and is also able to load the XML back into data.

Statistics

Displaying Tables

As RMS is a CLI (Command Line Interface) based program, we are not able to display any graphical tables to the users. However, the alternative to this is to print out the tables in an Ascii format. Therefore, the AsciiTable class is created. This class helps to format any data into a string that is able to display as an AsciiTable.

In order to display this table correctly, the font being used in the results windows needs to be a monospaced* font.

*Monospaced fonts refer to fonts with every characters having equal width size.

Calculating Menu Statistics

The way the statistics for menu items are calculated is by iterating through the list of orders and incrementing a counter for each unique menu items every time it is sold. These counters are then sorted in ascending order and it will print the menu item with the most sales and the one with the least sales for the best sellers and the unpopular items respectively.

Documentation

We use asciidoc for writing documentation.

Site Template

The files in docs/stylesheets are the CSS stylesheets of the site. You can modify them to change some properties of the site’s design.

The files in docs/templates controls the rendering of .adoc files into HTML5. These template files are written in a mixture of Ruby and Slim.

Modifying the template files in docs/templates requires some knowledge and experience with Ruby and Asciidoctor’s API. You should only modify them if you need greater control over the site’s layout than what stylesheets can provide. The SE-EDU team does not provide support for modified template files.

Testing

Running Tests

There are three ways to run tests.

Method 1: Using IntelliJ JUnit test runner

  • To run all tests, right-click on the src/test/java folder and choose Run 'All Tests'

  • To run a subset of tests, you can right-click on a test package, test class, or a test and choose Run 'ABC'

Method 2: Using Gradle

  • Open a console and run the command gradlew clean allTests (Mac/Linux: ./gradlew clean allTests)

Method 3: Manual testing

  • Go to our github release page and download Rms.jar and Rms.txt

  • Put them into the same folder and run Rms.jar and confirm that the program is running with pre-populated data

  • Rms.txt is populated with existing data, which allows testers to test the program using the data in Rms.txt

  • Test the program using the user and the developer guide

See UsingGradle.adoc for more info on how to run tests using Gradle.

Types of tests

We have 1 type of test:

  1. Non-GUI Tests - These are tests not involving the GUI. They include,

    1. Unit tests targeting the lowest level methods/classes.
      e.g. seedu.addressbook.commons.UtilsTest

    2. Integration tests that are checking the integration of multiple code units (those code units are assumed to be working).
      e.g. seedu.addressbook.storage.StorageFileTest
      seedu.addressbook.parser.ParserTest

    3. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
      e.g. seedu.addressbook.logic.LogicTest

Dev Ops

Build Automation

See UsingGradle.adoc to learn how to use Gradle for build automation.

Continuous Integration

We use Travis CI and AppVeyor to perform Continuous Integration on our projects. See UsingTravis.adoc and UsingAppVeyor.adoc for more details.

Coverage Reporting

We use Coveralls to track the code coverage of our projects. See UsingCoveralls.adoc for more details.

Documentation Previews

When a pull request has changes to asciidoc files, you can use Netlify to see a preview of how the HTML version of those asciidoc files will look like when the pull request is merged. See UsingNetlify.adoc for more details.

Making a Release

Here are the steps to create a new release.

  1. Update the version number in MainApp.java.

  2. Generate a JAR file using Gradle.

  3. Tag the repo with the version number. e.g. v0.1

  4. Create a new release using GitHub and upload the JAR file you created.

Appendix A: Product Scope

Target user profile:

  • has a need to manage a restaurant with high volume of orders

  • prefer desktop apps over other types

  • can type fast

  • prefers typing over mouse input

  • is reasonably comfortable using CLI apps

Value proposition: manage restaurant faster than a typical mouse/GUI driven app

Appendix B: User Stories

Priorities: High (must have) - * * *, Medium (nice to have) - * *, Low (unlikely to have) - *

Priority As a …​ I want to …​ So that I can…​

* * *

Cashier

add, edit and delete orders made

collate the customer’s orders and send it to the kitchen

* *

Cashier

add new members, delete old members and view all members of the restaurant

keep track of which customer has a membership at the restaurant

* * *

Cashier

view all existing menu items of the restaurant

know which item the customer wants when taking an order

* * *

Cashier

view the recommended items in the menu

suggest customers on what to order of needed

* * *

Cashier

search for a menu item

find a particular item easily without viewing the menu lists

* * *

Manager

keep track of the restaurant business statistics such as daily revenue

understand if the restaurant is making a loss or not

* * *

Manager

keep track of employees wages

know how much I have to pay or how much I have paid to restaurant employees

* *

Manager

keep track of which menu item are sold the most

know which food is the best seller

* *

Manager

add, edit and delete items from the menu

keep my restaurant menu interesting

* *

Manager

list employees

to view the details of the employees working in the restaurant

* * *

Manager

add, edit and delete employees from the system

to manage information of the employees working in the restaurant

* * *

Chef

view all the orders made

know which order I need to prepare next

* * *

Chef

update the order status

let the customers know that their orders are ready

* *

Employee

clock in and clock out attendance

account for the time period which I am working

{More to be added}

Appendix C: Use Cases

(For all use cases below, the System is the Restaurant Management System (RMS), unless specified otherwise)

Use case: Taking a Customer’s Orders

Actor: Manager and Cashier

MSS

  1. User chooses to view the menu list

  2. FMS shows the list of items in the menu

  3. User informs the menu item and the quantity they wish to order

  4. FMS put that item and its quantity in the order

  5. Repeat step 1 to 4 until user confirm the order

  6. FMS acknowledge the order and add it to the system

    Use case ends.

Extensions

  • 1a. If a customer is in the restaurant’s member list, user can record them in the order so that bonus points can be accumulated when the order is confirmed.

    Return to step 1.

  • 2a. Menu list too long or does not have what the customer exactly wants

    • 2a1. User enters the find command and searches for the item customer is looking for

      2a2. FMS returns the list of items searched by the command the user entered

    Return to step 3.

Use case: Show Main Menu

System: Restaurant Management System (RMS)
Use Case: Show Main Menu
Actor: Manager, Cashier

MSS

  1. User chooses to view the Main Menu to see the categories of menu item available.

  2. RMS shows Main Menu of the restaurant.

Use case ends.

Use case: List Menu Based On Category

System: Restaurant Management System (RMS)
Use Case: List employees
Actor: Manager, Cashier
Preconditions: User executes the Show Main Menu use case to know the existing menu categories.
Guarantees:

  • List of menu items of a particular category will be displayed.

MSS

  1. User requests to list menu items of a particular category.

  2. RMS displays a list of the menu items of that category.

    Use case ends.

Extensions

  • 1a. RMS detects that an invalid type has been entered.

    • 1a1. RMS displays an error message stating what the valid item types are.

      Use case ends.

Use case: List Menu To View All Menu Items

System: Restaurant Management System (RMS)
Use Case: List employees
Actor: Manager, Cashier

Guarantees:

  • Displays list of menu items that exists in the menu database.

MSS

  1. User requests to view all the menu items of the menu database, not just based on their categories.

  2. RMS displays all the menu items that exist in the restaurant’s database.

    Use case ends.

Use case: Add Menu

Actor: Manager Preconditions: List Menu By Type command should be executed prior to this use case.
Guarantees:

  • New menu item is added to the RMS.

MSS

  1. User requests to add a new menu item with the required parameters.

  2. RMS adds a new menu item to the existing menu list with the parameters that were specified by the User.

    Use case ends.

Extensions

  • 1a. RMS detects that an invalid command format has been entered.

    • 1a1. RMS displays an error that says the command format is invalid.

    • 1a2. RMS displays information on the proper use of the command along with an example.

      Use case ends.

  • 1b. RMS detects that the new menu item to be added has the same name as one of the exisitng menu items.

    • 1b1. RMS detects this as an an attempt to add a duplicate menu item.

    • 1b2. RMS displays an error that says the employee already exists in Rms.

      Use case ends.

  • 1c. RMS detects that the price field entered is invalid.

    • 1c1. RMS dispays an error message stating the appropriate price field argument to be entered.

      Use case ends.

  • 1d. RMS detects that the type field entered is invalid.

    • 1d1. RMS dispays an error message stating what the valid item types are.

      Use case ends.

Use case: Delete menu

Actor: Restaurant Manager
Preconditions: List Menu By Type or Find Menu use case should be executed prior to this use case this use case.
Guarantees:

  • The specified menu item will be deleted from the RMS.

MSS

  1. User requests to delete menu item by using the index as shown on the list of menu items.

  2. RMS deletes a menu item of the specified index.

    Use case ends.

Extensions

  • 1a. RMS detects that an invalid index has been entered.

    • 1a1. RMS displays an error that says the index provided is invalid.

      Use case ends.

Use case: Find Menu

System: Restaurant Management System (RMS)
Use Case: Find Menu
Actor: Cashier

MSS

  1. User chooses to find menu items containing some keywords.

  2. RMS shows the menu items that contain those keywords.

Use case ends.

Use case: Menu Recommendations

System: Restaurant Management System (RMS)
Use Case: Menu Recommendations
Actor: Cashier

MSS

  1. User chooses to view the recommended items from the different categories.

  2. System displays the best seller items from each category as recommendations.

Use case ends.

Use case: List employees

System: Restaurant Management System (RMS)
Use Case: List employees
Actor: Restaurant Manager
Preconditions: User has started up the system.
Guarantees:

  • List of employees will be displayed.

MSS

  1. User requests to list employees.

  2. RMS displays a list of the employees.

    Use case ends.

Use case: Add employee

Actor: Restaurant Manager
Preconditions: "List employee" use case was used before this use case.
Guarantees:

  • New employee is added to the RMS.

MSS

  1. User requests to add a new employee with the required parameters.

  2. RMS adds a new employee to the list with the parameters that were specified by the User.

    Use case ends.

Extensions

  • 1a. RMS detects that an invalid command format has been entered.

    • 1a1. RMS displays an error that says the command format is invalid.

    • 1a2. RMS displays information on the proper use of the command along with an example.

      Use case ends.

  • 1b. RMS detects that there is an attempt to add a duplicate employee.

    • 1b1. RMS displays an error that says the employee already exists in Rms.

      Use case ends.

Use case: Delete employee

Actor: Restaurant Manager
Preconditions: "List employee" use case was used before this use case.
Guarantees:

  • The specified employee will be deleted from the RMS.

MSS

  1. User requests to delete an employee by using the index as shown on the list of employees.

  2. RMS deletes an employee using the specified index.

    Use case ends.

Extensions

  • 1a. RMS detects that an invalid index has been entered.

    • 1a1. RMS displays an error that says the index provided is invalid.

      Use case ends.

Use case: Edit employee

Actor: Restaurant Manager
Preconditions: "List employee" use case was used before this use case.
Guarantees:

  • Details of an employee is edited.

MSS

  1. User requests to edit an existing employee at the specified index with the optional parameters provided.

  2. RMS edits the employee at the specified index with the optional parameters that were provided.

    Use case ends.

Extensions

  • 1a. RMS detects that an invalid command format has been entered.

    • 1a1. RMS displays an error that says the command format is invalid.

    • 1a2. RMS displays information on the proper use of the command along with an example.

      Use case ends.

  • 1b. RMS detects that an invalid index has been entered.

    • 1b1. RMS displays an error that says the index provided is invalid.

      Use case ends.

Use case: Employee clock in

Actor: Employee
Preconditions: User has started up the system.
Guarantees:

  • Details of the time that the employee clocks in will be added to the system.

MSS

  1. User requests to record his/her clock in details into the system with his/her name.

  2. RMS clocks in the user’s attendance based on the current date and time using his/her specified name.

    Use case ends.

Extensions

  • 1a. RMS detects that the user did not use the clock out command yet.

    • 1a1. RMS displays an error that says the user has to clock out before clocking in.

    • 1a2. RMS displays information on the proper use of the command along with an example.

      Use case ends.

Use case: Employee clock out

Actor: Employee
Preconditions: User has started up the system.
Guarantees:

  • Details of the time that the employee clocks out will be added to the system.

MSS

  1. User requests to record his/her clock out details into the system with his/her name.

  2. RMS clocks in the user’s attendance based on the current date and time using his/her specified name.

    Use case ends.

Extensions

  • 1a. RMS detects that the user did not use the clock in command yet.

    • 1a1. RMS displays an error that says the user has to clock in before clocking out.

    • 1a2. RMS displays information on the proper use of the command along with an example.

      Use case ends.

Use case: List member

System: Restaurant Management System (RMS)
Use Case: List member
Actor: Restaurant Manager / Cashier
Preconditions: User has started up the system.
Guarantees:

  • List of members will be displayed.

MSS

  1. User chooses to view the entire list of members.

  2. RMS displays a list of the employees.

    Use case ends.

Use case: Add member

Actor: Restaurant Manager / Cashier
Preconditions: User has started up the system.
Guarantees:

  • New member is added to the RMS.

MSS

  1. User requests to add a new member with the required parameters.

  2. RMS adds a new member to the list with the parameters that were specified by the User.

    Use case ends.

Extensions

  • 1a. RMS detects that an invalid command format has been entered.

    • 1a1. RMS displays an error that says the command format is invalid.

    • 1a2. RMS displays information on the proper use of the command along with an example.

      Use case ends.

  • 1b. RMS detects that there is an attempt to add a duplicate member.

    • 1b1. RMS displays an error that says the member already exists in Rms.

      Use case ends.

Use case: Delete member

Actor: Restaurant Manager / Cashier
Preconditions: User has started up the system.
Guarantees:

  • Existing member is deleted from the RMS.

MSS

  1. User requests to delete an existing member in the list of members.

  2. RMS deletes the existing member at the index that was specified by the User.

    Use case ends.

Extensions

  • 1a. RMS detects that an invalid command format has been entered.

    • 1a1. RMS displays an error that says the command format is invalid.

    • 1a2. RMS displays information on the proper use of the command along with an example.

      Use case ends.

  • 1b. RMS detects that there is an attempt to delete a member that does not exist in the RMS.

    • 1b1. RMS displays an error that says the member index provided is invalid.

      Use case ends.

Use case: View employee statistics

Actor: Manager

MSS

  1. User chooses to view the employee statistics

  2. RMS shows overview employee statistics

Use case ends.

Use case: View member statistics

Actor: Manager

MSS

  1. User chooses to view the member statistics

  2. RMS shows overview member statistics

Use case ends.

Use case: View menu statistics

Actor: Manager

MSS

  1. User chooses to view the menu statistics

  2. RMS shows overview menu statistics

Use case ends.

Use case: View order statistics

Actor: Manager

MSS

  1. User chooses to view the order statistics

  2. RMS shows overview order statistics

Use case ends.

  • 1a. RMS detects that there are currently no employees recorded.

    • 1a1. RMS shows a message that says there are currently no employees recorded.

      Use case ends.

{More to be added}

Appendix D: Non Functional Requirements

  1. Quality requirement: The system should be efficient enough for restaurants which want to add a management system for their orders. The orders will be processed in less than 5 clicks.

  2. Performance requirements: The system should respond within three seconds as speed and efficiency is important for a restaurant.

  3. Project scope: The product is not developed for the customers of the restaurants to use.

{More to be added}

Use case: View employee statistics

Actor: Manager

MSS

  1. User chooses to view the employee statistics

  2. RMS shows overview employee statistics

Use case ends.

Use case: View member statistics

Actor: Manager

MSS

  1. User chooses to view the member statistics

  2. RMS shows overview member statistics

Use case ends.

Use case: View menu statistics

Actor: Manager

MSS

  1. User chooses to view the menu statistics

  2. RMS shows overview menu statistics

Use case ends.

Use case: View order statistics

Actor: Manager

MSS

  1. User chooses to view the order statistics

  2. RMS shows overview order statistics

Use case ends.

  • 1a. RMS detects that there are currently no employees recorded.

    • 1a1. RMS shows a message that says there are currently no employees recorded.

      Use case ends.