Expertiza_Wiki - User contributions [en]

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

2024-04-24T03:58:24Z

Mmoyape: /* Test */

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

==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.

==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.

==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.

== 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.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://youtu.be/EWxvSC9hPtU

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

Model Tests Video: https://youtu.be/EPoD3ai33qk

Controller Tests Video: https://youtu.be/moZrjXE-dM8

==References==

*

File:Postman after create for answer.png

2024-04-24T03:56:59Z

Mmoyape:

File:Postman after update for answer.png

2024-04-24T03:56:36Z

Mmoyape:

File:DB after update.png

2024-04-24T03:55:46Z

Mmoyape:

File:DB after create.png

2024-04-24T03:55:36Z

Mmoyape:

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

2024-04-24T03:48:22Z

Mmoyape: /* Test */

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

==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.

==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.

==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.

== 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.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Response model test===
====Postman Tests====
Validate Parameters :

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Response model test===
====Postman Tests====

===Responses Controller test===
====Postman Tests====

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk

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

Model Tests Video: https://youtu.be/EPoD3ai33qk

Controller Tests Video: https://youtu.be/moZrjXE-dM8

==References==

*

File:Postman after update.png

2024-04-24T03:47:50Z

Mmoyape:

File:DB validate parameters update test.png

2024-04-24T03:42:00Z

Mmoyape:

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

2024-04-24T03:37:40Z

Mmoyape: /* Test */

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

==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.

==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.

==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.

== 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.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Response model test===
====Postman Tests====

===Response model test===
====Postman Tests====

===Responses Controller test===
====Postman Tests====

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk

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

Model Tests Video: https://youtu.be/EPoD3ai33qk

Controller Tests Video: https://youtu.be/moZrjXE-dM8

==References==

*

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

2024-04-24T03:36:14Z

Mmoyape: /* Response model test */

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

==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.

==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.

==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.

== 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.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Response model test===
====Postman Tests====

===Responses Controller test===

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk

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

Model Tests Video: https://youtu.be/EPoD3ai33qk

Controller Tests Video: https://youtu.be/moZrjXE-dM8

==References==

*

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

2024-04-24T03:32:37Z

Mmoyape: /* Test */

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

==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.

==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.

==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.

== 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.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Response model test===

===Responses Controller test===

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk

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

Model Tests Video: https://youtu.be/EPoD3ai33qk

Controller Tests Video: https://youtu.be/moZrjXE-dM8

==References==

*

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

2024-04-24T02:50:13Z

Mmoyape: /* Test Plan */

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

==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.

==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.

==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.

== 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.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

==== Init_answers ====

==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

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:

Unit tests will also be written for the controller functions:

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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video: https://youtu.be/EPoD3ai33qk

Controller Tests Video: https://youtu.be/moZrjXE-dM8

==References==

*

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

2024-04-24T02:49:36Z

Mmoyape:

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

==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.

==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.

==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.

== 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.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

==== Init_answers ====

==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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:

Unit tests will also be written for the controller functions:

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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video: https://youtu.be/EPoD3ai33qk

Controller Tests Video: https://youtu.be/moZrjXE-dM8

==References==

*

File:Controller Class diagram.png

2024-04-24T02:46:30Z

Mmoyape:

File:Use cases controller.png

2024-04-24T02:45:46Z

Mmoyape:

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

2024-04-23T05:12:03Z

Mmoyape: /* Show_calibration_results_for_student */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Authorize_show_calibration_before.png|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

==== Init_answers ====

==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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:

Unit tests will also be written for the controller functions:

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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T05:10:15Z

Mmoyape: /* Show_calibration_results_for_student */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Authorize_show_calibration_before.png|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.

[[File:Show_calibration_results.png|900px]]

==== Init_answers ====

==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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:

Unit tests will also be written for the controller functions:

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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T05:09:44Z

Mmoyape: /* Solutions/Details of Changes Made */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
Before:

[[File:Authorize_show_calibration_before.png|900px]]

The show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.

[[File:Show_calibration_results.png|900px]]

==== Init_answers ====

==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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:

Unit tests will also be written for the controller functions:

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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

File:Authorize show calibration before.png

2024-04-23T05:09:33Z

Mmoyape:

File:Show calibration results.png

2024-04-23T05:08:55Z

Mmoyape:

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

2024-04-23T05:07:00Z

Mmoyape: /* Show_calibration_results_for_student */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====
The show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.

==== Init_answers ====

==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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:

Unit tests will also be written for the controller functions:

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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T04:53:15Z

Mmoyape: /* Response Controller */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

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.

==== Show_calibration_results_for_student ====

==== Init_answers ====

==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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:

Unit tests will also be written for the controller functions:

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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T04:47:58Z

Mmoyape: /* Test Plan */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Beside Basic Crud MEthods
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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:

Unit tests will also be written for the controller functions:

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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T04:43:50Z

Mmoyape: /* Response Helper */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Beside Basic Crud MEthods
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T04:43:39Z

Mmoyape: /* Response Helper */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Beside Basic Crud MEthods
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:
[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T04:42:52Z

Mmoyape: /* Update_answers */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Beside Basic Crud MEthods
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method. To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:
[[File:Create_update_answers_before.png|900px]]

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T04:42:28Z

Mmoyape:

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
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.

Beside Basic Crud MEthods
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method. To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:
[[File:Create_update_answers_before.png|900px]]

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.
[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

File:Update answers after.png

2024-04-23T04:42:10Z

Mmoyape:

File:Create answers after.png

2024-04-23T04:41:53Z

Mmoyape:

File:Create update answers before.png

2024-04-23T04:40:37Z

Mmoyape:

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

2024-04-23T04:15:39Z

Mmoyape: /* 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: */

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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. Each new method does one thing only, which makes them easier to understand and maintain.===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Jacob Leavitt

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T04:14:25Z

Mmoyape:

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

==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.

==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.

==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.

== 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.

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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:===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==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.

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Jacob Leavitt

==Links==
Swagger Video Link:

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

Model Tests Video:

Controller Tests Video:

==References==

*

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

2024-04-23T04:13:42Z

Mmoyape: /* 1.Expertiza */

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

==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==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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:===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

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

2024-04-23T04:13:02Z

Mmoyape: /* Template Method */

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==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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:===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

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

2024-04-23T04:04:40Z

Mmoyape: /* 5. Solutions/Details of Changes Made */

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==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===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:===
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

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

2024-04-23T04:04:06Z

Mmoyape: /* validate_params */

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==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

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:
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

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

2024-04-23T04:03:54Z

Mmoyape: /* 5. Solutions/Details of Changes Made */

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==
=== Response Model ===
Methods within the response 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 is the original method that was 46 lines long:
[[File:Validate parameters before.png|900px]]

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:
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

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

2024-04-23T04:01:57Z

Mmoyape: /* 5. Solutions/Details of Changes Made */

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==
=== Response Model ===
Methods within the response 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:
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

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

2024-04-23T04:01:02Z

Mmoyape: /* 5. Solutions/Details of Changes Made */

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==
=== Response Model ===
Methods within the response 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:
* 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.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status.png|900px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

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

2024-04-23T04:00:18Z

Mmoyape: /* 5. Solutions/Details of Changes Made */

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==
=== Response Model ===
Methods within the response 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:
* 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.
[[File:Assign map id.png|1200px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|1200px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|1200px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|1200px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|1200px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|1200px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status.png|1200px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

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

2024-04-23T03:58:55Z

Mmoyape: /* validate_params */

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==
=== Response Model ===
Methods within the response 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:
* 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.
[[File:Assign map id.png|1000px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|1000px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|1000px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|1000px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|1000px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|1000px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status.png|1000px]]

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

=== Response Controller ===
Controller methods for CRUD operations were enhanced, comprising:
==== Create ====
==== Show ====
==== Update ====
==== Delete ====
==== 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.
==== Show_calibration_results_for_student ====
==== Init_answers ====
==== Save ====

=== Response Helper ===
==== Create_answers ====
==== Update_answers ====

==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:

==References==

*

File:Set and validte response.png

2024-04-23T03:46:25Z

Mmoyape:

File:Validate update conditions.png

2024-04-23T03:43:34Z

Mmoyape:

File:Validate submission status .png

2024-04-23T03:43:27Z

Mmoyape:

File:Validate parameters before.png

2024-04-23T03:43:17Z

Mmoyape:

File:Validate parameters after.png

2024-04-23T03:43:01Z

Mmoyape:

File:Validate create condition.png

2024-04-23T03:42:51Z

Mmoyape:

File:Set response attributes.png

2024-04-23T03:42:41Z

Mmoyape:

File:Assign map id.png

2024-04-23T03:42:19Z

Mmoyape:

File:Action specific validation.png

2024-04-23T03:41:55Z

Mmoyape: