CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb

This wiki page is for information regarding the changes made for the E2415. Reimplementation of responses controller.rb OSS assignment for Spring 2024, CSC/ECE 517.

Introduction

The Expertiza project, an open-source endeavor rooted in Ruby on Rails, embarks on continuous improvement to adapt and integrate modern software engineering practices. The Responses Controller is engineered to assist reviewers in submitting structured data that is specifically aligned with an assignment's rubrics, ensuring the provision of relevant questions for each round within the correct due date period. It enables a reviewer to evaluate and score the rubric questions pertinent to the assignment's topics. Furthermore, it ensures the delivery of appropriate questions for each assignment round, allowing reviewers to create and modify scores and comments for each of the rubric questions associated with the assignment. After reviewers submit their scored questions and comments, the Responses Controller dispatches an email notification to the instructor and the reviewed team's members.

Problem Description

The ResponseController in Expertiza, a legacy system with conventions predating Rails standards, is overly complex, encompassing functionalities beyond basic CRUD operations and needing adherence to modern Rails naming and design principles. Key issues include the direct implementation of functionalities like sorting reviews and checking reviewer roles within the controller, suggesting a shift towards polymorphism and a more structured approach to code organization. Furthermore, the controller's handling of email notifications and feedback mechanisms is inconsistent, indicating the necessity for a dedicated helper to streamline communication processes. The reimplementation effort must focus on simplifying the controller, adhering to Rails conventions, and improving code readability and maintainability by appropriately distributing responsibilities.

Reimplementation Objectives

The project's core objectives were manifold, aiming not only to adhere to contemporary Rails naming conventions but also to streamline and refactor the existing ResponseController for better clarity, functionality, and adherence to best practices. Key focus areas included:

1. Show_response: allow rendering json format for a response including an associated response_map and answers.

2. Create_response: create a new response model with associated answers.

3. Update_response: update an existing response model with associated answers.

4. Delete_response: delete an existing response model with associated answers.

5. Create answer blanks and Sort answers: We introduced a new sorting method “serialize_response” that formats response model structure to resolve the sort answers with question type.

6. Reimplement questionnaire_from_response and questionnaire_from_response_map: We introduced a new method “get_questionnaire” function that takes a response model as a parameter so that it identifies the questionnaire based on questionnaire type, signed up team, current round, version number, and due date. However there is a difficult to test it due to the chained functions throughout the related models, and no sufficient models provided.

Method Reimplemented

The ResponsesController, originally extensive with numerous functions beyond basic CRUD operations, has been streamlined for our API application. In this context, there's no need to manage data variables for view pages, simplifying the handling of request data solely through request methods. To enhance the architecture and efficiency of our application, we've eliminated redundant methods and consolidated functionalities across the model, controller, and helper files. This restructuring was essential for refining the response endpoints specifically tailored for an API application.

Model set_content method

The set_content method has been updated to configure the response model based on the requested response ID, including associating the relevant questions and answers.

Model validate_params method

The validate_params method verifies whether the request data contains the necessary information to create or update the Response model. It assesses if the received data can lead to the creation of a new model or update an existing one, based on the response_id, round, and num_review values provided in the request. Upon evaluation, it responds with a corresponding HTTP status code and message.

Model serialize_response method

The new method "serialize_response" eliminates the need to manage the order of items and offers a structured representation of the model for easier management.

Controller CRUD Actions

The ResponseController, originally extensive with numerous functions beyond basic CRUD operations, has been streamlined for our API application. In this context, there's no need to manage data variables for view pages, simplifying the handling of request data solely through request methods.To enhance the architecture and efficiency of our application, we've eliminated redundant methods and consolidated functionalities across the model, controller, and helper files. This restructuring was essential for refining the response endpoints specifically tailored for an API application. A key area of improvement has been minimizing the reliance on chaining method calls that span across various Active Record models. This practice, while common, posed significant risks to the ResponseController's stability, particularly if a function invoked from another model were to be updated.

Email Notification Refinement

Email-related methods were consolidated into the ResponseHelper, with new constructs like EmailObject and Mailer introduced for better organization.

Questionnaire Determination Simplification

Implementing the "questionnaire_from_response_map" method was a challenge due to its dependency on several models that aren’t in the reimplementation repository. To make the method work, it is necessary to create the following models, "TeamsUser", "SignupTopic", "SignedUpTeam", "DueDate", "TopicDueDate", "AssignmentDueDate", and "AssignmentForm". To manage the associated chain of methods, which are in several models, involves significant effort. To mitigate the complexities associated with cross-model method chaining, we introduced a new method named "get_questionnaire" within the "ResponseHelper" module. However, the extensive dependencies on numerous models posed challenges for successful testing.

Design and Additional Implementation Details

• Controller Renaming: The controller was renamed to responses_controller.rb, aligning with Rails conventions.
• Response Helper: During the reimplementation, the team employed various design patterns and refactoring strategies to achieve a cleaner, more maintainable codebase. We developed a response helper file serving as service logic to facilitate essential functions for processing the "set_content" and "validate_params" methods in the Response model, as well as supporting CRUD actions in the Responses controller.

File(s) Modified

• responses_controller.rb (new)
• response_helper.rb (new)
• response.rb
• 20240305170836_add_column_type_response_maps.rb
• 20240312235330_add_columns_to_participant.rb

Test Plan and Coverage

The project adopted Test-Driven Development (TDD) principles, ensuring that each new feature and refactoring effort was accompanied by comprehensive test cases. This approach not only facilitated the detection of potential issues early in the development cycle but also contributed to a robust and reliable codebase. Test coverage metrics were carefully monitored, with significant improvements observed in both the breadth and depth of the testing suite.

Response model test

• Validate present of map_id
• The map_id is the same as response.response_map.id
• Response_map should be an instance of the ResponseMap class
• Scores should be an array of the Answer classes
• when creating a new response, validates not existing of response_map in database
• when creating a new response, validates creating a new response
• when updating a response, validates updating the response
• when updating a response , validates cannot update the submitted response
• set_content, sets the response content based on provided response id

Response controller test

Documentation for methods that were re-implemented:

• Create
  • HTTP Method: POST
  • Endpoint: api/v1/responses/{map_id}
  • Input: map_id, scores
  • Output: Response code and a message
  • Description: It enables reviewers to save scores and comments for their assignment reviews.

• Update
  • HTTP Method: PUT
  • Endpoint: api/v1/responses/{id}
  • Input: response_id, scores
  • Output: Response code and a message
  • Description: It enables reviewers to update scores and comments for their assignment reviews.

• Delete
  • HTTP Method: DELETE
  • Endpoint: api/v1/reponses/{id}
  • Input: response_id
  • Output: Response code and a message
  • Description: It enables reviewers to delete their review for their assignment reviews.

• Index
  • HTTP Method: GET
  • Endpoint: api/v1/responses
  • Input:
  • Output: Response code and list of responses
  • Description: It enables reviewers to see the list of their reviews.

• Show
  • HTTP Method: GET
  • Endpoint:api/v1/responses/{id}
  • Input: id
  • Output: Present a response with the corresponding code and relevant scores.
  • Description: It displays the details of a response.

Relevant Links

• EXPERTIZA API V1 Swagger: Requests for responses in the "reimplementation" can be tested here. (username:admin, password:admin) *[1]
• GitHub Repository: Expertiza GitHub *[2]
• Pull Requests: Detailed pull request for the reimplementation can be viewed here *[3].

Team

Mentor

• Ameya Vaichalkar (ameyav)

Contributors

• Deana Franks
• Maday Moya
• Jacob Leavitt