CSC/ECE 517 Spring 2025 - E2510. Reimplement grades controller.rb

E2510: Reimplement grades_controller.rb

Introduction

The purpose of this project is to refactor grade_controller.rb in Expertiza, ensuring it adheres to the principles of Single Responsibility (SRP) and Don't Repeat Yourself (DRY). The controller is responsible for managing grading functionality, enabling instructors to view and modify assignment grades while allowing students to access their own evaluations.

Previous Implementation

The previous implementation (E2470) refactored the original Expertiza grades_controller.rb by enhancing modularity, reusability, and maintainability while attempting to adhere to the DRY and SOLID principles. However, it was determined that the controller still contained elements that could have been placed elsewhere in the system, which would have led to DRY and SRP violations if merged.

To address these concerns, further reimplementation of the controller will be needed to properly delegating responsibilities and eliminating redundant functionality. By restructuring the code and improving its organization, we can ensure a more maintainable, scalable, and efficient grading system within Expertiza.

Project Statement

This project focuses on refactoring the grades controller to improve modularity, reduce redundancy, and enhance overall maintainability. By adhering to DRY and SOLID principles, the refactor will streamline responsibilities, ensure that functionality is appropriately distributed across the system, and improve code clarity. Key improvements included eliminating unnecessary repetition, optimizing data retrieval, and enhancing method documentation for better readability and usability. Additionally, code structure and organization will be refined to align with best practices, promoting long-term scalability and ease of maintenance.

With these enhancements, the grading system will become more efficient and maintainable, providing a seamless experience for instructors and students while ensuring a cleaner and more structured codebase for future development.

Specific Objectives

1. Refactor the controller to streamline responsibilities, ensuring each function has a distinct and well-defined purpose in alignment with the Single Responsibility Principle.
2. Eliminate redundant privilege-checking methods by integrating existing functionality from the codebase to improve maintainability and consistency.
3. Ensure grade calculations are centralized within response.rb, response_map.rb, and assignment_team.rb to eliminate redundancy and maintain consistency across the system. Other classes should retrieve grades by invoking methods from these dedicated classes rather than redefining functionality.
4. Enhance method documentation by providing clear, concise explanations of their purpose and logic to improve code readability and maintainability.
5. Ensure the controller follows best practices by adhering to DRY and SOLID principles, promoting code maintainability, scalability, and consistency with the overall codebase standards.

Rationale for Changes

Change	Rationale
Refactored `action_allowed` into `action_allowed?`, and added new helper methods to perform appropriate validations	The `grades#action_allowed` method was not adhering to the Open-Closed Principle by incorporating case statements. This previous implementation was not open to extension, but rather modification. The new implementation closed the method off to modification and opened it up to extension. Additionally, we removed the redundant user_ta_privileges? and user_student_privileges? Methods, and replaced them with existing functionality from the codebase.
Refactored `view` into `view_grading_report`	The refactored version expands the older version by providing a more comprehensive grading report that includes all participants, received reviews, final scores (averages), and the greatest difference in scores. Instead of focusing solely on querying data for the heat map in the TA/staff view, the new version integrates these grading insights to enhance instructor visibility. This improves modularity and usability, ensuring that both heat map data and grading reports are efficiently retrieved and presented.
Refactored `view_team` into `view_my_scores` and `view_team`	The refactored version replaces the single-function approach with two distinct methods: `view_my_scores` for individual performance and `view_team` for team performance. This separation improves clarity and modularity by ensuring that each method focuses on retrieving relevant data, applying penalties, and preparing feedback while also maintaining anonymity in reviews.
Moved all functionality for calculating grades into the `response.rb` and `response_map.rb` models.	The `vector` function was initially implemented to handle grade calculations within the controller, but this approach led to redundancy and violated the DRY principle in the original Expertiza code. Since grading functionality already exists in `response.rb` and `response_map.rb`, maintaining calculations in multiple locations increases complexity and the risk of inconsistencies. To ensure a more modular and maintainable system, all grade-related logic was centralized within these classes, allowing other components to retrieve grades through well-defined method calls rather than duplicating logic across the codebase.
Refactored `edit` into `edit_participant_scores`	Assigned a more appropriate title to display the true functionality of the method. Additionally, refactored the grade references to be derived from the `response.rb` model instead of being calculated in the grades controller itself. This allowed the method to adhere to the DRY principles. Minor changes were made to the display features if a participant was not found.
Refactored `update` into `update_participant_grade` and `update_team`	The refactored methods break up the functionality of the old `update` method. Now, there are separate methods to handle the functionality of updating a participant’s grade and updating a team’s grade. This breakout also reincorporated functionality from the original Expertiza code that was left out in the E2470 reimplementation. Now, all functionality is present and the methods follow the SOLID principles.
Refactored `instructor_reivew` with minor updates	The group determined the functionality of the `instructor_reivew` was necessary and needed to be its own method to avoid breaking the SOLID principles guidelines. Minor changes were made to the method in an attempt to simplify the code and better adhere to all principles.