diff --git a/authentication/passwords.txt b/authentication/passwords.txt index 3d93be76..35cb3951 100644 --- a/authentication/passwords.txt +++ b/authentication/passwords.txt @@ -1,4 +1,7 @@ aturing:0d911297a1e34f4fcce78537f9aaa66a:b93727798b520dc10d145b53909c061f082ff14cd5f8cb4ab24c3b71bfa57d7e12e1296029be74c06a0d91ba32756f9fc978047fbe7232be67f94dfc1de9ced9 dritchie:e11d3b1a66b1ad362223c30b78138519:67aff785bd17ac24448d491926ff7aadd8fa75e51a2f7a9bfc31889bad0adcd2989061a27ccd9eff9e5e31f2bc14b5c193727e116dc8dc48259acb3919171cd4 llamport:89d0e5fe8d06ec113839c8f319d7033e:9171d14954eeda4e70777c23d98e349818125cdaeb884ff97ebf8cc0a9c7778f54ce394256588148132a03ebea891e44077c659e6c0132fa87a8cf77e436ae11 -bliskov:e71dda285effa69e1c29ac810fe7a986:1e4b9ae956cad1385cfa6fffd8323dd16c3fe18c54e6447e49bddef2138d042e84e1505a541c6ef19a5026e684b2559efd366145870a0a8d4d4173c0877f6cd2 \ No newline at end of file +bliskov:e71dda285effa69e1c29ac810fe7a986:1e4b9ae956cad1385cfa6fffd8323dd16c3fe18c54e6447e49bddef2138d042e84e1505a541c6ef19a5026e684b2559efd366145870a0a8d4d4173c0877f6cd2 +asteene:95dbb2bc2b4e761c53c9c71e64c94a59:dba160be834504fe81be71efc8fb9f385538c04f0e08847eb8d2ec69984272303f1e960f4d6c59a09e2e0425c507547074b44641f1b04af86e7e96340c02dcb6 +mansmohaali:3f3afcc3eef86052d7136609f9abe828:376d73187de23a68e281d25e69c87a1b0071ed66613f8a487d713178812a905927fc74e38a36376621a7e1540ab8b92d34e8728286fae557ee6a05652113f6e7 +user:9be32a9c75f5fa6307194f34b36d5b03:7c294cf6c011c99460302290e34f3ff9bbd3ddb95339b803a5decd180238d1a56c246c7ce3d2a2344e40026576f8d6964cb4779dfe9182538bceac61beb5d807 \ No newline at end of file diff --git a/core/classes.puml b/core/classes.puml new file mode 100644 index 00000000..9c62d774 --- /dev/null +++ b/core/classes.puml @@ -0,0 +1,24 @@ +@startuml classes +set namespaceSeparator none +class "Sessions" as core.session.Sessions #aliceblue { + sessions : dict + add_new_session(username: str, db: Database) -> None + get_all_sessions() -> dict + get_session(username: str) -> UserSession + remove_session(username: str) -> None +} +class "UserSession" as core.session.UserSession #aliceblue { + cart : dict + date : datetime, NoneType + db : Database + total_cost : int + username : str + add_new_item(id: str, name: str, price: int, quantity: int, discount: float, tax_rate: float) -> None + empty_cart() -> dict + is_item_in_cart(id: str) -> bool + remove_item(id: str) -> None + submit_cart() -> None + update_item_quantity(id: str, change_to_quantity: int) -> None + update_total_cost() -> None +} +@enduml diff --git a/core/packages.png b/core/packages.png new file mode 100644 index 00000000..d68ad8e7 Binary files /dev/null and b/core/packages.png differ diff --git a/core/packages.puml b/core/packages.puml new file mode 100644 index 00000000..9ffa5cec --- /dev/null +++ b/core/packages.puml @@ -0,0 +1,10 @@ +@startuml packages +set namespaceSeparator none +package "core" as core #aliceblue { +} +package "core.session" as core.session #aliceblue { +} +package "core.utils" as core.utils #aliceblue { +} +core.session --> core.utils +@enduml diff --git a/diagrams.md b/diagrams.md new file mode 100644 index 00000000..a7bb2df7 --- /dev/null +++ b/diagrams.md @@ -0,0 +1,138 @@ +# Project 2: Design + +## Introduction + +In this phase, you will be mapping out your project and creating easily understandable diagrams that will help you and your team know your codebase inside and out. This also makes it much easier to communicate the flow of your application to less technical audiences or anyone who is new to your project. We will be using `pyreverse` and `plantuml` to help us create, update, and visualize our diagrams. + +This activity will require you to generate Class, Package, Use Case, and Sequence diagrams for your project. If you are unfamiliar with these diagrams, you can find an in-depth explanation of each diagram type [here](https://www.uml-diagrams.org/) or reference [this article](https://nulab.com/learn/software-development/uml-diagrams-guide/). + +## Task 1: Installations + +- Use `pip` to install the following packages: + - `pylint==2.17.1` + - `plantuml==0.3.0` +- Add both of these packages to your `requirements.txt` file, including the version numbers. Follow the format of the `flask` package in the file. +- Install `Graphviz` on your machine. You can find download instructions for your operating system [here](https://graphviz.org/download/). + +## Task 2: Initial Structure Diagrams + +- Each group member will create diagrams for at least one of the following subdirectories/files of your project: + - `authentication`: requires a package diagram + - `core`: requires both a package diagram and a class diagram + - `database`: requires both a package diagram and a class diagram + - `testing`: requires a package diagram + +All of the above diagrams must be generated, so split this work evenly and push and pull code often. To generate a class diagram for a subdirectory or file, you must first generate the `plantuml` files using `pyreverse`. Then, you must use `plantuml` to generate the diagram from the `plantuml` file. Here's an example of how to do this for the package diagram in the `testing` subdirectory. + +```bash +pyreverse --output puml --colorized -A --output-directory testing testin # generates testing/package.puml +python3.10 -m plantuml testing/package.puml # generates testing/package.png +``` + +Since `testing` has no classes, we do not need a class diagram, but if we did, we would change the `testing/package.puml` to `testing/classes.puml` in the last command. + +- Delete the `.puml` files that do not have a corresponding `.png` file. For example, since `testing` has no classes, we would delete `testing/classes.puml`. +- For each subdirectory, create copies of the `.puml` and `.png` files with naming schemes that include `_initial` in the name. + - For example, `testing/package.puml` would have a copy called `testing/package_initial.puml` and `testing/package.png` would have a copy called `testing/package_initial.png`. + +## Task 3: Update Structure Diagrams + +- Begin planning the implentations necessary to fulfill requirements listed in your `SRS.md` file. +- Go to the corresponding subdirectory, and update the `.puml` file to reflect the changes you have planned. + - For example, by implementing a method called `delete_cart` in the `UserSession` class from `core`, my `core/classes.puml` file would look like the one shown below because I added a line to the `UserSession` class that says `delete_cart(id: str) -> None`. + - [PlantUML class diagram documentation](https://plantuml.com/class-diagram) +- Be sure to regenerate the `.png` file for each subdirectory after you update the corresponding `.puml` file. + +```plantuml +@startuml classes +set namespaceSeparator none +class "Sessions" as store.core.session.Sessions #aliceblue { + sessions : dict + add_new_session(username: str, db: Database) -> None + get_all_sessions() -> dict + get_session(username: str) -> UserSession + remove_session(username: str) -> None +} +class "UserSession" as store.core.session.UserSession #aliceblue { + cart : dict + date : datetime, NoneType + db + total_cost : int + username : str + add_new_item(id: str, name: str, price: int, quantity: int, discount: float, tax_rate: float) -> None + empty_cart() -> dict + is_item_in_cart(id: str) -> bool + remove_item(id: str) -> None + delete_cart(id: str) -> None + submit_cart() -> None + update_item_quantity(id: str, change_to_quantity: int) -> None + update_total_cost() -> None +} +@enduml +``` + +## Task 4: Use Case Diagrams + +- Create a `diagrams` subdirectory from the project root directory, and navigate to it. +- Create a `cases` subdirectory from the `diagrams` subdirectory and navigate to it. +- For each user type (actor) mentioned in your `SRS.md` file, create an appropriately named `.puml` file showcasing the use cases for that actor. + - For example, if I had an actor called `Customer`, I might create a file called `customer.puml` that looks like the template below. + - [PlantUML use case diagram documentation](https://plantuml.com/use-case-diagram) +- Generate a `.png` file from the `.puml` file. + - Remember, this will look something like: `python3.10 -m plantuml customer.puml` + +```plantuml +@startuml customer +left to right direction +actor Customer +rectangle "System" as system { + (Login) + (Register) + (View Cart) + (View Items) + (View Orders) + (View Profile) + (Logout) +} +Customer --> (Login) +Customer --> (Register) +Customer --> (View Cart) +Customer --> (View Items) +Customer --> (View Orders) +Customer --> (View Profile) +Customer --> (Logout) +@enduml +``` + +## Task 5: Sequence Diagrams + +- Create a `sequences` subdirectory from the `diagrams` subdirectory and navigate to it. +- For each of the use cases shown in your use case diagrams, create an appropriately named `.puml` file showcasing the sequence of events for that use case and generate its corresponding `.png` file. + - For example, if I had a use case called `Login`, I might create a file called `login.puml` that looks like the template below. + - [PlantUML sequence diagram documentation](https://plantuml.com/sequence-diagram) + +```plantuml +@startuml login +actor Customer +boundary "System" as system +control "Sessions" as sessions +control "Authentication" as auth +Customer -> system: Login +activate system +system -> auth: login_pipeline(username, password) +activate auth +auth --> system: True +deactivate auth +system -> sessions: add_new_session(username, db) +activate sessions +sessions --> system: None +deactivate sessions +system -> system: redirect to home page +deactivate system +@enduml +``` + +## Submission Details + +- On Canvas, submit the following: + - the URL to your group's repository diff --git a/group.md b/group.md new file mode 100644 index 00000000..81ea4820 --- /dev/null +++ b/group.md @@ -0,0 +1,21 @@ +# Group Members + +## Nicholas Matherly + +- **Github Username:** nymbee +- **Niner Net ID:** nmatherl + +## Jack Douglass + +- **Github Username:** JackDougl +- **Niner Net ID:** jdougl39 + +## Mansoor Mohamed Ali + +- **Github Username:** mmoham18 +- **Niner Net ID:** mansmohaali + +## Alec Steene + +- **Github Username:** asteene +- **Niner Net ID:** asteene diff --git a/requirements.txt b/requirements.txt index c39f059d..63c9afdb 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1 +1,3 @@ -flask==2.2.2 \ No newline at end of file +flask==2.2.2 +pylint==2.17.1 +plantuml==0.3.0 \ No newline at end of file diff --git a/srs.md b/srs.md new file mode 100644 index 00000000..4466081a --- /dev/null +++ b/srs.md @@ -0,0 +1,123 @@ +# Software Requirements Specification Document + +This serves as a template for each projects' Software Requirements Specification (SRS) document. When filling this out, you will be required to create user stories, use cases, requirements, and a glossary of terms relevant to your project. Each group member must contribute to every section, so it is crucial that your group's GitHub repository shows a commit history that reflects the work of each group member. It is highly recommended that you create separate branches for each member, but since this is one single document, you will need to manually merge the branches together. It is also advisable to have multiple working versions of this document (named separately) so that one person can compile the final SRS document from the multiple working versions. Ultimately, how you go about managing this is up to you, but consistent formatting, clear commit messages, and a thorough commit history with contributions from each group member are required. + +Fill the document out following the guidelines listed in each section. Maintain [proper Markdown syntax](https://www.markdownguide.org/basic-syntax/) and be sure that your group has a `main` branch with this document and the entire [template repository codebase](https://github.com/david-gary/onlineStoreTemplate) either forked or downloaded and copied into your group's repository. If you have arranged to use a different codebase as a template, you do not need to have the original template included, but a `main` branch is still required. + +## Group Members + +* [Alec](mmailto:asteene@uncc.edu) +* [Jack](mmailto:jdougl39@uncc.edu) +* [Nick](mmailto:nmatherl@uncc.edu) +* [Mansoor](mmailto:mmoham18@uncc.edu) + +## Revisions + +When a change is made to the document, a new revision should be created. The revision should be added to the table below with all information filled out. + +| Version | Date | Description | Author | Reviewed By | +| --- | --- | --- | --- | --- | +| 1.0 | 03/22/23 | Initial draft | [David Gary](mailto:dgary9@uncc.edu) | [David Gary](mailto:dgary@uncc.edu) | + +## Table of Contents + +- [Software Requirements Specification Document](#software-requirements-specification-document) + - [Group Members](#group-members) + - [Revisions](#revisions) + - [Table of Contents](#table-of-contents) + - [Introduction](#introduction) + - [Requirements](#requirements) + - [Constraints](#constraints) + - [Use Cases](#use-cases) + - [User Stories](#user-stories) + - [Glossary](#glossary) + +## Introduction + +In this section, you should give a brief overview of what your project will be. Describe the software system you are building and what problems it solves. You should also give a short description of the stakeholders (users of the system) and what their needs are. There is no set formatting requirement, but you should maintain a consistent structure across future sections. Not all members must contribute to this section. + +## Requirements + +Each group member must supply at least three functional requirements for the project. Each requirement should be written in the following format: + +REQ-1: the user should be able to create orders. + description: the user should be able to put multiple food items into an order, the the order gets created when the user is finished adding items + type: functional + priority: 1 + rationale: the user needs to be able to create orders in order for the kitchen to complete them + testing: we could test this by showing the contents of the completed order once the order is completed +REQ-2: the orders should get stored in a database + description: once the orders are completed, they should get stored in a database so they can get acessed lated when needed + type: functional + priority: 1 + rationale: the kitchen should be able to access the orders so they can fulfill them + testing: we could show a list of completed orders whenever a new order is completed +REQ-3: be able to make changes to completed orders + description: once the orders are completed, a user should be able to change the order in case a mistake is made + type: functional + priority: 2 + rationale: in case a customer changes their mind, or a user makes a mistake, the completed orders need to be changable + testing: we could create an order, then change it to see if the corresponding order on the order list is changed. + + +* **ID:** A unique identifier for the requirement. This should be a number that is unique across the entire document (something like REQ-1, REQ-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Description:** A short description of the requirement. This should be a single sentence that describes the requirement. Do not replace the word `Description` with the actual description. Put the description in the space where these instructions are written. Maintain that practice for all future sections. + * **Type:** The type of requirement. Should be either `Functional` or `Non-Functional`. + * **Priority:** The priority of the requirement. This should be a number between 1 and 5, with 1 being the highest priority and 5 being the lowest priority. + * **Rationale:** A short description of why the requirement is important. This should be a single sentence that describes why the requirement is important. + * **Testing:** A short description of how the requirement can be tested. This should be a single sentence that describes how the requirement can be tested. +* **ID:** A unique identifier for the requirement. This should be a number that is unique across the entire document (something like REQ-1, REQ-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Description:** A short description of the requirement. This should be a single sentence that describes the requirement. + * **Type:** The type of requirement. Should be either `Functional` or `Non-Functional`. + * **Priority:** The priority of the requirement. This should be a number between 1 and 5, with 1 being the highest priority and 5 being the lowest priority. + * **Rationale:** A short description of why the requirement is important. This should be a single sentence that describes why the requirement is important. + * **Testing:** A short description of how the requirement can be tested. This should be a single sentence that describes how the requirement can be tested. + +## Constraints + +In this section, you should list any constraints that you have for the project. Each group member must supply at least two constraints. These can be constraints on the project itself, the software system, or the stakeholders. Constraints can be anything that limits the scope of the project. For example, that this project's template code is written using Flask and Python constitutes a constraint on the backend of the project. Constraints can also be things like the required timeline of the project. Be creative. +CONST-1: user should only be able to create orders if they have a server account +CONST-2: only users with proper permissions should be able to view sales and user data + +## Use Cases + +In this section, you should list use cases for the project. Use cases are a thorough description of how the system will be used. Each group member must supply at least two use cases. Each use case should be written in the following format: + +UC-1: create and index orders for completion + description: the user will click on the food that will be added to the order, and then click complete order when the order is completed, it will then go back to the main screen where there is a create order button for each table, and a list of all current orders on the side + actors: servers, who will make the orders, and chefs, who will prepare the orders from the list + preconditions: code needs to have a button for each table, a way to create an order, and a list to the side of the tables with the orders on it. + postconditions: order must be listed on the side of the tables part of the software +UC-2: create sales data for the owner to look at + description: the owner of the store will be able to look at sales data for the day, with a number of each item sold + actors: the owner of the store + preconditions: the number of each item sold during the day will need to be tracked and put into a database + postconditions: the database will be printed onto a page that only the manager can access + +* **ID:** A unique identifier for the use case. This should be a number that is unique across the entire document (something like UC-1, UC-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Description:** A description of the use case that gives the user a high-level overview of how the system is interacted with. + * **Actors:** A list of the actors that are involved in the use case. Only include the actors that are directly involved. Actors are the people or things that interact with the system. For example, when ordering at a fast food restaurant, one might have the following actors: the customer, the cashier, and the cook. But only the customer and the cashier are directly involved in the use case of ordering food. The cook is not directly involved in the use case of ordering food. + * **Preconditions:** A list of the preconditions for the use case. This should be a list of the preconditions for the use case, which are the conditions that must be met before the use case can be executed. Continuing with the restaurant example, the customer must have money in their wallet and the cashier must be logged in to the system before the use case of ordering food can be executed. + * **Postconditions:** A list of the postconditions for the use case. This should be a list of the postconditions for the use case, which are the conditions that must be met after the use case has been executed. Continuing with the restaurant example, the customer must have their food and the cashier must have the customer's money after the use case of ordering food has been executed. + +## User Stories + +In this section, you should list user stories for the project. User stories are a short description of how a user will be interacting with the system. Each group member must supply at least two user stories. Each user story should be written in the following format: + +US-1: + type of user: server + description: the server will click on the table that they are currently serving, and fill out the order that the customer wants, then clicks complete order +US-2: + type of user: manager + description: the manager will log on to his admin account to make changes to orders, he can also access the sales and customer data, he can use this information to pay taxes and see what items are the most popular. + +* **ID:** A unique identifier for the user story. This should be a number that is unique across the entire document (something like US-1, US-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Type of User:** The type of user that the user story is for. This should be a single word that describes the type of user. For example, a user story for a customer might be `Customer` and a user story for an administrator might be `Admin`. + * **Description:** A description of the user story that gives a narrative from that user's perspective. This can be any length, but it must paint the picture of what the user wants to do, how they intend to do it, why they want to, and what they expect to happen. + +## Glossary + +In this section, you should list any terms that are used in the document that may not be immediately obvious to a naive reader. Each group member must supply at least one term. Each term should be written in the following format: + +* **Term:** The term that is being defined. This should be a single word or phrase that is being defined. + * **Definition:** A definition of the term. This should be a short description of the term that is being defined. This should be a single sentence that describes the term.