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〉 Currently, the functionality relevant to waitlisting is scattered across the multiple files. These functions need to be consolidated and placed in a single class.

Control Flow

In the current implementation, multiple models and controllers perform actions that indirectly affect the teams in the waitlist and require to be added or removed from the waitlist. Due to this the same redundant operations of modifying the waitlist is being performed by multiple models and controllers. In order to improve the functionality all the redundant operations being performed on the waitlist need to be moved to the 'waitlist.rb' file and all the other controllers and models will be utilising these methods to manipulate the waitlists.

Existing Control Flow

Modified Control Flow

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 is Strategy Design Pattern. It is a behavioural 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. lottery_controller.rb
5. suggestion_controller.rb
6. signed_up_team.rb
7. student_teams_controller.rb

Test Plan

This project entails code refactoring such that all functionality relevant to waitlist 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. However, new unit tests will be written for testing waitlist.rb independently. Furthermore, test cases for suggestion_controller.rb & signed_up_team.rb are missing in the current implementation. Hence, we will be adding spec files for the aforementioned files as well. Certain edge cases will also be tested which have not been covered by the current tests.

Test Files

1. sign_up_topic_spec.rb
2. invitation_spec.rb
3. waitlist_spec.rb
4. lottery_controller_spec.rb
5. suggestion_controller_spec.rb
6. signed_up_team_spec.rb
7. student_teams_controller_spec.rb

Cases To Be Covered

1. Add team to waitlist if topic isn't available.
2. Push the first waitlisted member (if exists) in case a confirmed slot is deleted.
3. Remove waitlists for team if a topic is confirmed.
4. Clean waitlists & assign topic if the user has a team but not a topic.
5. Remove old team from waitlists.

References

1. Problem Statement
2. Forked Repository

Team

• Ankit Singh (asingh072318)

• Asrita Kuchibhotla (kAsrita)

• Neha Kotcherlakota (nehajaideep)

• Vinit Desai (VinitDesai1998)