Skip to content

Domain Model

Jump to bottom
raniaouassif edited this page Mar 19, 2021 · 5 revisions

Important Decisions :

  1. Generalization of Technician, Customer, and Administrative Assistant into User class :

We wanted to avoid the repetition of fields in our domain model. Since all of the possible users need to have a first name, last name, phone number, and id, we created an abstract User class. However, later on, in order to reduce the number of classes we have, we decided to use Account class instead of user. Nonetheless, we decided it is better for us to use the abstract User class.

  1. No owner class :

At first multiple drafts of our domain model had an owner class in it. It was a subclass of users as technicians, Customer, and Administrative Assistants. We ended up deciding not to have an owner class since it has no functionality.

  1. TimeSlot class :

We created a separate class for time slots because if the time slot is an attribute in the Appointment class it would be more difficult to do later in the coding.

  1. Service type enumeration :

On the first draft of our domain model, we created an enumeration class for the service types. However, later on we decided to keep the serviceType as a string so that if later on, the shop decides to add on more service types.

  1. Composition between User and Account:

We made a composition association between the User class and Account class because each account belongs to a specific user. If we delete one user from the system, the account related to that user a

Domain Model Version 2

Important Decisions for domain model version 2:

  1. We decided to change the association between the Appointment class and the Customer class. Instead of using a one-way association from Customer class to Appointment, we decided to make it a two-way association. (Same has done on the association between Technician and Appointment)

  2. The main important decision for our second model is getting rid of the Account class we had before. During our implementation, we realized it was unnecessary.

  3. We decided to remove Account class in order to eliminate the redundancy.

  4. Re-organized the associations between timeslot, services and appointments to get rid of primary key constraints

  5. Removed an association between administrator and appointment in order to remove an error caused by POSTGRESQL

Clone this wiki locally