☀️ Note: Some of our tests evoke pop-up responsive message, but Action cannot close the message dialog, thus the Github Classroom Workflow failes but all the implementation, including the tests themselves, are correct.

🍣🍦🥟Welcome to FOODQEE🍜🌯🍲

Are you a food lover who is looking to try some new restaurants? Are you a restaurant owner who is seeking more customers? Have you ever been annoyed by the huge line up to your favorite food truck or the unpleasant wait you have to stand by in cold winter? If any of these applies to you, FOODQEE is here to help!

🍤Table of Contents

1. Introduction
2. How to Run
3. Screens and Features
4. Database
5. Architecture and Design Pattern
6. Test Coverage
7. Future Enhencemants
8. Use of Github Features
9. Closing Words

🍿Introduction

In this project, we aim to provide a platform for both customer and restaurant owners to place and process food orders. Customers are able to browse and search for the restaurant of their preference, add items to the shopping cart from the menu of that restaurant, and place the order. Restaurant owners are able to upload and edit their menus, see the list of orders that have been placed and process those orders by changing the order status. Users of FOODQEE must verifiy their account before entering, thus we ensures all users are reliable and safe.

More details will be introduced in the next few sections of this document.

🍩How to Run

1. Run the file named AppRun and a JFrame window will pop out, this is our welcome screen.
2. The window can be closed by clicking on the top left/right corner(depending on Mac or Windows) as you would do to all other windows.
3. The components will navigate between each other on click according to their functionalities.
4. Note that there are also runnable files in some of the use cases, these are used to run the use cases separately. They are very helpful when doing UI design since displaying a specific screen does not require navigating to that screen from the very beginning.

🍺Screens and Features

1. Welcome Screen.

• This screen is the first screen that shows up when the program is successfully runned.
• It contains a simple greeting message and two buttons used for register and login.
• We support registering two different types of account: user and restaurant.
• Login and Register will both direct you to a separe window.
• You can try to register new account or login with our sample account given in the table below:

	username	password
Restaurant	yinuo's res	123456
User	davidlin123	lzy123456

2. Login/Register Window.

• Depending on what action is taken on the previous screen, the login or register window will be called and allows users to log in to their existing account or register a new account.
• On the login screen, you can enter the username and password, then click on "login as restaurant" or "login as user". "Cancel" will take you back to the welcome screen.
• When the given cridentials are correct, there will be a "success" message dialog. It may also say "You need to verify" if the account is not verified, we will introduce more details on this in the next section. If the given username and password does not math to any user in the database, login will fail.
• Note that the login is case sensitive, that means try logging in as a restaurant with the user crediential will fail, pop-up dialog will show the message "failed", and vice-versa.
• If loggin succeded, you will be directed to the homepage.
• New Account registration is also divided by the type of user, which requires a set of different information.
• It is worth mentioning that we used Regex to determine whether the given email is a valid email. For instance, something like "123456" or "hello" are both invalid. Username also has to be more than 6 characters.
• Attempts to register an account with a username that already exist in the database will also fail, message with "user already exist" will be given when this happens.
• To better protects user information, we used SHA256 to hash the password before saving it to the data base, therefore even in the case of the data leak, the origional password cannot be revealed.

3. Verification Window.

• New users need to verify their account before using this platform. In this window, users can request a verification code being sent to their entered email. After the user has received the code and entered it into the field provided, it will be compared with the code sent. Successful match will change the status of the account to "verified".
• Note that the verification code expires in 5 minutes from the time it was issued.
• Entering incorrect or expired verification code will not pass the verification.

4. Restaurant/Customer homepage.

• The restaurant homepage consists of the following 3 different tabs:

• Order History: Restaurant owners will be able to view the orders received and change the status of the order from this page. Status includes received, preparing, ready for picked up, picked up, order completed, and cancelled. Food items, quantity, total revenue can be seen if "view details" is clicked. After making any modification, clicking the "Refresh" button will display the changed contents. “Show current orders” filters out ourders that are completed or cancelled, and displays only orders that are qurrently in the queue.

• When an user placed an order to the current restaurant, there will be a pop up message "You have a new order".

• Menu: The current menu of this restaurant. It also supports editing the menu by add, delete items, or modify the information of existing food items. Add and Edit will be done in seperate screen. Similar to becore, "Refresh" will display changes to the menu, but deleting food does not require manual refresh.

• Profile: Shows the account information. Restaurant owners can modify all informations on this page, including the password, and logout of the acount.

• When multiple screens are opened, logging out the account will close all windows simotaneously.

• The user homepage consists of the following 4 different tabs:

• Restaurants: Displays all restaurant in the platform. The search bar allows fuzzy search of keywords, thus the search result contains all "close" match of the key word, ratehr than "exact match". By clicking in "Details", there will be a separate window that contains the restaurant's menu, from there the user can add items to the cart, with their desired quantity.
• Shopoing Cart: Displays items that has been added to the cart, checking out will place the order. The shopping cart is initially emptu, after adding items and refreshing the page, it will shows the current restaurant, and items in the cart. Users can also modify the cart by removing unwanted items. It is worth mentioning that the shopping cart will be cleared if you enter a differnt restaurant and add items from that restaurant to the cart, this is made to avoid place an order that contains food from different restaurants.
• Order History: All orders that the current user has placed. After placing an order from the cart page, the order will be added to here. Similar to the restaurant homepage order historm, "Show current order" filters out orders that have been completed or cancelled, leaving only orders in queue. User can make reviews to past orders and view the details of each individual order(items, total price and etc.)
• Profile: Acount information of the current user. Can modify the acount info and password, as well as log out, same as restaurant homepage.

🍔Database

In this project, we used MongoDB as our database, which is a online document-oriented NoSQL database. We created 6 different collections to store our data:

1. AuthInfo: Stores the username and password for all users(restaurant owners and customers), along with an unique user id.
2. Menus: Stores menus and the restaurant(id) of this menu.
3. Orders: Stores all orders with their: status, time placed, customer(id) that placed the order, restaurant(id) that receives the order.
4. Restaurants: Stores restaurant name, location, email, phone, and a unique restaurant id.
5. Users: Stores customer's name, email, account verification status and an unique user id.
6. Verification: Stores the verification code that has been set, with the user(id) that receives the code and the time it was requested.

Note that there are several overlap in the data saved across differnt collection, for instance, any order will contain a user id of the user that pleace the order, and a restaurant id of the restaurant that receives the order. Each Menu also saves a restaurant id.

🍟Architecture and Design Pattern

We construct our project in a way that it is consistent with both the Clean Architecture and SOLID principle. The UI and algorithms also interact in a way that follows the pattern MVPC Model-View-Presenter-Controller design pattern. Each use case has its own package and all components, interactors, presenters and controllers are organized in the package of the by use case.

🍕Test Coverage

• We tested most of the use case through controller/interactor, because all the other methdos/classes are reacheable from there.
• We have imlemenetd responsive message dialogs, where each individual action will evoke a message window telling the user whether the current actill fails or success. Such dislogs also pops up when running tests, and the tests only pass when the dialog is closed. Since github Action cannot close the poped up windows, the tests fails when it trys to run them.
• Testing of all getters and setters are omitted as those methods are simple.
• The table below is our test coverage summary:

🍙Future Enhencements

• Payment System.
• Allow uploding photos to the menu.
• Estimated wait time calculator for users.
• And more.

🥗Use of GitHub features

1. We use the discussion page to open up the floor for everyone to express their thoughts and ask questions. Important deadlines and decisions are also posted there using the announcement feature.
2. The issues are used to track our progress of implementing the project. We have one issue for each use case in the beginning, assigned to each member for implementation. During the process, whenever new problems or ideas arise, we make a new issue to take note of and address it.
3. Branching: we made 1 branch for every single feature. Each time the new commit from a branch is merged to the main, that branch will not be used anymore. This workflow has prevented us from the possible mess caused by frequent pull and merge.
4. Merging and Pull request: We assigned 1 member to keep an eye on the pull requests and merge in the pull requests after having confirmed that there's no conflict and every member in the team is aware of the new changes.

🍱Closing Words

Thank you so much for taking the time to read over this document. We also hope to be able to continue this project in the future, adding more features and functionalities and we will appreciate any comments and feedbacks!

Team members: Allen Xu, Leo Liu, Yinuo Zhao, David Lin, Jackon Su, Kevin Yang, Peter Yang.