CSC/ECE 517 Fall 2024 - E2470. Reimplement grades controller

E2470. Reimplement grades controller

This page provides a description of the Expertiza based OSS project.

About Expertiza

Expertiza is an open source project utilizing the Ruby on Rails framework. It is meant to serve as an environment for classes to host assignments, teams, and evaluations of submissions. It is designed to provide instructors the ability to create and modify assignments. Instructors have access to viewing all completed assignments and grades given as well. Additionally, it allows the instructor to provide topic lists that students can access to determine which projects they sign up for. Students are able to form teams for projects and assignments, and during each they can review both peers and other submissions from teams. Expertiza is designed to support submission types ranging from URLs to varying documents.

Introduction

The purpose of this project is to refactor grade_controller.rb, which is responsible for all grading functionality within Expertiza. Its main purpose is to enable instructors to view all grades for an assignment, and allow students to view their own grades. Our main focus is to streamline functionality, remove redundancies, and provide more clarity to this refactored class.

Previous Iterations

• Spring 2024
  • This iteration was not approved to be pulled into expertiza, but provided our team with additional insight on how to more appropriately refactor the grades controller.
• Spring 2021
  • Added additional methodology for providing model data, along with a greater focus on helper classes.
• Fall 2017
  • Refactored penalties, review systems, and utilized rspec testing.

Problem Statement

The following tasks have been completed in this assignment:

• Controller Refactoring:
  • Reimplement the existing grades_controller.rb to make it more modular, reusable, and compliant with the DRY (Don’t Repeat Yourself) principle.
  • Improve the readability and maintainability of the codebase, ensuring it is easily understandable for future developers.
  • Refactor code to eliminate unnecessary repetition and reduce complexity by adhering to SOLID design principles.
• CRUD Operations:
  • Ensure that the required CRUD operations (Read, Update) are properly implemented and optimized.
  • Update methods to reflect best practices and consistent error handling mechanisms.

Previous Implementation

• One of the first major concerns we noticed was the reliance on an excessive amount of helper classes. Helper classes were being defined and provided to the grades_controller, but no other class actually used them. It could be more consistent to keep that functionality stored within helper methods local to the class.
• Functions such as view/view_my_scores/view_team would contain calculations and functionality beyond the purpose of the method, which should be delegated to private methods to preserve modularity.
• The class contained obsolete variables in multiple methods which could be cleaned up.
• Chart methodology is contained within the backend which can now be delegated to the front end, since the controller should only be responsible for grading functionality and returning appropriate data. Model data should be provided to the front end.
• Penalty calculations are currently no longer relevant for the grading controller.
• There are currently no render statements for appropriately providing data to the front end.

Our Implementation

Our Goals

• Simplify the code structure in order to enhance readability by taking complex operations and unneeded local variable assignments into private helper methods within the grades_controller.
• Enforce the intended functionality of the grades_controller by removing unneeded functionality and clutter, some of which is the responsibility of other controllers (i.e. calculating scores and penalties) or the frontend (i.e. rendering the bar chart information). The functionalities of the grades_controller are as follows:
  • Verify the user to ensure they are permitted to view the particular page they are looking for with the action_allowed controller method
  • Provide needed information for the grade heatmap from the instructor's POV, with no hidden information such as reviewers id’s or names
  • Provide needed information for the grade heatmap from the student's POV which obscures information such as the reviewer name/id
  • Update the student's grade and make comments on it from the instructor's POV
• Cut down on repeated code to adhere to the DRY principle in order to improve maintainability and consistency within the code.
• Update the return values of the grades_controller methods in order to provide needed information and HTTP response codes that consistently reflect state and errors, as well as provide the required information for frontend tasks such as making the heatmap itself.

Routes and Methods

• GET /api/v1/grades/action_allowed – action_allowed
  • Checks if the current user is allowed to view scores or team information based on the queried action. Through helpers it focuses on checking if a student is viewing their own team’s scores, or if it’s an instructor trying to access grades. It renders a JSON response with status codes based on resulting output.
• GET /api/v1/grades/view/:id – view
  • Prepares and provides data required for rendering a heat map for an instructor’s point of view. The helper method gathers all the relevant data before providing it in a JSON response with the scores, assignment details, average scores, and review score count.
• GET /api/v1/grades/view_team/:id – view_team
  • Serves a similar function as the view statement, but focusing purely on the student’s perspective of their team. It provides data for rendering a heat map, but hides any sensitive information pertaining to grading, while also acquiring questions from the assignment. It renders a JSON response containing scores, assignment details, average scores, review score count, and questions.
• GET /api/v1/grades/edit/:id – edit
  • Represents functionality for editing grade information, setting the scores for every question after listing the questions out. Renders a JSON response with details about the participant, questions, scores, and assignment.
• GET /api/v1/grades/instructor_review/:id – instructor_review
  • Provides the instructor with a rendered JSON response on whether there’s a new record or preexisting instance of a review.
• PATCH /api/v1/grades/update/:participant_id – update
  • Updates the total score and comments for a team submission based on the received data. It finds the specified assignment, modifies the grade, and makes an attempt to save those changes. Upon failure it will provide an error message.

Change	Rationale	Relevant commit(s)
Refactored `action_allowed?` into `action_allowed`, and added new helper methods	The `grades#action_allowed?` method was not being called anywhere in the backend, which means this functionality is only presently used by the frontend. As such, `action_allowed?` needed to become a Rails API method and endpoint, meaning that it no longer returned a boolean (which is why it was renamed). Now it is a GET request to the appropriate route.	Commit Link
Added `participant_scores` model	Added a participant scores model to belong to an assignment, `assignment_participant` and `question`. A participant score also holds a `score`, `total_score` and `round`.	Commit Link
Changed return types of all controller methods to render JSON Strings	As Rails API methods the easiest and expected way to communicate with the new frontend is by rendering appropriate JSON response strings with HTTP status codes appended, this can allow the frontend to parse and handle returned data.	Commit Link 1 Commit Link 2
Created test files and factories to test our grades controller reimplementation.	We needed to test the API endpoints for the grades controller. The factories helped in assisting the testing.	Commit Link 1 Commit Link 2 Commit Link 3 Commit Link 4 Commit Link 5 Commit Link 6
Refactored all the main API endpoint methods, added new helper methods, and removed redundant methods	Many of the methods were redundant and unused in the front end (all the chart methods). We removed all of those methods and reimplemented the logic for the view methods, as previously they did grade calculation within the grades_controller, something that does not follow the best programming practices. Instead, we have the calculated elsewhere and just have grades_controller displaying all the heat map information on the front end	Commit Link 1 Commit Link 2 Commit Link 3 Commit Link 4 Commit Link 5 Commit Link 6
Overhauled method comment documentation replaced with correct comments that describe what the method does, and did a quick style pass to ensure code readability	A lot of the comments within the grades_controller were not very good, some of which were outright incorrect or at the very least we're not correct to the current implementation of the controller at the time that we started it. So updating all of the documentation to be accurate and reflect the current state of the controller after our changes was a necessity, trying to aim for a high understanding of what each method does without even needing to read the code for future work on the codebase. Additionally, code readability was an issue in the old controller, primarily due to long or dense lines, we made an effort to limit these issues and promote clean, readable, and maintainable code.	Commit Link 1 Commit Link 2 Commit Link 3 Commit Link 4 Commit Link 5 Commit Link 6 Commit Link 7 Commit Link 8 Commit Link 9 Commit Link 10

Team

Mentor

• Srusti, Chaitanya

Members

• Eastin, Charlie
• Hulse, Jeremy
• Middleton, Maverick