CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

About Expertiza

The Expertiza platform employs a divide-and-conquer strategy for creating reusable learning objects via active-learning exercises built entirely on Ruby on Rails framework. Students get to choose from a list of tasks to complete either individually or in teams. It also allows the instructor to create a list of topics the students can sign up for. They then prepare their work and submit it to a peer-review mechanism. On submission, other students can assess their peers work and provide feedback. Expertiza encourages students to collaborate in order to improve the learning experiences from one another. It aids their learning by making them translate what is taught in the lectures and apply those concepts to a real-world issue.

Problem Statement

When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When another team drops a topic, then a waitlisted team will be assigned the topic, if there are any teams waitlisted for it. Implement a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

Solution Approach

Refactoring

Goal of the project is to simplify waitlist functionality by moving all the functions manipulating waitlists to waitlist.rb, along with a WaitingTeam class that would consist of a 〈team_id, topic_id〉pair to store information regarding teams on waitlist for a particular topic. Classes should just invoke methods of waitlist.rb for the following functionality:

1. Add themselves to waitlists
2. Add another team to a waitlist
3. Take a team off a waitlist
4. Purge all waitlists of a specific team
5. Clear a specific waitlist of all waiting teams

Introduce a waitlist object associated with each topic so that any team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

Design Pattern

As we are decoupling the functionality manipulating waitlists that is scattered across various files and putting it all under a single class the design pattern opted for Strategy Design Pattern. is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.

Tentative list of files to be modified

1. sign_up_topic.rb
2. invitation.rb
3. waitlist.rb
4. suggestion_controller.rb
5. signed_up_team.rb
6. student_teams_controller.rb

Test Plan

This project entails code refactoring such that all functionality relevant to wailtist is easily available under one class. Focus is on ensuring existing tests work as expected as the newly added code will not impact functionality per se.

References

1. Problem Statement
2. Forked Repository

Team

• Ankit Singh (asingh072318)

• Asrita Kuchibhotla (kAsrita)

• Neha Kotcherlakota (nehajaideep)

• Vinit Desai (VinitDesai1998)