GroceryPickUp

An online inventory system where small local store owners can update stock information of products and consumers of those stores can browse or reserve and pick up goods from those stores.

Required Models

Process Model

The selected process model is the “Phased Development: Incremental Development” process, model. The selected model fits well with our project plan, allowing us to provide various feature/project requirements in pieces.

Use Case Models

Use Case: Use Grocery Pickup Services
Scope: Grocery Store
Level: Summary
Intention in Context: The intention of the Customer is to access the grocery store’s catalog of available items and place an order for pickup.
Multiplicity: Multiple Customers can access the store and place pick-up orders at any given time. A given Customer can have multiple active sessions with the pickup service.
Primary Actor: Customer
Main Success Scenario:

1. Customer informs the System of their location.
2. System provides a list of available stores within a set distance, based on the geofencing of the user location.
3. Customer process to select an available store.
4. System provides a list of available products at the store.
5. Customer proceeds to add various products to their cart or remove items from their cart.

Step 5 can be repeated as many times as desired.
6. Customer authenticates or signs up with the System.
7. Customer proceeds to place an order for pickup.
8. System informs Customer that the order was successful.

Extensions:
2a. Locating the user/stores near the user is not successful. Use case ends in failure.
6a. Authentication or sign-up is unsuccessful. Use case ends in failure.

---

Use Case: Geofencing Users' Location
Scope: Grocery Store
Level: Subfunction
Intention in Context: The intention of the Person is to find the available stores within their area. Multiplicity: Multiple Customers can request a list of available stores.
Primary Actor: Customer
Main Success Scenario:

1. Customer provides their address/location information to System.
2. System calculates a list of available stores within a set distance of the address/location.
3. System informs the Customer of the available stores.
   

Extensions:
2a. Locating the stores near the user is not successful. Use case ends in failure.

---

Use Case: Add Product to Cart
Scope: Grocery Store
Level: User-Goal
Intention in Context: The intention of the Customer is to add/save certain products to purchase.
Multiplicity: Multiple Customers can add/save certain products to their cart at any given time.
Primary Actor: Customer
Main Success Scenario:

1. Customer requests a specific product .
2. System provides information about the specific product.
3. Customer informs the System to add/save the specific product to their cart, and in what quantity he chooses.
   Extensions:
   3a. Customer does not want the product. Use case ends in failure.
   3b. System informs the Customer that the item isn’t in stock at the location. Use case ends in failure.
   

---

Use Case: Remove Product from Cart
Scope: Grocery Store
Level: User-Goal
Intention in Context: The intention of the Customer is to remove certain products from their cart
Multiplicity: Multiple Customers can remove certain products from their cart at any given time.
Primary Actor: Customer
Main Success Scenario:

1. Customer requests the removal of a specific product.
2. System informs the Customer that the specific product has been removed from their cart.

---

Use Case: Place an order for pickup
Scope: Grocery Store
Level: User-Goal
Intention in Context: The intention of the Customer is to place an order for pick-up
Multiplicity: Multiple Customers can place orders for pickup at a given time.
Primary Actor: Customer
Main Success Scenario:

1. Customer informs the System to check out the products in their cart.
2. System validates that the Customer is authenticated and has items in their cart.
3. System informs the Customer of the current items in their cart..
4. Customer informs the System that the cart is correct and places the order.
5. System sends an email to the store owner to prepare the specific product.
6. System sends a confirmation email to the customer for pick-up.
7. System processes stock information.
   

Extensions:
(1-4)a. Customer informs the System that he wants to cancel the process of placing an order.
(1-4)a.1. System cancels the process of placing an order; use case ends in failure.
2a. System informs customer that cannot place an order when the shopping cart is empty; use case ends in failure.

---

Use Case: Authenticate
Scope: Grocery Store
Level: Subfunction
Intention in Context: The intention of the User is to authenticate with the System
Multiplicity: Multiple Users can authenticate simultaneously.
Primary Actor: User
Main Success Scenario:

1. User provides an email and password to the System.
2. System validates the email and password.
3. System informs User of a successful login.

Extensions:
2a. System ascertains that the email or password is invalid/wrong.
2a.1. System prompts User to try again. Use case continues at step 1.

---

Use Case: Sign Up
Scope: Grocery Store
Level: Subfunction
Intention in Context: The intention of the User is to sign up with the *System
Multiplicity: Multiple Users can sign up simultaneously. A given Customer can only sign up once with the System at a given time
Primary Actor: User
Main Success Scenario:

1. User provides a brand new email and password to the System.
2. System validates and stores the email and password.
3. System informs User of successful signup.
   

Extensions:
2a. System ascertains that the email or password is invalid/wrong.
2a.1. System ascertains that the email is already in use. Use case ends.
2a.2. System prompts User to try again. Use case continues at step 1.

---

Use Case: Manually Update Inventory Information
Scope: Grocery Store
Level: User-Goal
Intention in Context: The intention of the Store owner is to update inventory information when customers shop offline.
Multiplicity: Only one kind of product can be processed at a given time.
Primary Actor: Store Owner
Main Success Scenario:

1. Store owner manually updates the stock information.
2. System process the updating of stock information.

Extensions:
2a. Store owner informs the system that he/she wants to change the updating
2a.1. System confirms the request of the store owner; use case continues at step
2. 2b. Store owner fill out an invalid number as a new stock number
2b.1. System informs the store owner about the error; use case continues at step 2.

---

Use Case: Adding new products to inventory
Scope: Grocery Store
Level: User-Goal
Intention in Context: The intention of the Store Owner is to add new inventory items/products for the customer to shop from.
Multiplicity: The system should allow for simultaneous modifications of the inventory system. Primary Actor: Store Owner
Main Success Scenario:

1. Owner informs System that they want to add a new type of item.
2. System displays a form for Owner to fill in product details. (Name, price, image, description)
3. Owner fills out the form and informs the System of its completion.
4. System validates the data and adds the new product.

Extensions:
2a. Owner closes the form. The use case ends in failure.
4a. System finds form missing certain fields.
4a.1. Alert Owner what fields are invalid, return to step 2.
4b. System finds the item already exists.
4b.1. Alert Owner that the item exists, return to step 2.

---

Use Case: Register Store
Scope: Grocery Store
Level: User-Goal
Intention in Context: The intention of the Store Owner is to register their store on the system.
Multiplicity: A Store Owner can only register one store at a time. Other Store Owners may register their store simultaneously
. Primary Actor: Store Owner
Main Success Scenario:

1. Owner informs the System that they would like to register a store.
2. System authenticates if Owner is logged in.
3. If not, the System displays a form for Owner to fill in business and personal information to register.
4. Owner fills out the form and informs the System of its completion.
5. System validates the data and adds the new store.

Extensions:
2a. Owner fails to authenticate. The use case ends in failure.
3a. Owner closes the form. The use case ends in failure.
5a. System finds form missing certain fields or wrongly formatted data.
5a.1. Alert Owner what fields are invalid, return to step 3.
5b. System finds the store already exists.
5b.1. Alert Owner that the store exists, return to step 3.

---

Use Case Diagram

Domain Model Diagram

UI Design

Design Models

Architecture Design

Client-server pattern and a Publish-Subscribe pattern for the architecture pattern.

• Client-Server Pattern: we use the Client-Server pattern for store owners so that they can manually update the stock by themselves. There are some functions, such as creating 10 new products and increasing or decreasing product numbers. In this case, the store owners can access the server to call these functions.
• Publish-Subscribe Pattern: we use Publish-Subscribe Pattern because this pattern is suitable to our system from ordering to picking up. When a component announces publishing an event successfully, the subscribing component is notified.

Sequence Diagrams

Design Class Model

State Machine Model

Design Models

Units tests are done through postman to test the api end points.

Design Patterns

One of the design patterns we used in our project was the observer pattern on our checkout process. When an order is placed, the store owners are updated based on the new order. The dependents (store owners) in this case are notified via WebSockets when the new order comes in and updates automatically their orders page, displaying the new order. This allows the store owners to receive updates when a new order is placed and additionally update users for when an order is ready for pick up/an order can’t be completed.

Discussions on Design & implementation Decisions Made

The architectural design choice made during the project was to use a client-server architecture and a publish-subscribe architecture. The use of the client-server architecture allows users to communicate with the servers and get the most update to date availability information on products and stores located near them. Additionally, allows the users to place orders for products, and updates the new availability information for the product at that store. Built on top of the client-server architecture is the use of a publish-subscribe architecture which is used to update store owners of new potential orders. When a new order is created an event is published and the subscribed store owner would receive this new event/order and can handle it accordingly.
The architectural designs were implemented through the use of a MERN (MongoDB, Express, React, and Node.js) stack which helps to achieve our client-server design. The user would 22 interact with the server to pull store information, product availability, and other functionalities and the client-side react code would update the information accordingly. To achieve the publish-subscribe architecture, we used WebSockets built upon pusher.js to build out our checkout functionality and update the dependent users (store owners).