Domain Model
The initial class diagram constructed over the course of the Sprint 1
(view fullscreen)
For convenience we have also uploaded a zipped folder trial.zip containing the trial.umlcd file and the generated classes.
(trial.zip)
The second iteration of the class diagram constructed at the beginning of Sprint 2 to address some of the domain-related issues encountered during Sprint 1, namely the over-complexity, and the fact that Models with Many-to-many associations to multiple classes needed some way to be handled (setting the other M-t-m to null, or having the multiplicity as 0..* and logic to ensure to ensure only one of the M-t-m relations was satisfied for any given object)
(view fullscreen)
One of the key design decisions was to divide the Room and Session classes into Individual and Group sub-classes to enable the feature of scheduling group sessions in group rooms. We could have opted to simply set a boolean flag in each class say is_group to indicate if the session was held in a group or the room has group capacity, but we decided that this would be inefficient as it would require an extra field for each database entry for Room and Session, and it would make listing group rooms more inefficient as the system would require logic to iterate through all Room instances and check for each instance if the is_group was true and then return it based on this comparison. We instead opted to use the Individual and Group sub-classes for both Session and Room as in this example fetching all group rooms would simply require fetching all GroupRoom instances.
Another key design decision was having a TimeBlock class to represent availabilites and reservations in 30 minute increments for Tutors and Room. For example, a Tutor available for tutoring only on one arbitrary day from 8:30am to 10:00am would have 3 TimeBlock instances, one starting at 8:30 am (start_time = 8.5), another starting at 9:00am and the last one starting at 9:30am. This was done as it satisfied the constraint that Tutor and Room availability had to only be granular enough to modify at the hour or the half-hour, and it also allowed to easily add and remove availability for a tutor by adding removing one or more TimeBlock instances, or book a room by giving the Room a reservation time block. It also makes it more efficient to check for overlapping availability by simply comparing the availability and/or reservation of any Class to see if they have the same day, date, and start_time.
Finally, we decided to have a Subject and Course class associated with each Product (with each other due to their logical hierarchy). This made the Persistence Layer more efficient as it would not store potentially duplicate course and subject strings for each Product, but instead Products have a foreign key of a Course entry (which itself has a foreign key to a Subject entry). As such, different Products can both use the same Course entry in the database, which avoids redundancy, and a Product only needs to create a new Course entry if that Course does not yet exist, instead of having to save a course field for each Product entry regardless of whether it already existed.
The domain model project folder can be found here: