Design Decisions - McGill-ECSE321-Winter2022/project-group-group-08 GitHub Wiki

We decided to use a player-role pattern for employees, managers and customers. We made each player a user in the first version of our domain model but then changed the class name from user to person because "user" is a reserved word. Class Person contains variables including firstName, lastName, phoneNumber, email, and address. We also had an abstract class called worker under another abstract class called user role. We decided to remove the abstract class worker because having an abstract class within another makes it hard on the database to keep track of and write the JPA tags and relationship. UserRole class contains only the ID instance since all its subclasses have instance ID. Customer class contain tier class and ban status.

Nonetheless, one person could play one or no role, so the multiplication between person and user role is one to 0…1. Each person has one account so the multiplication between account and person is 1 to 1. Each employee is associated with many business-hour classes indicating which weekday they work and finish. Instead of 1 to 7 for a business hour, it is 1 to many because JPA tags have four common tags (1 to 1, 1 to many, many to many, and many to 1). We also have a class called grocery store system indicating the store’s name, address, and employees’ discount. It is assigned with many business hours and many items. Each person has an account consisting of their username, password, total points and in-town status. Each cart contains the date ID and is assigned with an account. We initially had a class called order, but we changed it to receipt since "order" is a reserved word. Nonetheless, many receipts could be inside one cart. Thus, the multiplication between Cart and Receipt is 1 to many. Within the receipt class, there are the status, type, and the number of the receipt. The item class consists of item ID, item name, item price, item's points, return date, and in store quantity. It also indicates if a customer could pick up the item or have it delivered. We assigned each item to one quantity class, indicating the number of items. Having a quantity class handles the conflict between customer shopping online. If a customer is browsing a specific item online, then the available quantity of the item is subtracted by 1.

We have multiple enum classes because they improve type safety to avoid the run-time error. Our first enum class is ReceiptStatus, including processing, transiting, and fulfilled status. The second enum class is called tier class which indicates the customer’s tier class. The three tier classes are gold, silver, and bronze. Another enum class is WeekDay including Monday, Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday. This enum class is helpful for scheduling employees’ shifts. The final enum class is called ReceiptType and it contains type delivery and pickup.

Each class's first attribute is the primary key (except for the manager, employee and customer. Their primary key is the User role's ID). Realistically, each customer is assigned one cart that contains items to be purchased. While browsing, customers can add or remove items in the cart. The cart is emptied and ready for the following Order by the end of an order. Therefore, we decided to make the multiplication between the cart class and account class to be one.