CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

Team

Mentor

• Anish Toorpu

Members

• Dennis Christman <dchrist2@ncsu.edu>
• Eleanor Maye <edmaye@ncsu.edu>
• Ryan Gallagher <rtgalla2@ncsu.edu>

Problem Statement

The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

• ResponseMap
  • SurveyResponseMap
    • AssignmentSurveyResponseMap
    • CourseSurveyResponseMap
    • GlobalSurveyResponseMap
  • ReviewResponseMap
    • BookmarkRatingResponseMap
  • FeedbackResponseMap
  • MetareviewResponseMap
  • QuizResponseMap
  • SelfReviewResponseMap
  • TeammateReviewResponseMap

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

Design Goal

We have several goals for this project:

• Utilize the existing hierarchy and ensure proper inheritance between models.
• Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
• Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
• Develop extensive test coverage for each new model.
• Document each new model with clear comments on its use and methods.

Implementation

Implementation Plan

Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:

belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'

which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the email method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.