Here is our domain model:

Rationale behind key decisions of the domain model:

1. Generalization of Tutor and Student classes into Person class:

   This generalization was used to avoid using many duplicate fields including the first name and last name of a student and a tutor, their email address and their username. We chose not to use the player-role pattern in this generalization because of the implementation decision that a tutor cannot become a student under the same username and email address.

2. Creating a Review class and linking it twice to Person and once to appointment:

   For the Review class, we started with the idea that every person object, either a tutor or a student, should have a list of reviews given and reviews received, as both student and tutors are able to give reviews. This means that we want two associations between Person and Review, determining that a Person has two lists of review, and each review has a single reviewer and a single reviewee. In addition, we want each review to be linked to a single appointment, after which is was created, while an appointment might generate zero reviews minimum up to a maximum of the number of students plus the tutor.

3. Creating an Appointment class linked to Tutor and Student:

   We know that every tutoring session if going to involve a tutor and a minimum of 1 student up to 15 students. This means that each student and each tutor object should have a list of all their appointments, while each appointment should have a tutor object has a field and a list of student has another field to keep track of the participants of the review session.

4. Creating an Availability class linked to Tutor:

   A single availability object will have to contain a specific date and a specific time, which means it should be its own class. In addition, we want each tutor object to have a list of availabilities, while each availability should be linked to its own unique tutor. Any appointments objects should stop existing if their tutor object is deleted, hence we chose to use a composition association to link these two classes.

5. Abstraction/occurence pattern with SpecificCourse and Course:

   One of the main issue with our domain model was to figure out how to illustrate the fact that a tutor might teach many courses, and have different hourly rates for each course. We chose to differentiate between the general case of a course with its ID, its name and its level, and the specific case of a course, which has an hourly rate and which a tutor would actually teach. That allows us to easily access all the courses thought by a single tutor and display the hourly rates connected to that course. It was also decided that one tutor had many specific courses, and each specific course has one general course. While each general course has many specific course and each specific course has one tutor.

Notes:

1. Generalization relation from tutor and student to person. This means one person/account cannot be a student and tutor
2. Each review has an association with 2 person objects. These objects must be of different type. (A student cannot review another student and a tutor cannot review another tutor)