Skip to content

Domain Model

Talha edited this page Oct 14, 2019 · 21 revisions

Domain Model

Key Decisions:

  1. We make review an abstract class. When we are making the draft of the domain model, the tutor review and student review were two separate classes. We just simply connected tutor review to Tutor and student review to Student. But if the domain model were like that, the domain model will be too complicated. So we change the model. We create a new abstract class called Review and connected it to the User class because every user should have reviews. But different from student review, the tutor reviews should also have a rating. So, the Review class has one attribute called review and the tutor review class has one attribute called rating. The student review class doesn't have any attributes.

  2. We make Availability a separate class. If the availability is an attribute in the Room and Tutor class, it will be too difficult to do the later coding. So we create an abstract class called availability. The only attribute in that class is availability, which is an array. There will be at most 12 hours a day and we divide it into 24 slots. Each slot stands for half an hour. There will be 120 elements in the array and each element is a Boolean. If the boolean is 1, it means that the room or the tutor is available in that half an hour.

  3. There is a composition between the Course and University class. Because the courses are part of the university s. If we delete one university from the system, all the related courses should be deleted.

  4. We make every class a component of the model folder because all the generated code should be in that folder. When making the domain model, our main focus resided on keeping it to the student's viewpoint and have it on par with how the spring project was set up. The generated code should always be in the ca.mcgill.ecse321.tutoringsystem.model package and our diagram can reflect that despite looking slightly messy. We also added the class TutoringSystem where every class would be linked with the composition relation. This is to ensure that everything can be monitored via the TutoringSystem instance.