Skip to content

Class Diagram & Design Decision Rationale

Jump to bottom
jordanbuch13 edited this page Oct 13, 2024 · 1 revision

UML Class Diagram and Design Decision Rationale

UML_Diag_V4

Rationale

Classes & Associations

  1. Decision: Employee and Customer are subclasses of the abstract Person class.
  • Explanation: This avoids repeated common attributes among customers and employees. Also, a user must be either a customer or staff, thus the Person class is abstract.
  1. Decision: Manager is a subclass of Employee.
  • Explanation: Again, this avoids repeated common attributes. Manager inherits all the attributes from the Employee class, where the isManager field can be set to True. This also allows Manager to complete tasks that only they can do (e.g.: game approvals, promotions, etc.)
  1. Decision: Order class

  • Explanation: Each instance of the Order class will contain a unique ID and order Number that can be used to track, view, and manage specific orders from the system and the user respectively.

  • The status field relates to the separate enum class Status. Here, an order can be defined as “PendingPurchase” when a customer has added games to their cart without purchasing yet.

  • Next, once customer has purchased the items in their Order, the status changes to “Delivered” (since delivery issues and tracking are outside the scope of this project).

  • Alternatively, the customer can cancel a pending order in which case, the order status is “Canceled”, and the order can be deleted.

  • Finally, a “Delivered” order can be returned by the customer, thereby changing its status to “Returned”. Customers and Employees can view the purchase histories by filtering for “Delivered” orders.

  1. Decision: Game class

  • Explanation: Each instance of the Game class has a unique ID that can be used to manage it from the backend. Also the game’s title, description, image, price, and stock can be viewed by the user (Person).

  • When an employee adds a game to the GameStoreSystem, the isApproved field is defaulted to False, thereby setting the archivedDate to the current Date, and archiving the game until it has been approved by a manager.

  • Once a manager approves (or if they themselves add a game directly), the isApproved field changes to True. When this happens, the archivedDate field is emptied (set to null), meaning the game is no longer archived and can be viewed by the customer.

  • Additionally, if an Employee needs to remove a game, or if the stock is down to zero, the archivedDate can be changed. This not only acts as a Boolean to track if a game is archived, but also records the archived date for staff records.

  1. Decision: PaymentInfo is a separate class from Customer
  • Explanation: Although the fields in PaymentInfo could have been included in the Customer class, having them as separate classes with a 1-to-many association allows a customer’s payment information NOT to be stored in the system if they so choose.
  1. Decision: Wishlist class
  • Explanation: Wishlist is a separate class from Order because there is no imminent purchase implied in a wish list. Indeed, a Wishlist simply allows customers to save games they are interested in.

Multiplicities Composition Associations:

  1. Review and Game
  • a. A review cannot exist without a game.
  • b. If a game is removed (archived) from the system, it is logical that all the reviews about this game are also removed.
  • c. A game can have multiple or zero reviews.

NOTE: A case could be made that Review should have a Composition association with Customer as well (i.e. A review cannot exist without a customer). Although this is true logically, it is illegal to have Review depend on 2 classes in a part-whole relationship (Customer and Game) without and {xor} branch between associations. Additionally, if a customer is removed from the system, it is still beneficial to keep their reviews about a game.

  1. Promotion and Game
  • a. Promotions apply to games and cannot exist without a game.
  • b. If a game is removed, the promotions on this game should also be removed.
  • c. A game can have zero or one promotion. If multiple promotions exist, only the highest one should apply to the game (i.e. promotions do not add up).

Unidirectional Associations:

  1. Wishlist and Game
  • A wish list requires access to information available in the Game class, while the opposite is not true: a game does not need to know if it is included in a wish list, much less the details of a specific wish list.
  1. Employee and Category
  • A category does not need to know the information of the Employee creating it.

UC Diagrams & Specifications

Login System UC Diagram

UC1

Return System UC Diagram

UC2

UC1 Specification : Create Account

Author: Jason

ID: UC1

Title: Create account

Description: A user creates an account for the game store system.

Actor: A user who does not have an account.

Pre-condition: A user clicking and create account button and does not have an account.

Post-condition: The system redirects user to the login page.

Main scenario:

  1. The user indicates that they want to create a customer account.
  2. The system displays the new user registration page with a form.
  3. The user enters their email, username, password, re-enter password (twice to avoid typos), and address.
  4. The system confirms that their account was created successfully.

Alternative scenarios:

  • 4a) The user enters an empty email, username, password, or address
    • 4a.1) The system informs the user that the email, username, password, and address they enter cannot be empty.
    • 4a.2) The system highlights the empty fields.
    • 4a.3) The use case continues at step 3.
  • 4b) The password that the user enters does not have at least 8 characters
    • 4b.1) The system informs the user that the password has to be at least 8 characters long
    • 4b.2) The system erases the password and re-enters password field
    • 4b.3) The use case continues at step 3
  • 4c) The two passwords that the user enters does not match
    • 4c.1) The system informs the user that the passwords they entered do not match
    • 4c.2) The system erases the password and re-enters password field
    • 4c.3) The use case continues at step 3
  • 4d) The email address already matches with an existing user in the database
    • 4d.1) The system informs the user that the email they entered is already linked to an existing account so try logging in.
    • 4d.2) The system redirects the user to the login page.

UC2 Specification : User Login

Author: Jacob

ID: UC2

Title: User Login

Description: The user signs into their existing account for the game store system.

Actor: A user who has already created an account.

Pre-condition: A user on the login window.

Post-condition: Returns to the page they were previously on where they can now access their account information by clicking a tab.

Main scenario:

  1. The user clicks on the login button available on any page.
  2. A new login window pops up containing a username and password field.
  3. The user enters their username and password.
  4. The user returns to the page that they were previously on where they can now complete actions that require logging in.

Alternative scenarios:

  • 1a) The user attempts an action that requires logging in (viewing account information, purchasing/returning a game, adding a review, etc.)
    • 1a.1) The login window pops up.
    • 1a.2) The user enters their username and password.
    • 1a.3) The user returns to the page that they were on when the login window popped up.
  • 3a) The user enters an incorrect or non-existent username or password, and the page displays a warning.

UC3 Specification: Add/delete game (to store)

Author: Jordan

ID: UC3

Title: Adding/Removing a game

Description: The manager adds and/or removes a game from the game store system.

Actor: A user with manager privileges

Pre-condition: User with manager privileges is on the Manage Games page

Post-condition: The game is added/remove with a confirmation message displaying the action

Main scenario :

  1. The user navigates to the Manage Games page
  2. The user clicks the Add Game button
  3. A new form appears where the user enters game details, such as title, description, price and category
  4. The user clicks the Submit button
  5. The game is successfully added to the system and a confirmation message is displayed

Alternative scenarios:

  • 2a) The user removes a game

    • 2a.1) The user selects a game from the list of games
    • 2a.2) The user clicks the remove button next to the selected game
    • 2a.3) A confirmation prompt appears, asking the user to confirm the removal
    • 2a.4) The user confirms the removal
    • 2a.5) The game is now archived, and a confirmation message is displayed

  • 3a) The user enters an empty title, description, price and/or category

    • 3a.1) The system informs the user that the title, description, price and/or category they enter cannot be empty.
    • 3a.2) The system highlights the empty fields.
    • 3a.3) The use case continues at step 3.

UC4 Specification: Review Purchased Game

Author: Yvehenry

ID: UC4

Title: Reviewing a Purchased Game

Description: A customer gives a review on a game he previously purchased.

Actor: A user who has a customer account and who has purchased games on the system

Pre-condition: The user is logged into his customer account and is on their “Purchase History” page

Post-condition: A review is added to a game, and the review can be seen by other users

Main scenario:

  1. The user navigates to the purchased game they want to review
  2. The user clicks on the “Review Game” button
  3. The system redirects the user to a form where a star rating from 1 to 5 and a description can be inputted.
  4. The user gives a rating from 1 to 5.
  5. The user writes a description for the rating.
  6. The user clicks the “Submit Review” button.
  7. The review is successfully added to the system and a confirmation message is displayed

Alternative scenarios:

  • 7a) The user does not provide a star rating from 1 to 5
    • 7a.1) The system informs that a star rating from 1 to 5 is required
    • 7a.2) The use case continues at step 4.
  • 7b) The user does not give a description to his rating
    • 7b.1) The system informs that a review description is required
    • 7b.2) The use case continues at step 5.

UC5 Specification: Add game to cart

Author : Ben

ID: UC5

Title: Add game to cart

Description: The customer adds a game to the virtual shopping cart

Actor: A customer

Pre-condition: Customer is on the browsing/shopping page with the available-to-purchase games displayed

Post-condition: The game is added to the cart which can be seen when the user enters the “go to cart” page

Main scenario :

  1. The user navigates to the browsing/shopping page
  2. The user clicks the title/icon of the game they are interested in
  3. The Game Information page is displayed, with accessible buttons such as add to cart and add to wishlist
  4. The user clicks the add to cart button
  5. The game is added to the user’s cart, which is verifiable in the cart page
  6. The button changes to say “added to cart” and a new field is displayed to allow the user to increase the number of copies of the game that they would like to add to cart

Alternative scenarios:

  • 4a) The game is already added to cart and the user attempts to press the add to cart button
    • 4a.1) The user is prompted to confirm if he would like to add a second copy of the game to cart
    • 4a.2) The user can select yes, which would add the copy to the cart, or no which would simply remove the prompt from the page

UC6 Specification: Return purchased game

Author: Ben

ID: UC6

Title: Return Purchased Game

Description: The customer returns a game online with the anticipation of shipping it back to the store warehouse

Actor: A customer

Pre-condition: Customer is on the purchase history page with the display of games he has purchased

Post-condition: The game is virtually returned with a confirmation for pick up date

Main scenario :

  1. The user selects the game he would like to return
  2. The user selects the button “return game”
  3. The user is asked to provide a reason for his desire to return the game and to select a method of refund as well as a refund address
  4. The user is given a date for the pick-up of his game and asked to confirm if all provided information is correct
  5. After confirmation, the user is given the opportunity to leave an optional review of the game
  6. The user is returned to the purchase history page and the game is grayed out to indicate it’s return

Alternative scenarios:

  • 3.a) The user does not provide a reason of return, credit card or pick-up address and is prompted to give all appropriate information before executing any further commands
  • 4.a) The user does not confirm that the information is correct, and can execute step 3 again
  • 5.a) The user refuses to leave a review, and is redirected back to the purchase history page regardless

UML Class Diagram and Design Decision Rationale

UML_Diag_V4

Rationale

Classes & Associations

  1. Decision: Employee and Customer are subclasses of the abstract Person class.
  • Explanation: This avoids repeated common attributes among customers and employees. Also, a user must be either a customer or staff, thus the Person class is abstract.
  1. Decision: Manager is a subclass of Employee.
  • Explanation: Again, this avoids repeated common attributes. Manager inherits all the attributes from the Employee class, where the isManager field can be set to True. This also allows Manager to complete tasks that only they can do (e.g.: game approvals, promotions, etc.)
  1. Decision: Order class

  • Explanation: Each instance of the Order class will contain a unique ID and order Number that can be used to track, view, and manage specific orders from the system and the user respectively.

  • The status field relates to the separate enum class Status. Here, an order can be defined as “PendingPurchase” when a customer has added games to their cart without purchasing yet.

  • Next, once customer has purchased the items in their Order, the status changes to “Delivered” (since delivery issues and tracking are outside the scope of this project).

  • Alternatively, the customer can cancel a pending order in which case, the order status is “Canceled”, and the order can be deleted.

  • Finally, a “Delivered” order can be returned by the customer, thereby changing its status to “Returned”. Customers and Employees can view the purchase histories by filtering for “Delivered” orders.

  1. Decision: Game class

  • Explanation: Each instance of the Game class has a unique ID that can be used to manage it from the backend. Also the game’s title, description, image, price, and stock can be viewed by the user (Person).

  • When an employee adds a game to the GameStoreSystem, the isApproved field is defaulted to False, thereby setting the archivedDate to the current Date, and archiving the game until it has been approved by a manager.

  • Once a manager approves (or if they themselves add a game directly), the isApproved field changes to True. When this happens, the archivedDate field is emptied (set to null), meaning the game is no longer archived and can be viewed by the customer.

  • Additionally, if an Employee needs to remove a game, or if the stock is down to zero, the archivedDate can be changed. This not only acts as a Boolean to track if a game is archived, but also records the archived date for staff records.

  1. Decision: PaymentInfo is a separate class from Customer
  • Explanation: Although the fields in PaymentInfo could have been included in the Customer class, having them as separate classes with a 1-to-many association allows a customer’s payment information NOT to be stored in the system if they so choose.
  1. Decision: Wishlist class
  • Explanation: Wishlist is a separate class from Order because there is no imminent purchase implied in a wish list. Indeed, a Wishlist simply allows customers to save games they are interested in.

Multiplicities Composition Associations:

  1. Review and Game
  • a. A review cannot exist without a game.
  • b. If a game is removed (archived) from the system, it is logical that all the reviews about this game are also removed.
  • c. A game can have multiple or zero reviews.

NOTE: A case could be made that Review should have a Composition association with Customer as well (i.e. A review cannot exist without a customer). Although this is true logically, it is illegal to have Review depend on 2 classes in a part-whole relationship (Customer and Game) without and {xor} branch between associations. Additionally, if a customer is removed from the system, it is still beneficial to keep their reviews about a game.

  1. Promotion and Game
  • a. Promotions apply to games and cannot exist without a game.
  • b. If a game is removed, the promotions on this game should also be removed.
  • c. A game can have zero or one promotion. If multiple promotions exist, only the highest one should apply to the game (i.e. promotions do not add up).

Unidirectional Associations:

  1. Wishlist and Game
  • A wish list requires access to information available in the Game class, while the opposite is not true: a game does not need to know if it is included in a wish list, much less the details of a specific wish list.
  1. Employee and Category
  • A category does not need to know the information of the Employee creating it.
Clone this wiki locally