CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)

CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document)

1.Expertiza

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.

2.Problem Statement

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.

3.Design Goal

The redesign of the `responses_controller.rb` is guided by several key objectives to improve the code quality, system behavior, and developer interaction. The goals include:

• Maintainability and Scalability: Ensuring the code is easy to understand, modify, and extend. The reimplementation should simplify future updates and feature additions.

• Adherence to Rails Best Practices: Following Rails conventions for naming, structure, and coding practices to ensure code consistency and reliability.

• DRY Principle: "Don't Repeat Yourself" - removing redundant code and logic to create a more efficient and error-resistant codebase.

• Single Responsibility Principle: Restructuring the controller and associated models so that each class and method has one purpose and one purpose only, leading to easier testing and management.

• Improved Testing and Coverage: Enhancing test suites to cover more scenarios and edge cases, increasing confidence in the application's stability and performance.

• Performance Optimization: Identifying and optimizing slow or inefficient areas in the code to ensure the application runs smoothly.

• Clean Up Dead Methods: Audit the codebase for any unused ("dead") methods within the current controller and remove them to declutter the code.

• Reduced Controller Complexity: We already have streamline the `ResponseController` to focus primarily on CRUD operations and extract non-essential logic to appropriate models or helpers, now we aim to implement the rest operations.

By meeting these design goals, the project aims to produce a `responses_controller.rb` that is robust, efficient, and a pleasure to work with, both for the current development team and for those who will maintain the system in the future.

4. Design Pattern

During the code refactoring process, we conscientiously followed various design patterns to enhance the overall structure. When refactoring the Response model and associated controller and helper methods in the application, several key design patterns and principles were followed to ensure improved code quality, maintainability, and scalability. Here are the primary patterns and principles that were considered:

Single Responsibility Principle (SRP)

This principle was applied to break down complex methods into smaller, more focused functions that handle a specific part of the process

• In the Response Model:

Validate_params was broken down into multiple smaller methods, each handling a specific part of the validation process. This allows each method to manage one aspect of the validation, making the code easier to maintain and modify. Creation and management of relationships and basic attributes were clearly defined, ensuring that the Response class isn't overloaded with logic that doesn't pertain to its direct attributes or relationships.

• In the ResponsesController:

The controller methods like create, update, show, etc., were defined to handle only HTTP requests and delegate business logic to the model or helper methods. This keeps the controller actions clean and focused on routing and basic request handling.

• In the ResponseHelper:

Methods such as create_answers and update_answers are good examples where each method is tasked with either creating or updating answers but not both. This follows SRP by dividing the responsibilities into more manageable, discrete operations.

Factory Method

The Factory Method pattern can be seen implicitly where object creation processes are encapsulated within the model or helper methods, such as creating a new ResponseMap or generating new Answer objects. This ensures that object creation is modular and separated from the main application logic.

Strategy Pattern

By defining a family of algorithms (in this case, validation rules for different actions like create or update), encapsulating each one, and making them interchangeable, the strategy pattern lets the algorithm vary independently from the clients that use it. For instance, separating the validation conditions for creating and updating responses allows for flexible swapping and extension of validation logic without modifying the controller or model directly.

Observer Pattern

Used typically in scenarios where changes to a particular object need to notify other dependent objects automatically. In the context of this application, this could relate to notifying instructors or peers upon the submission or update of responses, handled through the helper methods for sending emails.

Template Method

This pattern can be used in defining the skeleton of an operation in a method, deferring some steps to subclasses or other methods. It's seen in how validate_params uses a general structure for validation but defers the specifics to methods like validate_create_conditions and validate_update_conditions. By integrating these design patterns and principles, the refactoring aims to achieve a more robust, maintainable, and scalable system. This approach not only addresses current complexities but also lays a foundation for easier future enhancements and modifications.

5. Solutions/Details of Changes Made

Model

Methods within the model were refactored or introduced, including:

set_content

Redesigned to gather and prepare the required data for response objects, optimizing the interaction with associated models

validate_params

This method was significantly refactored to improve parameter validation. It was split into multiple smaller, focused methods, each dedicated to handling a specific aspect of the validation process: o assign_map_id_from_params: Sets the map_id for the response based on the provided parameters, ensuring the correct map ID is used for both creating and updating responses. o set_response_map_from_id: Ensures that the response_map exists based on the map_id. If not found, it adds an error to halt further processing. o validate_create_action: Validates parameters specific to creating a response, such as checking for existing responses with the same map ID, round, and version number to prevent duplicates. o validate_update_action: Ensures that updates do not violate constraints, such as attempting to update a response that has already been submitted or changing its map ID. o assign_additional_params: Assigns other response parameters from the incoming request, such as round, version_num, additional_comment, and visibility.

serialize_response

Improved to efficiently serialize response data for API interactions, enhancing the clarity and usability of data exchanges.

Controller

Controller methods for CRUD operations were enhanced, comprising:

Questionnaire_from_response_map and Questionnaire_from_response

 Removed Methods: Legacy methods like Questionnaire_from_response_map and Questionnaire_from_response were removed following the refactoring of set_content, which now handles its functionalities internally without the need for these methods.

5. Files Modified/Added

List of primary files modified or created includes:

• responses_controller.rb
• response_helper.rb
• response.rb

6. Test Plan

The Model and Controller functions will be tested throughoughly.

Rspec unit tests will be used to test each function of the refactored and reimplemented functions to verify the expected responses are received for given inputs.

Unit tests will be written for the following model functions:

*set_content
*validate_params
*serialize_response

Unit tests will also be written for the controller functions:

*Create
*Show
*Update
*Delete
*Questionnaire_from_response_map
*Questionnaire_from_response
*Create_answers
*Show_calibration_results_for_student
*Init_answers
*Save

The Swagger UI will be utilized to make the controller functions accessible VIA API calls. This will allow for testing of the input and outputs of the API calls to the methods, and will function as integration tests.

7. Team

Mentor

• Ameya Vaichalkar

Members

• Jeff Riehle
• Maday Moya
• Jacob Leavitt

8. Links

Swagger Video Link:

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video:

Controller Tests Video: