Skip to content

Architecture

Jump to bottom
Cedric Wang edited this page Dec 5, 2023 · 18 revisions

The data structure diagram provided illustrates the interactions between different entities in the system designed to manage course schedules, wishlists, and calendars for users by accessing the University of Waterloo's OpenAPI. Here's an explanation of the key elements and their interactions:

  1. User Interaction with UW OpenAPI: The core of this system is the interaction between the user and the University of Waterloo's OpenAPI. The user can request course schedules and information about courses offered through the API. This interaction is central to all other functionalities of the system.

  2. Calendar and Course Management: Once the user retrieves course information from the OpenAPI, they can utilize this data in various ways:

    • Calendar: The user can add courses to their calendar, creating a personalized schedule of the courses they are taking or interested in.
    • Custom Calendar: For more tailored needs, the user can create a custom calendar. This involves first accessing the OpenAPI for course information, then processing this data according to the user's specific requirements, and finally adding it to a custom calendar.
    • Wishlist: Users can also add courses to a Wishlist. This is achieved by first requesting course data from the OpenAPI and then storing the desired courses in the Wishlist for future reference or enrollment.
    • Optimized Schedule: Users can send selected courses to this module, which then processes these courses to return an optimized schedule and thereby providing a more efficient and personalized academic schedule.

  3. Social Features - Friends and Shared Calendars:

    • Friend Requests and Shared Schedules: The system allows users to connect with friends. A user can send a friend request to another user. Once accepted, they can view each other's schedules. This feature enhances the collaborative aspect of the system, allowing students to coordinate or plan their schedules together.
    • Visibility of Friend's Calendar: After a friend request is accepted, a user can access their friend's calendar data, providing an opportunity for shared planning.

  4. Course-Related Data Entities: The diagram includes entities like 'User Course', 'User Custom Calendar', and 'Current Calendar Courses'. These represent different categories of course data processed and stored in the system. For instance, 'User Course' may represent the courses a user is currently enrolled in or interested in, while 'User Custom Calendar' could represent a user's uniquely created calendar based on specific criteria or preferences for future or current enrolment.

Overall, the data structure diagram outlines a comprehensive system for managing academic schedules and courses, integrating the University of Waterloo's OpenAPI for real-time course data, and enabling social interactions through shared calendars and friend functionalities. This system has been designed for ease of use, flexibility, and collaborative planning, tailored specifically for students at the University of Waterloo.

models.drawio.pdf Entity Relationship

Our application needs to save multiple assets to a database in order for users to be able to view them again between sessions. We decided to use a relational database notably PostgreSQL notably due its wide use in the industry and its flexibility. As such, we have defined multiple tables in our database to store the assets we need. The following diagram provides the design of our database which includes all the entities and their relationships.

Users: The Users table represents the users of our application. It contains an ID field which many entities will reference. It also stores the user’s username and password which has been hashed. UserCourses: The UserCourses table represents a user’s current selection of courses. This entity has a foreign key referencing a User through the user_id. As such, there is a one-to-many relationship between Users and UserCourses. A User can have many UserCourses, but all UserCourses reference one specific User. The UserCourse entity has its own ID and also stores information such as course_id, course_title, course_number, start_time, end_time, start_date, end_date, and week_pattern. CustomCalendars: The CustomCalendats table represents a user’s alternate schedules. Other than their current schedule, users can make alternate schedules with different courses. As such, this entity has a foreign key referencing a User through the user_id. There is a one-to-many relationship between Users and CustomCalendars. A user can have many CustomCalendars, but all CustomCalendars reference one specific User. The CustomCalendars has its own ID field and it also stores the name of the calendar. UserCalendarCourses: The UserCalendarCourses table represents the courses added to a CustomCalendar. Once a User makes a CustomCalendar, they can add courses to it. This entity has a foreign key referencing a CustomCalendar through the custom_calendar_id and a foreign key referencing a User through the user_id. As such, there is a one-to-many relationship between Users and UserCalendarCourses and a one-to-many relationship between CustomCalendars and UserCalendarCourses. The UserCalendarCourse entries are heavily linked to the CustomCalendars, so if a CustomCalendar is deleted, all of the associated UserCalendarCourses are also deleted in a cascade effect. The UserCalendarCourse entity has its own ID and also stores information such as course_id, course_title, course_number, start_time, end_time, and week_pattern. Friends: The Friends table represents the different requests for the friends system. Since to have a friends system, we have a many-to-many relationship between Users, we would need an association table which is what the Friends table is for. Thus, the Friends entity has two foreign keys each referencing a User through the user_id and the friend_id. It also has its own ID field and a status field which details the progress of a request. When a User sends a friend request to another user, an Friend entry is inserted and the status is set to “pending”. The other User then receives the request and can accept it or reject it. If rejected, the entry is deleted. If accepted, the status is changed to “accepted” and another entry is added for the opposite relationship. If a User is friends with another User, then the vice-versa is also true. Thus, two entries are needed to signify a friendship. Wishlists: The Wishlists table represents the courses a User wants in their wish list for one of the terms in their studies. The entity has a foreign key referencing a User through the user_id. As such, there is a one-to-many relationship between Users and Wishlists. A User can have many Wishlists, but each Wishlist is only associated with one User. The entity also has its own ID field and stores information such as subject_code, catalog_number, course_title, and term_year.

Clone this wiki locally