Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T03:45:28Z

Ntaori:

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

Updated respnse_map.rb
[[File: Response_map_new.png|center]]
Updated Response.rb
[[File: Response_new.png|center]]
New code of Feedback_response_controller.rb
[[File: Feedback_response_controller.png|center]]
New code for response_mao_controller.rb
[[File: Response_map_controller.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Video==
https://youtu.be/-42u-dL67Mo

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Response map new.png

2025-04-23T03:42:28Z

Ntaori: Ntaori uploaded a new version of File:Response map new.png

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T03:16:55Z

Ntaori: /* Improvised Code and New Code */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

Updated respnse_map.rb
[[File: Response_map_new.png|center]]
Updated Response.rb
[[File: Response_new.png|center]]
New code of Feedback_response_controller.rb
[[File: Feedback_response_controller.png|center]]
New code for response_mao_controller.rb
[[File: Response_map_controller.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Response map controller.png

2025-04-23T03:16:03Z

Ntaori:

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T03:14:24Z

Ntaori: /* Improvised Code and New Code */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

Updated respnse_map.rb
[[File: Response_map_new.png|center]]
Updated Response.rb
[[File: Response_new.png|center]]
New code of Feedback_response_controller.rb
[[File: Feedback_response_controller.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T03:13:22Z

Ntaori: /* Improvised Code and New Code */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

[[File: Response_map_new.png|center]]
[[File: Response_new.png|center]]

[[File: Feedback_response_controller.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T03:12:54Z

Ntaori: /* Improvised Code and New Code */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

[[File: Response_map_new.png|center]]
[[File: Response_new.png|center]]
[[File: Feedback_response_controller.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Feedback response controller.png

2025-04-23T03:12:09Z

Ntaori:

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T03:05:21Z

Ntaori: /* Improvised Code and New Code */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

[[File: Response_map_new.png|center]]
[[File: Response_new.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Response new.png

2025-04-23T03:04:51Z

Ntaori: Ntaori uploaded a new version of File:Response new.png

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T03:02:38Z

Ntaori: /* Improvised Code and New Code */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

[[File: Response_map_new.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Response map new.png

2025-04-23T03:02:14Z

Ntaori: Ntaori uploaded a new version of File:Response map new.png

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T02:56:38Z

Ntaori: /* Improvised Code and New Code */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T02:56:03Z

Ntaori: /* Improvised Code and New Code */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

[[File: Response_new.png|center]]

[[File: response_map_new.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T02:55:50Z

Ntaori:

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

[[File: Response_new.png|center]]
[[File: response_map_new.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Response map new.png

2025-04-23T02:55:27Z

Ntaori:

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T02:54:26Z

Ntaori:

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

[[File: Response_new.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T02:53:16Z

Ntaori:

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters. The snippets of the code are below:

[[File: response.png|center]]

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Response new.png

2025-04-23T02:52:21Z

Ntaori:

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T02:50:17Z

Ntaori:

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

[[File:FeedbackEmailService.png|center|500px]]

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

On testing the email functionality, we get this

[[File: FeedbackEmailServiceTest.png|center]]

===Improvised Code and New Code===
In the new Response class, logic for score aggregation and threshold comparison is more robust and encapsulated using model-level delegation (delegate) and helper methods, improving clarity and reusability. The ResponseMap class has been enhanced to return latest submitted responses selectively (especially for ReviewResponseMap), introducing type-checking and sorting to ensure the most recent relevant assessments are used. The ResponseMapsController was added to handle API endpoints for CRUD operations and reporting on ResponseMap objects, including actions like index, show, create, update, destroy, and response_report, enabling comprehensive backend support for managing peer reviews. A specialized controller FeedbackResponseMapsController was added to extend ResponseMapsController, enabling operations specific to feedback-based peer reviews, such as fetching assignment-specific feedback maps, calculating submission rates, and managing FeedbackResponseMap creation with customized parameters.

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T01:16:28Z

Ntaori: /* Testing */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==New Implementation==

=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

===Testing the Email Functionality===

The overall goal of the test is to ensure that the FeedbackEmailService correctly constructs the email content and interacts with the Mailer class to send the notification, verifying that the key fields in the email definition are accurate. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully. This has increased the coverage of the code to 7%.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Testing response map controller.png

2025-04-23T01:06:19Z

Ntaori: Ntaori uploaded a new version of File:Testing response map controller.png

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T00:20:19Z

Ntaori:

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==Implementation==
=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

In the accompanying RSpec test file, the functionality of the FeedbackEmailService is verified. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

==New Implementation==
===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully.

[[File: Testing_response_map_controller.png|center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

File:Testing response map controller.png

2025-04-23T00:19:32Z

Ntaori:

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T00:16:48Z

Ntaori:

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==Implementation==
=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

In the accompanying RSpec test file, the functionality of the FeedbackEmailService is verified. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

==New Implementation==
===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully.

[[File: |center]]

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T00:14:04Z

Ntaori: /* Testing */

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==Implementation==
=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

In the accompanying RSpec test file, the functionality of the FeedbackEmailService is verified. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

==New Implementation==
===Testing===
The ResponseMapsController in the application has been unit tested to ensure the stability and correctness of key API functionalities related to peer reviews. The testing focuses on verifying that the controller handles data retrieval and creation operations accurately, and that valid HTTP responses are returned under expected conditions. Three core functionalities have been validated through successful unit tests. First, the GET /api/v1/response_maps endpoint is tested to confirm that it retrieves all existing response maps from the database, ensuring the index action behaves as expected. Second, the GET /api/v1/response_maps/:id test confirms that a specific response map can be fetched reliably using its ID, and also handles the edge case of returning null if the record does not exist. Third, the POST /api/v1/response_maps endpoint is tested to verify that a new response map can be created successfully when valid reviewer and reviewee participants are provided. These tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as essential checks to confirm that the controller functions as intended and handles basic CRUD operations gracefully.

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-23T00:12:43Z

Ntaori:

__TOC__

== Introduction ==

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews and this is what the project will mainly focus on.

[[File: OODD.drawio.png|center]]

The system architecture follows an inheritance structure where the ResponseMap class acts as a base class, and both ReviewResponseMap and FeedbackResponseMap are its subclasses. This object-oriented design allows for modular handling of different types of responses in the system. While ReviewResponseMap manages the mapping between reviewers and reviewees for peer reviews, FeedbackResponseMap is specifically responsible for capturing feedback from reviewees on the reviews they received. The inheritance ensures shared functionality resides in the ResponseMap superclass, while each subclass handles its specific behavior, promoting code reuse and easier maintenance.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==Implementation==
=== Email Functionality ===
To adhere to Single Responsibility Principle, the email functionality was extracted from FeedbackResponseMap model and was implemented as a service called FeedbackEmailService. The service is basically responsible for sending email notification about the feedback. By extracting this code into a service, the model is lean and strictly focused on data and there is a place that is entirely dedicated to the emails. The separation also makes the testing simpler because a small, fast unit test can be written for the service without touching the database or a real mail server, and if the notification requirements ever change, it is clear where changes can be made. Additionally, the class utilizes the Service Object Pattern, which is a design pattern commonly employed to organize business logic that doesn’t naturally fit within models or controllers. This pattern is used in the class to encapsulate the logic for sending feedback emails, isolating this responsibility from other parts of the application. This separation of concerns makes the codebase more organized and less prone to errors when modifications are needed.

The FeedbackEmailService class is a service responsible for sending an email notification about feedback. It is initialized with two parameters: a response_map and an assignment. The call method is the public API for triggering the email sending process, which relies on the Mailer.sync_message method. This method is passed a definition, built by the private build_defn method, that contains details for the email such as the recipient's email address, the type of feedback, the recipient's first name, and the assignment's name. The build_defn method retrieves the necessary data by looking up various models: it finds the original review response using the response_map, then tracks back to the response map that created the review, the participant who wrote the review, and ultimately the user associated with the participant.

In the accompanying RSpec test file, the functionality of the FeedbackEmailService is verified. The test sets up several test doubles to simulate the behavior of the models involved (such as Response, ResponseMap, AssignmentParticipant, and User). These test doubles allow the test to isolate and focus on the behavior of the service without actually querying the database. The before block stubs the find methods of ActiveRecord models to return predefined doubles, and it also mocks the Mailer class to intercept the email sending process. In the test, the service is instantiated, and it is verified that the email definition is built correctly, with the expected values for the recipient's email, the email type, the user's full name, and the assignment name. The test concludes by calling the call method to simulate sending the email, ensuring the Mailer.sync_message method is invoked with the correct parameters.

==New Implementation==
===Testing===
The ResponseMapsController has been thoroughly unit tested to ensure that core functionalities like retrieving, creating, and showing response maps work as expected. These tests validate the controller’s behavior under normal conditions and help maintain the integrity of the response map-related API endpoints. Specifically, the test suite verifies that all response maps can be fetched (GET /api/v1/response_maps), a single response map can be retrieved by its ID (GET /api/v1/response_maps/:id), and new response maps can be successfully created (POST /api/v1/response_maps). These working unit tests—returns all response maps, returns the requested response map or 'null' if not found, and creates a new response map and returns it—serve as a foundation for ensuring correctness and preventing regressions as the code evolves.

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-09T15:58:43Z

Ntaori: /* Defects in existing code */

__TOC__

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-09T15:58:21Z

Ntaori: /* Defects in existing code */

__TOC__

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
The ResponseMap class contains certain implementations that reflect a partial or incorrect application of common object-oriented design patterns.

While the ResponseMap class makes use of several object-oriented principles, some design patterns appear to have been applied in a limited or suboptimal manner. Two key patterns that could be improved in this implementation are the Strategy and Delegation patterns.

===Strategy Pattern===
The assessments_for method includes logic that changes behavior based on the type of response map, such as conditionally handling instances of ReviewResponseMap. This suggests the need for the Strategy pattern, where each type of map could encapsulate its own assessment retrieval behavior. However, instead of using polymorphism or encapsulated strategies, the method relies on conditional checks (if map.type.eql?('ReviewResponseMap')), leading to tightly coupled and hard-to-extend logic.

===Delegation Pattern===
The method response_assignment performs manual delegation by directly retrieving the reviewer's assignment through a chain of method calls (Participant.find(self.reviewer_id).assignment). This approach bypasses more maintainable delegation mechanisms provided by the framework, such as Ruby’s delegate method. As a result, the model becomes more tightly coupled to other classes and less readable, reducing flexibility and violating the principle of clear responsibility separation.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-09T15:53:54Z

Ntaori:

__TOC__

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.
* Alias Declaration: The model ID is aliased as map_id for internal referencing.
* Custom Methods:
** response_assignment: Fetches the assignment associated with the reviewer.
** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

===Design Patterns in ResponseMap===
The ResponseMap class in this Ruby on Rails application exhibits the use of established object-oriented design patterns. Two notable patterns implemented in the class are the Iterator and Delegation patterns.

====Iterator Pattern====
The assessments_for class method makes use of Ruby's built-in each construct to iterate over collections of ResponseMap instances and associated Response records. This reflects the Iterator design pattern, which provides a uniform interface for traversing elements in a collection. In this context, it allows the code to abstract away the internal structure of the response map list, enabling clean and consistent traversal without exposing collection details to the caller.

====Delegation Pattern====
The method response_assignment illustrates the Delegation pattern, where the task of retrieving the associated Assignment is delegated to the Participant object representing the reviewer. Rather than the ResponseMap owning the logic for determining the assignment, it calls Participant.find(self.reviewer_id).assignment, passing responsibility to the related model. Although implemented in a direct and somewhat manual way, it reflects the core idea of delegation—passing behavior to another object that is better suited to handle it.

==Defects in existing code==
The ResponseMap class contains certain implementations that reflect a partial or incorrect application of common object-oriented design patterns.

===Strategy Pattern===
The assessments_for method contains explicit conditional checks based on the type of response map (e.g., 'ReviewResponseMap'). While this suggests a need for dynamic behavior selection, the logic is implemented through hardcoded conditionals rather than encapsulated strategy objects. This results in behavior that is rigid and difficult to extend, diverging from the intended use of the Strategy pattern.

===Delegation===
The method response_assignment performs manual delegation by directly querying the Participant model to access the assignment. This form of delegation bypasses object encapsulation and does not utilize Ruby's built-in delegate functionality, leading to tight coupling and reduced maintainability.

===Facade Pattern===
The ResponseMap model serves as a central access point for various related objects and operations, such as retrieving responses and assignments. While this reflects the Facade pattern in form, the model's accumulation of responsibilities indicates a potential overuse of this pattern, leading to a violation of the Single Responsibility Principle.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

=== ResponseMap Controller ===
The ResponseMapController serves as the base controller for all types of response maps within the system. It encapsulates common functionalities shared across different response map types, significantly reducing code duplication. By centralizing shared logic, the controller promotes a modular architecture, making the codebase easier to maintain, extend, and test. This refactoring effort aligns with the architectural improvements discussed with the professor and forms the foundation for scalable enhancements in the future.

=== FeedbackResponseMap Controller ===
The FeedbackResponseMapController extends the base ResponseMapController and overrides specific functionalities that differ from the generic response map logic. In addition to the overridden methods, this controller implements new features exclusive to feedback response maps, such as feedback_response_report. These additions are tailored to meet the unique requirements of handling feedback responses and ensure specialized behavior without compromising the integrity of the base class design.

=== Testing ===
We are planning to implement a comprehensive testing strategy to ensure the reliability and correctness of the refactored response map system. Key elements of this approach include:
*Object Creation Based on Model Relationships: All dependent objects will be instantiated in accordance with the established model relationships before creating a response map object.
*Edge Case Handling: We are addressing previously unhandled edge cases, such as creating response maps for rounds that have not yet occurred (e.g., assigning a round attribute value higher than the current one).
*High Coverage: Our test suite includes unit, integration, and end-to-end tests to verify both base and specialized behaviors across the system.
*Documentation: Each test will be accompanied by detailed documentation to facilitate understanding and reproducibility.

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-09T00:06:05Z

Ntaori:

This page contains the details of OSS project ''E2509: Refactoring and Enhancing the Feedback Response Map Controller'' done for Expertiza in Spring 2025.

__TOC__

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.

* Alias Declaration: The model ID is aliased as map_id for internal referencing.

* Custom Methods:

1.response_assignment: Fetches the assignment associated with the reviewer.

2.assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

==Design Patterns in ResponseMap==
The ResponseMap class exhibits or could benefit from several well-known object-oriented design patterns. While the current implementation reflects some implicit design patterns typical in Rails applications, certain improvements are evident through the lens of more structured design paradigms.

===Strategy Pattern===
The method assessments_for includes conditional logic that varies based on the type of ResponseMap, particularly for ReviewResponseMap. This could be refactored using the Strategy pattern, allowing each map type to define its own behavior for assessment filtering without relying on if statements.

===Visitor Pattern===
Handling different types of response maps could also be facilitated by the Visitor pattern. Each ResponseMap subtype could accept a visitor responsible for retrieving or processing its latest response, simplifying type-specific operations.

===Decorator Pattern===
Presentation and formatting logic, such as how responses are displayed or filtered, could be extracted into decorators to reduce bloating within the model and adhere to the Single Responsibility Principle.

===Delegation===
While partially implemented, the model could leverage Ruby's delegate method to cleanly access associated data (e.g., delegating assignment to the reviewer), replacing manual chaining like Participant.find(...).assignment.

===Facade Pattern===
The complex business logic found in assessments_for suggests a need for the Facade pattern. Extracting this logic into a service object would provide a cleaner interface for retrieving assessments and improve separation of concerns.

===State Pattern===
The Response model’s submission status (is_submitted) could be modeled with a State pattern, allowing more flexible behavior and transitions between states (e.g., draft, submitted, archived) instead of using basic booleans.

==Problem statement==

==Defects in existing code==
The ResponseMap class contains certain implementations that reflect a partial or incorrect application of common object-oriented design patterns.

===Strategy Pattern===
The assessments_for method contains explicit conditional checks based on the type of response map (e.g., 'ReviewResponseMap'). While this suggests a need for dynamic behavior selection, the logic is implemented through hardcoded conditionals rather than encapsulated strategy objects. This results in behavior that is rigid and difficult to extend, diverging from the intended use of the Strategy pattern.

===Delegation===
The method response_assignment performs manual delegation by directly querying the Participant model to access the assignment. This form of delegation bypasses object encapsulation and does not utilize Ruby's built-in delegate functionality, leading to tight coupling and reduced maintainability.

===Facade Pattern===
The ResponseMap model serves as a central access point for various related objects and operations, such as retrieving responses and assignments. While this reflects the Facade pattern in form, the model's accumulation of responsibilities indicates a potential overuse of this pattern, leading to a violation of the Single Responsibility Principle.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-09T00:05:24Z

Ntaori:

This page contains the details of OSS project ''E2509: Refactoring and Enhancing the Feedback Response Map Controller'' done for Expertiza in Spring 2025.

__TOC__

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.

* Alias Declaration: The model ID is aliased as map_id for internal referencing.

* Custom Methods:

*response_assignment: Fetches the assignment associated with the reviewer.

*assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

==Design Patterns in ResponseMap==
The ResponseMap class exhibits or could benefit from several well-known object-oriented design patterns. While the current implementation reflects some implicit design patterns typical in Rails applications, certain improvements are evident through the lens of more structured design paradigms.

===Strategy Pattern===
The method assessments_for includes conditional logic that varies based on the type of ResponseMap, particularly for ReviewResponseMap. This could be refactored using the Strategy pattern, allowing each map type to define its own behavior for assessment filtering without relying on if statements.

===Visitor Pattern===
Handling different types of response maps could also be facilitated by the Visitor pattern. Each ResponseMap subtype could accept a visitor responsible for retrieving or processing its latest response, simplifying type-specific operations.

===Decorator Pattern===
Presentation and formatting logic, such as how responses are displayed or filtered, could be extracted into decorators to reduce bloating within the model and adhere to the Single Responsibility Principle.

===Delegation===
While partially implemented, the model could leverage Ruby's delegate method to cleanly access associated data (e.g., delegating assignment to the reviewer), replacing manual chaining like Participant.find(...).assignment.

===Facade Pattern===
The complex business logic found in assessments_for suggests a need for the Facade pattern. Extracting this logic into a service object would provide a cleaner interface for retrieving assessments and improve separation of concerns.

===State Pattern===
The Response model’s submission status (is_submitted) could be modeled with a State pattern, allowing more flexible behavior and transitions between states (e.g., draft, submitted, archived) instead of using basic booleans.

==Problem statement==

==Defects in existing code==
The ResponseMap class contains certain implementations that reflect a partial or incorrect application of common object-oriented design patterns.

===Strategy Pattern===
The assessments_for method contains explicit conditional checks based on the type of response map (e.g., 'ReviewResponseMap'). While this suggests a need for dynamic behavior selection, the logic is implemented through hardcoded conditionals rather than encapsulated strategy objects. This results in behavior that is rigid and difficult to extend, diverging from the intended use of the Strategy pattern.

===Delegation===
The method response_assignment performs manual delegation by directly querying the Participant model to access the assignment. This form of delegation bypasses object encapsulation and does not utilize Ruby's built-in delegate functionality, leading to tight coupling and reduced maintainability.

===Facade Pattern===
The ResponseMap model serves as a central access point for various related objects and operations, such as retrieving responses and assignments. While this reflects the Facade pattern in form, the model's accumulation of responsibilities indicates a potential overuse of this pattern, leading to a violation of the Single Responsibility Principle.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-09T00:04:35Z

Ntaori:

This page contains the details of OSS project ''E2509: Refactoring and Enhancing the Feedback Response Map Controller'' done for Expertiza in Spring 2025.

__TOC__

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

* Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

* Assignment: The object being reviewed, associated through the reviewed_object_id.

* Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
* Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.

* Alias Declaration: The model ID is aliased as map_id for internal referencing.

* Custom Methods:

** response_assignment: Fetches the assignment associated with the reviewer.

** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

==Design Patterns in ResponseMap==
The ResponseMap class exhibits or could benefit from several well-known object-oriented design patterns. While the current implementation reflects some implicit design patterns typical in Rails applications, certain improvements are evident through the lens of more structured design paradigms.

===Strategy Pattern===
The method assessments_for includes conditional logic that varies based on the type of ResponseMap, particularly for ReviewResponseMap. This could be refactored using the Strategy pattern, allowing each map type to define its own behavior for assessment filtering without relying on if statements.

===Visitor Pattern===
Handling different types of response maps could also be facilitated by the Visitor pattern. Each ResponseMap subtype could accept a visitor responsible for retrieving or processing its latest response, simplifying type-specific operations.

===Decorator Pattern===
Presentation and formatting logic, such as how responses are displayed or filtered, could be extracted into decorators to reduce bloating within the model and adhere to the Single Responsibility Principle.

===Delegation===
While partially implemented, the model could leverage Ruby's delegate method to cleanly access associated data (e.g., delegating assignment to the reviewer), replacing manual chaining like Participant.find(...).assignment.

===Facade Pattern===
The complex business logic found in assessments_for suggests a need for the Facade pattern. Extracting this logic into a service object would provide a cleaner interface for retrieving assessments and improve separation of concerns.

===State Pattern===
The Response model’s submission status (is_submitted) could be modeled with a State pattern, allowing more flexible behavior and transitions between states (e.g., draft, submitted, archived) instead of using basic booleans.

==Problem statement==

==Defects in existing code==
The ResponseMap class contains certain implementations that reflect a partial or incorrect application of common object-oriented design patterns.

===Strategy Pattern===
The assessments_for method contains explicit conditional checks based on the type of response map (e.g., 'ReviewResponseMap'). While this suggests a need for dynamic behavior selection, the logic is implemented through hardcoded conditionals rather than encapsulated strategy objects. This results in behavior that is rigid and difficult to extend, diverging from the intended use of the Strategy pattern.

===Delegation===
The method response_assignment performs manual delegation by directly querying the Participant model to access the assignment. This form of delegation bypasses object encapsulation and does not utilize Ruby's built-in delegate functionality, leading to tight coupling and reduced maintainability.

===Facade Pattern===
The ResponseMap model serves as a central access point for various related objects and operations, such as retrieving responses and assignments. While this reflects the Facade pattern in form, the model's accumulation of responsibilities indicates a potential overuse of this pattern, leading to a violation of the Single Responsibility Principle.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-09T00:03:35Z

Ntaori:

This page contains the details of OSS project ''E2509: Refactoring and Enhancing the Feedback Response Map Controller'' done for Expertiza in Spring 2025.

__TOC__

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

*Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

*Assignment: The object being reviewed, associated through the reviewed_object_id.

*Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
*Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.

*Alias Declaration: The model ID is aliased as map_id for internal referencing.

*Custom Methods:

** response_assignment: Fetches the assignment associated with the reviewer.

** assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

==Design Patterns in ResponseMap==
The ResponseMap class exhibits or could benefit from several well-known object-oriented design patterns. While the current implementation reflects some implicit design patterns typical in Rails applications, certain improvements are evident through the lens of more structured design paradigms.

===Strategy Pattern===
The method assessments_for includes conditional logic that varies based on the type of ResponseMap, particularly for ReviewResponseMap. This could be refactored using the Strategy pattern, allowing each map type to define its own behavior for assessment filtering without relying on if statements.

===Visitor Pattern===
Handling different types of response maps could also be facilitated by the Visitor pattern. Each ResponseMap subtype could accept a visitor responsible for retrieving or processing its latest response, simplifying type-specific operations.

===Decorator Pattern===
Presentation and formatting logic, such as how responses are displayed or filtered, could be extracted into decorators to reduce bloating within the model and adhere to the Single Responsibility Principle.

===Delegation===
While partially implemented, the model could leverage Ruby's delegate method to cleanly access associated data (e.g., delegating assignment to the reviewer), replacing manual chaining like Participant.find(...).assignment.

===Facade Pattern===
The complex business logic found in assessments_for suggests a need for the Facade pattern. Extracting this logic into a service object would provide a cleaner interface for retrieving assessments and improve separation of concerns.

===State Pattern===
The Response model’s submission status (is_submitted) could be modeled with a State pattern, allowing more flexible behavior and transitions between states (e.g., draft, submitted, archived) instead of using basic booleans.

==Problem statement==

==Defects in existing code==
The ResponseMap class contains certain implementations that reflect a partial or incorrect application of common object-oriented design patterns.

===Strategy Pattern===
The assessments_for method contains explicit conditional checks based on the type of response map (e.g., 'ReviewResponseMap'). While this suggests a need for dynamic behavior selection, the logic is implemented through hardcoded conditionals rather than encapsulated strategy objects. This results in behavior that is rigid and difficult to extend, diverging from the intended use of the Strategy pattern.

===Delegation===
The method response_assignment performs manual delegation by directly querying the Participant model to access the assignment. This form of delegation bypasses object encapsulation and does not utilize Ruby's built-in delegate functionality, leading to tight coupling and reduced maintainability.

===Facade Pattern===
The ResponseMap model serves as a central access point for various related objects and operations, such as retrieving responses and assignments. While this reflects the Facade pattern in form, the model's accumulation of responsibilities indicates a potential overuse of this pattern, leading to a violation of the Single Responsibility Principle.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-08T23:53:52Z

Ntaori:

This page contains the details of OSS project ''E2509: Refactoring and Enhancing the Feedback Response Map Controller'' done for Expertiza in Spring 2025.

__TOC__

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

*Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

*Assignment: The object being reviewed, associated through the reviewed_object_id.

*Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
*Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.

*Alias Declaration: The model ID is aliased as map_id for internal referencing.

*Custom Methods:

**response_assignment: Fetches the assignment associated with the reviewer.

**assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

==Design Patterns in ResponseMap==
The ResponseMap class exhibits or could benefit from several well-known object-oriented design patterns. While the current implementation reflects some implicit design patterns typical in Rails applications, certain improvements are evident through the lens of more structured design paradigms.

===Strategy Pattern===
The method assessments_for includes conditional logic that varies based on the type of ResponseMap, particularly for ReviewResponseMap. This could be refactored using the Strategy pattern, allowing each map type to define its own behavior for assessment filtering without relying on if statements.

===Visitor Pattern===
Handling different types of response maps could also be facilitated by the Visitor pattern. Each ResponseMap subtype could accept a visitor responsible for retrieving or processing its latest response, simplifying type-specific operations.

===Decorator Pattern===
Presentation and formatting logic, such as how responses are displayed or filtered, could be extracted into decorators to reduce bloating within the model and adhere to the Single Responsibility Principle.

===Delegation===
While partially implemented, the model could leverage Ruby's delegate method to cleanly access associated data (e.g., delegating assignment to the reviewer), replacing manual chaining like Participant.find(...).assignment.

===Facade Pattern===
The complex business logic found in assessments_for suggests a need for the Facade pattern. Extracting this logic into a service object would provide a cleaner interface for retrieving assessments and improve separation of concerns.

===State Pattern===
The Response model’s submission status (is_submitted) could be modeled with a State pattern, allowing more flexible behavior and transitions between states (e.g., draft, submitted, archived) instead of using basic booleans.

==Problem statement==

==Defects in existing code==
The ResponseMap class contains certain implementations that reflect a partial or incorrect application of common object-oriented design patterns.

===Strategy Pattern===
The assessments_for method contains explicit conditional checks based on the type of response map (e.g., 'ReviewResponseMap'). While this suggests a need for dynamic behavior selection, the logic is implemented through hardcoded conditionals rather than encapsulated strategy objects. This results in behavior that is rigid and difficult to extend, diverging from the intended use of the Strategy pattern.

===Delegation===
The method response_assignment performs manual delegation by directly querying the Participant model to access the assignment. This form of delegation bypasses object encapsulation and does not utilize Ruby's built-in delegate functionality, leading to tight coupling and reduced maintainability.

===Facade Pattern===
The ResponseMap model serves as a central access point for various related objects and operations, such as retrieving responses and assignments. While this reflects the Facade pattern in form, the model's accumulation of responsibilities indicates a potential overuse of this pattern, leading to a violation of the Single Responsibility Principle.

==Implementation Plan==

=== Email Functionality ===
To adhere to the Single Responsibility Principle, the email functionality needs to be extracted from the FeedbackResponseMap model and moved to a separate class called the FeedbackEmailService. This will ensure that the model remains focused solely on managing feedback mappings, while all concerns related to emails are handled independently. Separating this logic will improve code clarity, testability, and maintainability. While a simple service object is sufficient for the current need, other design patterns like Strategy or Visitor could also be considered depending on how the notification logic evolves, especially if multiple types of emails or behaviors need to be supported in the future.

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-08T23:47:26Z

Ntaori:

This page contains the details of OSS project ''E2509: Refactoring and Enhancing the Feedback Response Map Controller'' done for Expertiza in Spring 2025.

__TOC__

==Team==
=====Mentor=====
* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=====Members=====
* Riya Bihani (rbihani@ncsu.edu)
* Nayan Taori (ntaori@ncsu.edu)
* Chandrakant Koneti (ckoneti@ncsu.edu)

== Introduction ==

=== Background ===
Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===
This project aims to refactor the Feedback Response Map controller in the system and to improve the current Feedback Response Map into a more robust and maintainable Response Map and its corresponding controller.

=== Objectives ===
* Refactoring to Response Map - Refactor the existing the Feedback Response Map to make a more generalized Response Map controller by restructuring the methods in the controller and integrate new functionalities in it to support a wider range of response types.

* Thorough Testing - Develop a strategy to cover all features of the new refactored Response Map and controller. To ensure that all functionalities are working, unit tests, integration tests and end-to-end tests need to be included.

* Develop and Test Email Functionality - The email notification functionality has to be included in this project but as separate logic to ensure that the Single Responsibility Principle is followed and there is modularity and clear separation of concerns.

* Code Quality Improvement - The existing codebase should be reviewed and enhanced to improve readability and maintainability. This can be done by updating comments, class names, and variable names. It is important to ensure that all the modifications are well documented and clear.

* Best Practices Implementation - Apply SOLID principles, DRY (Don’t Repeat Yourself) philosophy, and appropriate design patterns to enhance the modularity and testability of the code and justify each implementation choice.

* Originality and Integrity - All the code should be original and should meet the ethical coding standards.

==Current Implementation==
===Overview of ResponseMap Class===
The ResponseMap class is an ActiveRecord model in a Ruby on Rails application, primarily responsible for managing the relationship between reviewers and reviewees within the context of an assignment. It acts as a bridge linking participants (reviewers and reviewees) with their respective responses in a peer-review system.

This class is tightly coupled with several other models:

*Reviewer and Reviewee: Both are instances of the Participant class, representing users assigned to review or be reviewed.

*Assignment: The object being reviewed, associated through the reviewed_object_id.

*Response: The actual evaluation or review content provided by a reviewer.

===Key Functionalities===
*Relationship Management: Utilizes has_many and belongs_to associations to link responses, participants, and assignments.

*Alias Declaration: The model ID is aliased as map_id for internal referencing.

*Custom Methods:

**response_assignment: Fetches the assignment associated with the reviewer.

**assessments_for(team): Gathers the most recent and relevant responses for a given team, filtering based on submission status and response type.

===Logic and Behavior===
The assessments_for class method exemplifies custom business logic that:

*Iterates over response maps for a specific team.

*Filters out empty or unsubmitted responses (especially in the case of ReviewResponseMap types).

*Sorts and selects the latest version of each valid response.

*Returns the final result sorted by reviewer name.

This class is integral to handling the complex mappings and evaluations common in peer-reviewed academic or collaborative environments.

==Design Patterns in ResponseMap==
The ResponseMap class exhibits or could benefit from several well-known object-oriented design patterns. While the current implementation reflects some implicit design patterns typical in Rails applications, certain improvements are evident through the lens of more structured design paradigms.

===Strategy Pattern===
The method assessments_for includes conditional logic that varies based on the type of ResponseMap, particularly for ReviewResponseMap. This could be refactored using the Strategy pattern, allowing each map type to define its own behavior for assessment filtering without relying on if statements.

===Visitor Pattern===
Handling different types of response maps could also be facilitated by the Visitor pattern. Each ResponseMap subtype could accept a visitor responsible for retrieving or processing its latest response, simplifying type-specific operations.

===Decorator Pattern===
Presentation and formatting logic, such as how responses are displayed or filtered, could be extracted into decorators to reduce bloating within the model and adhere to the Single Responsibility Principle.

===Delegation===
While partially implemented, the model could leverage Ruby's delegate method to cleanly access associated data (e.g., delegating assignment to the reviewer), replacing manual chaining like Participant.find(...).assignment.

===Facade Pattern===
The complex business logic found in assessments_for suggests a need for the Facade pattern. Extracting this logic into a service object would provide a cleaner interface for retrieving assessments and improve separation of concerns.

===State Pattern===
The Response model’s submission status (is_submitted) could be modeled with a State pattern, allowing more flexible behavior and transitions between states (e.g., draft, submitted, archived) instead of using basic booleans.

==Problem statement==

==Defects in existing code==

==Implementation Plan==

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-08T23:38:19Z

Ntaori:

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-08T23:36:08Z

Ntaori:

CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller

2025-04-07T11:39:27Z

Ntaori: Created page with "This page contains the details of OSS project ''E2509: Refactoring and Enhancing the Feedback Response Map Controller'' done for Expertiza in Spring 2025. __TOC__ == Expertiza and Project Overview == === Background === Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a worki..."

This page contains the details of OSS project ''E2509: Refactoring and Enhancing the Feedback Response Map Controller'' done for Expertiza in Spring 2025.

__TOC__

== Expertiza and Project Overview ==

=== Background ===

Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===

The aim of this project is to implement the feedback_response_map.rb file in the reimplementation-backend repository of Expertiza. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews.

There is room for improvement in the current system and refactoring the FeedbackResponseMap could enhance its efficiency and flexibility. This would allow for better management of feedback data and provide opportunities for optimizing the overall functionality of the review process.

=== Current Implementation ===

The current feedback_response_map.rb in the Expertiza repository has several methods including assignment, show_review, get_title, questionnaire, feedback_response_report, and email. The assignment method retrieves the assignment associated with the review, the show_review method returns the review's content as HTML or a message if no review exists, the get_title method returns a simple label and the questionnaire method retrieves the feedback questionnaire associated with the assignment. The feedback_response_report method compiles a report by querying multiple tables to gather reviewer information and responses, handling varying rubrics by round, specifically for three rounds of review. Finally, the email method sends feedback emails to reviewers.

However, there are a few problems in the model that need to be fixed -

* Violation of SOLID and DRY principles: The existing code leads to repetition and complexity, which violates the SOLID and DRY principles.
* Issues with the feedback_response_report methods: This method is complicated, handling only the first three rounds of reviews, which introduces redundancy. It also uses a hardcoded approach to varying rubrics across rounds, which should be generalized to support any number of rounds dynamically.
* Misplaced Responsibilities: The email method should not be placed in this class as it violates the Single Responsibility Principle (SRP). It would be better to create a separate class to handle this method.
* Memory Inefficiencies: The method currently consumes excessive memory by using multiple separate arrays for storing review data for different rounds.
* Code Readability and Efficiency: The code suffers from redundant methods, unclear variable names, and inefficient loops that contribute to poor readability and performance. By eliminating this, the code would become more readable, and maintainable.

=== Objectives & Requirements ===
1. Implement methods for the feedback_response_map model

Develop methods in feedback_response_map.rb to properly manage feedback responses and ensure seamless integration and functionality within the system.

2. Adhere to SOLID and DRY Principles

Follow best software design practices by ensuring the code is modular, maintainable, and reusable. Eliminate redundancy and ensure adherence to SOLID and DRY principles.

3. Refactor feedback_response_report Method

Change the feedback_response_report method to allow it to support a dynamic number of rounds and eliminate redundant logic for varying rubrics across rounds, which will improve efficiency.

4. Separate Email Functionality

Separate the email notification logic from the FeedbackResponseMap class using the Visitor Pattern, adhering to the Single Responsibility Principle and enhancing modularity and maintaining clear separation of concerns.

5. Remove Redundant Code and Improve Readability

Eliminate unnecessary methods that do not contribute to core functionality. Refactor long or unclear method names for better clarity, and add detailed comments to explain complex logic for easier maintenance.

6. Testing and Documentation

Implement thorough testing for the new functionality and refactoring. Ensure that the code is well-documented, with clear explanations of logic, method functionality, and expected behavior for future maintainability.

== Design ==

=== Design Principles ===

* Solid Principles: We adhered to SOLID principles (specifically Single Responsibility Principle) by ensuring each class has a single responsibility, extending functionality without modifying existing code, substituting derived classes seamlessly, segregating interfaces for specific client needs, and inverting dependencies to rely on abstractions.
* Don’t Repeat Yourself (DRY): Eliminate redundancy by creating general solutions that handle multiple scenarios.
* Visitor Pattern: Utilize this pattern to separate emailing functionality from the main FeedbackResponseMap class.

=== Implementation Plan ===

The refactoring will proceed as follows:

1. Implement Feedback Response Map Methods

* Design and implement methods that effectively handles all aspects of the feedback responses.
* Ensure seamless integration with related models, such as ResponseMap, for consistent and accurate feedback management.
* Methods should handle feedback collection, presentation, and reporting appropriately.

2. Refactor the feedback_response_report Method

* Remove the hardcoded logic for the rounds of reviews with a dynamic approach that is able to handle any number of rounds. This could be done using a loop or a grouping mechanism that can adapt to any number of review rounds.
* Replace redundancy with a generalized solution that dynamically adapts to varying rubrics without requiring manual intervention.
* Improve the data structure used by using more flexible and memory-efficient options to reduce memory usage and improve scalability.

3. Separate Email Functionality Using the Visitor Pattern

* Implement the Visitor Pattern to move email handling out of the FeedbackResponseMap class, ideally into a a separate service object.
* Ensure that the new email class follows SOLID principles, especially the Single Responsibility Principle (SRP).

4. Remove Redundant Code

* Review the class for redundant methods and comments.
* Remove any code that is not required for the feedback response management, such as unused helper methods or unnecessary variable assignments.
* Refactor code that repeats functionality found elsewhere in the system to avoid duplication.

=== Implementation ===

1. Implement Feedback Response Map Methods

The original feedback_response_map model used inconsistent naming, such as get_title, and retrieved data inefficiently. Additionally, the questionnaire method searched for a questionnaire type rather than using the ActiveRecord associations. The contributor method accessed the reviewee indirectly instead of using direct associations.

The refactored code addressed these issues by improving naming consistency, optimizing data retrieval, and simplifying method logic. To improve naming and align with Ruby naming conventions, get_title was changed to title. The questionnaire method now directly retrieves the assignment’s associated questionnaires using self.assignment.questionnaires, making the code more concise, and the contributor method now directly returns self.reviewee, eliminating unnecessary lookups. These changes improve readability by making method names more intuitive and increase efficiency by reducing redundant database queries and method calls. They also enhance maintainability by providing clearer method definitions, reducing confusion, and simplifying future modifications.

2. Refactor the feedback_response_report Method

The feedback_response_report method begins by fetching all authors (participants) associated with the assignment through the fetch_authors_for_assignment method. It then retrieves the review map IDs for the assignment using ReviewResponseMap.where, followed by fetching the corresponding responses using Response.where. These responses are ordered by their creation time in descending order to ensure that the most recent feedback is prioritized.

Next, the method checks if the assignment uses varying rubrics by round. If this is the case, it initializes a hash (latest_by_map_and_round) to store the latest response for each review map and round combination. The method iterates over the responses, using the combination of map_id and round as the key, and updates the hash with the latest response for each round. Afterward, the responses are grouped by round and sorted, resulting in a hash (sorted_by_round) where each round number maps to an array of response IDs.

In the case where rubrics do not vary by round, the method follows a simpler approach, storing only the latest response for each review map in the latest_by_map hash. It then returns the authors along with the IDs of the most recent responses for each review map.

Finally, the method returns an array: the first element contains the authors, and the second element contains the response IDs grouped by round if rubrics vary by round, or the latest response IDs if they do not. This structure allows for efficient and organized retrieval of feedback responses based on the assignment's rubric configuration.

3. Separate Email Functionality Using the Visitor Pattern

The Visitor pattern is a design pattern that allows new operations to be added to existing object structures without modifying the objects themselves. Using this pattern, the email method can interact with different parts of the system (responses, participants, etc.) without modifying those objects directly.

To separate the email functionality, we created the EmailVisitor class, which is implemented as a service class. It encapsulates the specific action of sending emails to users based on responses, participants, and assignments. By placing this logic in a service class, we ensure that the email functionality remains independent of the models, which helps keep the models focused on their core responsibilities.

The EmailVisitor class implements the Visitor pattern by interacting objects such as responses, response maps, participants, and users. It gathers the necessary data by storing relevant information in instance variables. The visitor then uses this data to construct and send an email, including details like the recipient’s name and the assignment’s information. The visitor pattern facilitates this interaction by allowing the EmailVisitor to operate on these objects without directly modifying them. Each model, such as response, response_map, participant, and user, has an accept method that takes the visitor as an argument and calls the appropriate method on the visitor, passing itself as a parameter. This enables the visitor to perform specific operations on each model without needing to know the internal details of the models. The visitor relies on the accept methods to trigger the correct operation. Additionally, this structure makes it easy to extend functionality, as new operations can be added to the visitor without altering the existing models, a key advantage of the Visitor pattern.

4. Remove Redundant Code and Improve Code Readability and Maintainability

The original code contains unnecessary variables (like @temp_response_map_ids) that tracked the maps in a roundabout way. It also used complicated loops and conditionals to filter responses, leading to logi that is hard to follow. There were also certain duplicated database queries, such as retrieving response maps multiple times.

The refactored code removed the redundant variables and replaced them with a streamlined data structure (latest_by_map_and_round). It removed deep nesting by using hash-based filtering instead of multiple conditionals and used concise ActiveRecord queries to fetch only the necessary records, reducing memory usage and execution time. The refactored code addressed the readability and maintainability issues of the original implementation by breaking down large methods into smaller, focused functions like fetch_authors_for_assignment. Hence, the refactored method is shorter, easier to understand, executes faster with less looping and redundant queries, and has a more straightforward logic for easier future modifications.

=== Testing ===

1. Adapt Existing Tests for Refactored Methods

* Any new helper methods will be private, and so by the "Magic Tricks of Testing" guide, should not be tested (both query and command messages sent to self are ignored in the test plan).
* Use mocks to isolate components during testing, especially for external dependencies like Mailer, to ensure that email functionality works as expected without direct integration.

2. Document Code for Clarity

* Write detailed comments explaining the purpose of each method, input and output, and any critical logic that might be complex for future developers to understand.
* Create or update documentation and diagrams to illustrate the newly designed structure, making it easier for new developers to contribute or modify functionality.

=== Files ===

The files that were added or modified to our repository are shown below.

==== Models ====

feedback_response_map.rb

Many comments were placed throughout the document in order to make code more readable.

==== Database ====

migrate/20250324184409_add_round_to_responses

==== Spec ====

feedback_response_map_spec.rb

=== Video ===

https://drive.google.com/drive/folders/1D47ABE413j1OWY1ad2Gv9mJEQ_YguKH7?usp=sharing

=== Pull Request ===

https://github.com/expertiza/reimplementation-back-end/pull/182

=== Conclusion ===

By refactoring feedback_response_map.rb, this project enhances Expertiza’s backend maintainability and readability, ensuring a modular, efficient, and more secure implementation.

== Team Information ==

=== Mentor ===

* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=== Members ===

* Riya Bihani (rbihani@ncsu.edu)

* Nayan Taori (ntaori@ncsu.edu)

* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025

2025-04-07T11:38:34Z

Ntaori:

* [[CSC/ECE 517 Spring 2025 - E2503. Refactor the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Spring 2025 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Spring 2025 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2502: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2518. Reimplement password resets (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2511. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2521. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2513. Reimplement sign_up_topic.rb as project_topic.rb]]
* [[CSC/ECE 517 Spring 2025 - E2506. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2025 - E2527. Mentor-meeting management: assignments with topics]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller]]
* [[CSC/ECE 517 Spring 2025 - E2539 Reimplement Student Task View (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2521 UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2524 Reimplement student review controller]]
* [[CSC/ECE 517 Spring 2025 - E2525 Reimplement review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2526 Reimplement Teams and Participant hierarchies]]
* [[CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2538 Reimplementing Questionnaire Page in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2534 UI for Assign Reviewers]]
* [[CSC/ECE 517 Spring 2025 - E2540 Integration of Assignment participant Frontend with participant controller Backend]]
* [[CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses]]
* [[CSC/ECE 517 Spring 2025 - E2542. Refactor review_bids_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2531 Refactor participants_controller.rb]]

CSC/ECE 517 Spring 2025

2025-04-07T11:38:17Z

Ntaori:

* [[CSC/ECE 517 Spring 2025 - E2503. Refactor the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Spring 2025 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Spring 2025 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2502: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2518. Reimplement password resets (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2511. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2521. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2513. Reimplement sign_up_topic.rb as project_topic.rb]]
* [[CSC/ECE 517 Spring 2025 - E2506. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2025 - E2527. Mentor-meeting management: assignments with topics]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller
* [[CSC/ECE 517 Spring 2025 - E2539 Reimplement Student Task View (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2521 UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2524 Reimplement student review controller]]
* [[CSC/ECE 517 Spring 2025 - E2525 Reimplement review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2526 Reimplement Teams and Participant hierarchies]]
* [[CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2538 Reimplementing Questionnaire Page in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2534 UI for Assign Reviewers]]
* [[CSC/ECE 517 Spring 2025 - E2540 Integration of Assignment participant Frontend with participant controller Backend]]
* [[CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses]]
* [[CSC/ECE 517 Spring 2025 - E2542. Refactor review_bids_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2531 Refactor participants_controller.rb]]

CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback response map.rb

2025-03-25T01:51:38Z

Ntaori:

This page contains the details of OSS project ''E2509: Reimplement feedback response map'' done for Expertiza in Spring 2025.

__TOC__

== Expertiza and Project Overview ==

=== Background ===

Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===

The aim of this project is to implement the feedback_response_map.rb file in the reimplementation-backend repository of Expertiza. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews.

There is room for improvement in the current system and refactoring the FeedbackResponseMap could enhance its efficiency and flexibility. This would allow for better management of feedback data and provide opportunities for optimizing the overall functionality of the review process.

=== Current Implementation ===

The current feedback_response_map.rb in the Expertiza repository has several methods including assignment, show_review, get_title, questionnaire, feedback_response_report, and email. The assignment method retrieves the assignment associated with the review, the show_review method returns the review's content as HTML or a message if no review exists, the get_title method returns a simple label and the questionnaire method retrieves the feedback questionnaire associated with the assignment. The feedback_response_report method compiles a report by querying multiple tables to gather reviewer information and responses, handling varying rubrics by round, specifically for three rounds of review. Finally, the email method sends feedback emails to reviewers.

However, there are a few problems in the model that need to be fixed -

* Violation of SOLID and DRY principles: The existing code leads to repetition and complexity, which violates the SOLID and DRY principles.
* Issues with the feedback_response_report methods: This method is complicated, handling only the first three rounds of reviews, which introduces redundancy. It also uses a hardcoded approach to varying rubrics across rounds, which should be generalized to support any number of rounds dynamically.
* Misplaced Responsibilities: The email method should not be placed in this class as it violates the Single Responsibility Principle (SRP). It would be better to create a separate class to handle this method.
* Memory Inefficiencies: The method currently consumes excessive memory by using multiple separate arrays for storing review data for different rounds.
* Code Readability and Efficiency: The code suffers from redundant methods, unclear variable names, and inefficient loops that contribute to poor readability and performance. By eliminating this, the code would become more readable, and maintainable.

=== Objectives & Requirements ===
1. Implement methods for the feedback_response_map model

Develop methods in feedback_response_map.rb to properly manage feedback responses and ensure seamless integration and functionality within the system.

2. Adhere to SOLID and DRY Principles

Follow best software design practices by ensuring the code is modular, maintainable, and reusable. Eliminate redundancy and ensure adherence to SOLID and DRY principles.

3. Refactor feedback_response_report Method

Change the feedback_response_report method to allow it to support a dynamic number of rounds and eliminate redundant logic for varying rubrics across rounds, which will improve efficiency.

4. Separate Email Functionality

Separate the email notification logic from the FeedbackResponseMap class using the Visitor Pattern, adhering to the Single Responsibility Principle and enhancing modularity and maintaining clear separation of concerns.

5. Remove Redundant Code and Improve Readability

Eliminate unnecessary methods that do not contribute to core functionality. Refactor long or unclear method names for better clarity, and add detailed comments to explain complex logic for easier maintenance.

6. Testing and Documentation

Implement thorough testing for the new functionality and refactoring. Ensure that the code is well-documented, with clear explanations of logic, method functionality, and expected behavior for future maintainability.

== Design ==

=== Design Principles ===

* Single Responsibility Principle (SRP): Each method and class should have a single, well-defined purpose.
* Don’t Repeat Yourself (DRY): Eliminate redundancy by creating general solutions that handle multiple scenarios.
* Ruby Readability Guidelines:
** Guideline: Variable names should be neither too short nor too long.
** Guideline: Names should not be redundant.
** Guideline: A method should do only one thing and do it well.
* Visitor Pattern: Utilize this pattern to separate emailing functionalities from the main class.
* Solid Principles: We adhered to SOLID principles by ensuring each class has a single responsibility, extending functionality without modifying existing code, substituting derived classes seamlessly, segregating interfaces for specific client needs, and inverting dependencies to rely on abstractions.

=== Implementation Plan ===

The refactoring will proceed as follows:

1. Implement Feedback Response Map Methods

* Design and implement methods that effectively handles all aspects of the feedback responses.
* Ensure seamless integration with related models, such as ResponseMap, for consistent and accurate feedback management.
* Methods should handle feedback collection, presentation, and reporting appropriately.

2. Refactor the feedback_response_report Method

* Remove the hardcoded logic for the rounds of reviews with a dynamic approach that is able to handle any number of rounds. This could be done using a loop or a grouping mechanism that can adapt to any number of review rounds.
* Replace redundancy with a generalized solution that dynamically adapts to varying rubrics without requiring manual intervention.
* Improve the data structure used by using more flexible and memory-efficient options to reduce memory usage and improve scalability.

3. Separate Email Functionality Using the Visitor Pattern

* Implement the Visitor Pattern to move email handling out of the FeedbackResponseMap class, ideally into a a separate service object.
* Ensure that the new email class follows SOLID principles, especially the Single Responsibility Principle (SRP).

4. Remove Redundant Code

* Review the class for redundant methods and comments.
* Remove any code that is not required for the feedback response management, such as unused helper methods or unnecessary variable assignments.
* Refactor code that repeats functionality found elsewhere in the system to avoid duplication.

5. Improve Code Readability and Maintainability

* Rename methods to be more descriptive and concise
* Add detailed comments above complex methods or logic blocks to explain their purpose and functionality. Ensure comments are concise but descriptive enough for future developers.

=== Implementation ===

1. Implement Feedback Response Map Methods

The original feedback_response_map model implements basic methods like assignment, show_review, get_title, questionnaire, and contributor to manage feedback responses and they mainly interact with the ResponseMap, Response, AssignmentParticipant, and Assignment models. This introduces some unnecessary redundancy and is not modular.
The refactored code eliminates this redundancy and consolidates the logic. For example, the title method replaces get_title, providing a clearer, simpler approach. The questionnaire, contributor, and other methods have been simplified and streamlined to make the code more readable, and function names are now more descriptive. The refactored code improves modularity, readability, and maintainability by simplifying method names, reducing interdependencies between models, and eliminating redundant calls.

2. Refactor the feedback_response_report Method

The original feedback_response_report method processes the feedback responses and returns authors and review response IDs for different rounds. It uses hard-coded round numbers (round_one, round_two, round_three), which causes redundancy in the code. The logic for fetching responses by round is complicated and inefficient, with duplicated code for handling varying rubrics. The refactored feedback_response_report method dynamically handles any number of rounds and removes hard-coded round handling. It uses a more generalized approach to group and sort the responses by round.

3. Separate Email Functionality Using the Visitor Pattern

The Visitor pattern is a design pattern that allows new operations to be added to existing object structures without modifying the objects themselves. Using this pattern, the email method can interact with different parts of the system (responses, participants, etc.) without modifying those objects directly.

To separate the email functionality, we created the EmailVisitor class, which is implemented as a service class. It encapsulates the specific action of sending emails to users based on responses, participants, and assignments. By placing this logic in a service class, we ensure that the email functionality remains independent of the models, which helps keep the models focused on their core responsibilities.

The EmailVisitor class implements the Visitor pattern by interacting with various objects such as responses, response maps, participants, and users. It gathers the necessary data by storing relevant information in instance variables. The visitor then uses this data to construct and send an email, personalizing it with details like the recipient’s name and the assignment’s information. The visitor pattern facilitates this interaction by allowing the EmailVisitor to operate on these objects without directly modifying them. Each model, such as response, response_map, participant, and user, has an accept method that takes the visitor as an argument and invokes the appropriate method on the visitor, passing itself as a parameter. This mechanism enables the visitor to perform specific operations on each model without needing to know the internal details of the models. The visitor simply relies on the accept methods to trigger the correct operation, enabling a flexible and decoupled interaction with multiple objects. Additionally, this structure makes it easy to extend functionality, as new operations can be added to the visitor without altering the existing models, a key advantage of the Visitor pattern.

4. Remove Redundant Code

5. Improve Code Readability and Maintainability

=== Testing ===

1. Adapt Existing Tests for Refactored Methods

* Any new helper methods will be private, and so by the "Magic Tricks of Testing" guide, should not be tested (both query and command messages sent to self are ignored in the test plan).
* Use mocks to isolate components during testing, especially for external dependencies like Mailer, to ensure that email functionality works as expected without direct integration.

2. Document Code for Clarity

* Write detailed comments explaining the purpose of each method, input and output, and any critical logic that might be complex for future developers to understand.
* Create or update documentation and diagrams to illustrate the newly designed structure, making it easier for new developers to contribute or modify functionality.

=== Documentation ===

Ensure all code is well-documented, with comments explaining purpose, inputs, outputs, and any complex logic. Maintain updated documentation for all modified and newly added classes and methods, allowing for ease of understanding and maintenance.

=== Files ===

The files that were added or modified to our repository are shown below.

==== Models ====

The following files were copied from the expertiza/expertiza repository:
* analytic/assignment_team_analytic.rb
* assignment_team.rb
* feedback_response_map.rb

Added assignment_team.rb and assignment_team_analytic.rb as the existing spec tests depended on those 2 files. No changes were made to these files other than commenting out include Scoring in assignment_team.rb

feedback_response_map.rb

Many comments were placed throughout the document in order to make code more readable.

The main changes were taking feedback_response_report method and scanning it, to find different functionalities that could be taken out of it and turned into the following private helper methods: get_feedback_authors, varying_rubrics_report, static_rubrics_report.

Additionally, the variable @temp_response_map_ids was changed into response_map_ids both inside and outside the helper methods that used this variable. The variable @temp_review_responses was not changed except for being called review_responses in the helper methods.

==== Database ====

migrate/20241203083135_add_missing_reponse_map_fields.rb

One class is added, called AddMissingResponseMapFields, with a change of adding columns to response_maps and type and calibrate_to.

db/schema.rb

The only things changed in this file were a version change, as well as the addition of a t.string of "type" and a t.integer of "calibrate_to".

==== Spec ====

factories.rb

This file was modified to use single quotation marks instead of double quotation marks to adhere to RuboCop.

factories/factories.rb

We populated the factory with necessary factories such as response, course, institution, and role, as well as fixing the factory formatting to function properly.

feedback_response_map.rb

The code was updated to adhere to RuboCop guidelines. Secondly, tests and parts of tests were commented out if they were reliant on functionality that was not yet implemented in reimplementation-back-end.

=== Pull Request ===

https://github.com/expertiza/reimplementation-back-end/pull/144

=== Conclusion ===

By refactoring feedback_response_map.rb, this project enhances Expertiza’s backend maintainability and readability, ensuring a modular, efficient, and more secure implementation.

== Team Information ==

=== Mentor ===

* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=== Members ===

* Riya Bihani (rbihani@ncsu.edu)

* Nayan Taori (ntaori@ncsu.edu)

* Chandrakant Koneti (ckoneti@ncsu.edu)

CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback response map.rb

2025-03-25T00:55:14Z

Ntaori: /* Design Principles */

CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback response map.rb

2025-03-23T18:01:19Z

Ntaori: /* Video */

This page contains the details of OSS project ''E2509: Reimplement feedback response map'' done for Expertiza in Spring 2025.

__TOC__

== Expertiza and Project Overview ==

=== Background ===

Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===

The goal of this project is to refactor the feedback_response_map.rb file from the Expertiza repository and integrate it into the reimplementation-back-end repository. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. Each ResponseMap links a reviewer (reviewer_id), reviewee (reviewee_id), and the reviewed item (reviewed_object_id). FeedbackResponseMap, a subclass of ResponseMap, represents the feedback provided by a reviewee on the feedback received for their submission.

This class has significant room for improvement, especially with respect to object-oriented principles. Refactoring feedback_response_map.rb will streamline functionality, enhance maintainability, and improve adherence to coding standards.

=== Current Implementation ===

The current feedback_response_map.rb in the Expertiza repository has several issues. It includes the following problems:

* Poor adherence to SOLID and DRY principles: The current code structure introduces unnecessary repetition and complexity.
* feedback_response_report Method Issues: This critical method is highly complex, relying on custom data structures and separate containers for each review round, resulting in a DRY violation.
* Improper Responsibility Assignment: The email method does not belong within this class and would benefit from refactoring out into a separate class using the Visitor pattern. This pattern is suggested to streamline functionality, though alternative design patterns may be considered if more suitable.
* Memory Inefficiencies: The method currently creates unnecessary memory through inefficient structures, including multiple separate arrays for different rounds of review, which could be simplified into a 2D array structure.
* Code Smells: The code has redundant methods, unclear variable names, inefficient loops, and overly long method names.

=== Objectives & Requirements ===
1. Refactor the feedback_response_report Method

* Address the DRY violation by consolidating the containers for review rounds.
* Generalize the code to handle both cases—when rubrics vary by round and when they do not—without duplicating code.
* Introduce efficient data structures, like a 2D array, to replace multiple arrays and reduce memory usage.

2. Separate Responsibilities Using Visitor Pattern (stretch goal)

* Extract the email method using the Visitor pattern to modularize email functionality. Alternatively, select a design pattern better suited to organizing this method if available. Note that the email method is not properly used in its current location and is better suited to the Response class rather than ResponseMap.

3. Eliminate Redundant Methods

* Remove methods that do not serve a clear purpose and improve method naming for clarity.
* Aim to address any redundant meta-review functionality, as indicated by the professor's preference to remove these from response_map.rb.

4. Refactor for Code Clarity and Efficiency

* Improve variable names, reduce unnecessary loops, and replace long method names with concise, intuitive alternatives.
* Ensure that each method has a single, clearly defined purpose, improving code readability.

5. Testing and Documentation

* Write comprehensive tests for all newly implemented and modified methods to ensure reliability.
* Add detailed comments to facilitate code maintenance and understanding for future developers.

== Design ==

=== Design Principles ===

* Single Responsibility Principle (SRP): Each method and class should have a single, well-defined purpose.
* Don’t Repeat Yourself (DRY): Eliminate redundancy by creating general solutions that handle multiple scenarios.
* Ruby Readability Guidelines (Week 9 Notes):
** Guideline: Variable names should be neither too short nor too long.
** Guideline: Names should not be redundant.
** Guideline: A method should do only one thing and do it well.
* Visitor Pattern: Utilize this pattern to separate emailing functionalities from the main class.

=== Implementation Plan ===

The refactoring will proceed as follows:

1. Analyze and Refactor Current Code Structure

* Review and understand the existing structure and dependencies within feedback_response_map.rb.
* Identify areas of redundancy, complexity, and inefficiency, particularly in feedback_response_report, to create a clear plan for refactoring.
* Try to reduce character count and improve readability with aliasing (this way we do not break any code that relies on being able to call specific methods).

2. Refactor the feedback_response_report Method

* Consolidate containers for each review round to address DRY violations. By using a single structure to store review data, we will eliminate hard-coded repetition.
* Generalize logic to accommodate both scenarios where rubrics vary by round and where they do not, without duplicating code paths.
* Replace inefficient structures, such as multiple arrays, with more flexible and memory-efficient options, like a 2D array or a hash, to reduce memory usage and improve scalability.

3. Introduce Helper Methods for Reusable Logic (for feedback_response_report)

* Extract frequently used or complex code blocks into helper methods, reducing the size of primary methods and enhancing reusability.
* Use helper methods for specific actions, like handling rounds or retrieving assignment data, to make the code cleaner and better organized.
* Emphasis on adhering to the guideline: A method should do only one thing and do it well.

4. Research Future Refactoring for email Method

* The email method is convoluted and the functionality should be refactored into a different class in the future.
* This is because this visitor pattern violation is present in many classes, and is beyond the scope of a one-class re-implementation.

5. Improve Variable Naming and Structure

* Replace ambiguous variable names with clearer alternatives that convey purpose, such as renaming @temp_review_responses and @temp_response_map_ids to more meaningful names.
* Simplify long method names to make the code more readable and approachable for new contributors.

=== Implementation ===

1. Analyze and Refactor Current Code Structure

Before refactoring, the FeedbackResponseMap class contains 6 methods, with the majority of the code in self.feedback_response_report:

[[File:FeedbackResponseMap_before.png |250px]]

We aim to change that by splitting up this method into three helper methods, as seen in the following:

[[File:FeedbackResponseMap_after.png |350px]]

To go into more detail, here is the code for the feedback_response_report method, and how we intend to split it up:

[[File:E2451_after_code1.png |600px]]

[[File:E2451_after_code2.png |600px]]

The red section of code will be self.get_feedback_authors, yellow will be self.varying_rubrics_report, and green will be self.static_rubrics_report. Each separated group will be its own method, and self.varying_rubrics_report and self.static_rubrics_report (the yellow and green methods) will be returned at the end of the new feedback_response_report.

2. Refactor the feedback_response_report Method

The following are the original arrays used to statically represent the review rounds.

[[File:E2451-OriginalArrayRounds.png]]

We can take these multiple arrays, and use dictionaries instead, where each round is called by its key value (integer value).

[[File:E2451-UpdatedArraysMain.png | 600px]]

The code found in the feedback_response_report method that use the arrays were moved to the two helper methods, seen as follows:

[[File:E2451-UpdatedArrays1.png | 600px]]

[[File:E2451-UpdatedArrays2.png | 600px]]

Additionally, Rubocop was used to analyze the code and adhere to proper Ruby Guidelines. The command below was used to search for any code smells that we missed.

rubocop app/models/feedback_response_map.rb

Originally, there were only three offenses, but this largely grew as we continued to refactor the code. All of the offenses can be seen below:

[[File:E2451-Rubocop1.png | 600px]]

[[File:E2451-Rubocop2.png | 600px]]

[[File:E2451-Rubocop3.png | 600px]]

[[File:E2451-Rubocop4.png | 600px]]

All of these offenses were fixed. The following three offenses were the original ones. For the first and third offenses, the colon after the method headers were simply removed. For the second offense, the “return” keyword caused errors, thus, it was removed, because a ruby method will return its last statement. The two other private methods containing “return” also had that keyword removed.

[[File:E2451-RubocopOriginal.png | 600px]]

Lastly, commenting was added throughout the files, to improve readability.

3. Introduce Helper Methods for Reusable Logic (for feedback_response_report)

As planned in step 1, the feedback_response_report method was split up into 3 private helper methods: get_feedback_authors(id), varying_rubrics_report(review_responses, response_map_ids), and static_rubrics_report(review_responses, response_map_ids). One change we made that was different from the UML diagram was the addition of an id parameter in the get_feedback_authors method, in order to access id, since it was a parameter given to feedback_response_report. Each helper method was planned in order to stick to the guideline of “A method should do only one thing and do it well.”

Final UML for FeedbackResponseMap

[[File:E2451_FeedbackResponseMap_final.drawio.png | 600px]]

Authors

This image contains comments showing what the implementation looked like before:

[[File:E2451_authors_before_1.png]]

This image shows the construction of the private method we implemented to replace it, reducing complexity and improving readability in the process:

[[File:E2451_authors_after_1.png]]

Report

This image contains comments showing what the implementation looked like before (this image is out of date, the return functionality for the varying rubric report rounds has since been generalized, please see the repo for the updated version) (The updated version does not include the old version comments, which is why this screenshot is used):

[[File:E2451_reports_before_1.png]]

These images show the construction of the private methods we implemented to replace it, reducing complexity and improving readability in the process:

[[File:E2451_reports_varying_1.png]]

[[File:E2451_report_static_1.png]]

Notice that in both the original self.feedback_response_report method and the private methods, comments are included to explain each non-obvious step of the process.

Complexity changes

Previously, Rubocop reported the following failures on behalf of the self.feedback_response_report method:

Metrics/PerceivedComplexity: Perceived complexity for feedback_response_report is too high. [14/8]
Metrics/CyclomaticComplexity: Cyclomatic complexity for feedback_response_report is too high. [12/7]
Metrics/AbcSize: Assignment Branch Condition size for feedback_response_report is too high. [<14, 46, 16> 50.68/20]

Now, neither self.feedback_response_report nor any of its associated private methods trigger any of these Metric violations!
(Note that the email method does trigger a AbcSize violation when the protective comments are removed, but adjusting that method is beyond the scope of this project for reasons listed in the Implementation Plan)

4. Research Future Refactoring for email Method

As discussed in the implementation plan, the email method was left as is. Any changes would require the addition of a new class and/or major refactoring for the functionality.

5. Improve Variable Naming and Structure

The two sets of variables discussed in the plan, @temp_response_map_ids and @temp_review_responses were modified as needed. First, the @temp_response_map_ids was moved to the helper methods varying_rubrics_report and static_rubrics_report, to be initialized, and changed to response_map_ids.

Secondly, @temp_review_responses was changed to review_responses in the helper methods that call it: varying_rubrics_report and static_rubrics_report

=== Testing ===

1. Adapt Existing Tests for Refactored Methods

* Any new helper methods will be private, and so by the "Magic Tricks of Testing" guide, should not be tested (both query and command messages sent to self are ignored in the test plan).
* Use mocks to isolate components during testing, especially for external dependencies like Mailer, to ensure that email functionality works as expected without direct integration.

2. Document Code for Clarity

* Write detailed comments explaining the purpose of each method, input and output, and any critical logic that might be complex for future developers to understand.
* Create or update documentation and diagrams to illustrate the newly designed structure, making it easier for new developers to contribute or modify functionality.

=== Documentation ===

Ensure all code is well-documented, with comments explaining purpose, inputs, outputs, and any complex logic. Maintain updated documentation for all modified and newly added classes and methods, allowing for ease of understanding and maintenance.

=== Files ===

The files that were added or modified to our repository are shown below.

==== Models ====

The following files were copied from the expertiza/expertiza repository:
* analytic/assignment_team_analytic.rb
* assignment_team.rb
* feedback_response_map.rb

Added assignment_team.rb and assignment_team_analytic.rb as the existing spec tests depended on those 2 files. No changes were made to these files other than commenting out include Scoring in assignment_team.rb

feedback_response_map.rb

Many comments were placed throughout the document in order to make code more readable.

The main changes were taking feedback_response_report method and scanning it, to find different functionalities that could be taken out of it and turned into the following private helper methods: get_feedback_authors, varying_rubrics_report, static_rubrics_report.

Additionally, the variable @temp_response_map_ids was changed into response_map_ids both inside and outside the helper methods that used this variable. The variable @temp_review_responses was not changed except for being called review_responses in the helper methods.

==== Database ====

migrate/20241203083135_add_missing_reponse_map_fields.rb

One class is added, called AddMissingResponseMapFields, with a change of adding columns to response_maps and type and calibrate_to.

db/schema.rb

The only things changed in this file were a version change, as well as the addition of a t.string of "type" and a t.integer of "calibrate_to".

==== Spec ====

factories.rb

This file was modified to use single quotation marks instead of double quotation marks to adhere to RuboCop.

factories/factories.rb

We populated the factory with necessary factories such as response, course, institution, and role, as well as fixing the factory formatting to function properly.

feedback_response_map.rb

The code was updated to adhere to RuboCop guidelines. Secondly, tests and parts of tests were commented out if they were reliant on functionality that was not yet implemented in reimplementation-back-end.

=== Pull Request ===

https://github.com/expertiza/reimplementation-back-end/pull/144

=== Conclusion ===

By refactoring feedback_response_map.rb, this project enhances Expertiza’s backend maintainability and readability, ensuring a modular, efficient, and more secure implementation.

== Team Information ==

=== Mentor ===

* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=== Members ===

* Riya Bihani (rbihani@ncsu.edu)

* Nayan Taori (ntaori@ncsu.edu)

* Chandrakant Koneti (ckoneti@ncsu.edu)

* ChatGPT (Honorary Member)

CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback response map.rb

2025-03-23T17:59:34Z

Ntaori: Created page with "This page contains the details of OSS project ''E2509: Reimplement feedback response map'' done for Expertiza in Spring 2025. __TOC__ == Expertiza and Project Overview == === Background === Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mi..."

This page contains the details of OSS project ''E2509: Reimplement feedback response map'' done for Expertiza in Spring 2025.

__TOC__

== Expertiza and Project Overview ==

=== Background ===

Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

=== Project Overview ===

The goal of this project is to refactor the feedback_response_map.rb file from the Expertiza repository and integrate it into the reimplementation-back-end repository. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. Each ResponseMap links a reviewer (reviewer_id), reviewee (reviewee_id), and the reviewed item (reviewed_object_id). FeedbackResponseMap, a subclass of ResponseMap, represents the feedback provided by a reviewee on the feedback received for their submission.

This class has significant room for improvement, especially with respect to object-oriented principles. Refactoring feedback_response_map.rb will streamline functionality, enhance maintainability, and improve adherence to coding standards.

=== Current Implementation ===

The current feedback_response_map.rb in the Expertiza repository has several issues. It includes the following problems:

* Poor adherence to SOLID and DRY principles: The current code structure introduces unnecessary repetition and complexity.
* feedback_response_report Method Issues: This critical method is highly complex, relying on custom data structures and separate containers for each review round, resulting in a DRY violation.
* Improper Responsibility Assignment: The email method does not belong within this class and would benefit from refactoring out into a separate class using the Visitor pattern. This pattern is suggested to streamline functionality, though alternative design patterns may be considered if more suitable.
* Memory Inefficiencies: The method currently creates unnecessary memory through inefficient structures, including multiple separate arrays for different rounds of review, which could be simplified into a 2D array structure.
* Code Smells: The code has redundant methods, unclear variable names, inefficient loops, and overly long method names.

=== Objectives & Requirements ===
1. Refactor the feedback_response_report Method

* Address the DRY violation by consolidating the containers for review rounds.
* Generalize the code to handle both cases—when rubrics vary by round and when they do not—without duplicating code.
* Introduce efficient data structures, like a 2D array, to replace multiple arrays and reduce memory usage.

2. Separate Responsibilities Using Visitor Pattern (stretch goal)

* Extract the email method using the Visitor pattern to modularize email functionality. Alternatively, select a design pattern better suited to organizing this method if available. Note that the email method is not properly used in its current location and is better suited to the Response class rather than ResponseMap.

3. Eliminate Redundant Methods

* Remove methods that do not serve a clear purpose and improve method naming for clarity.
* Aim to address any redundant meta-review functionality, as indicated by the professor's preference to remove these from response_map.rb.

4. Refactor for Code Clarity and Efficiency

* Improve variable names, reduce unnecessary loops, and replace long method names with concise, intuitive alternatives.
* Ensure that each method has a single, clearly defined purpose, improving code readability.

5. Testing and Documentation

* Write comprehensive tests for all newly implemented and modified methods to ensure reliability.
* Add detailed comments to facilitate code maintenance and understanding for future developers.

== Design ==

=== Design Principles ===

* Single Responsibility Principle (SRP): Each method and class should have a single, well-defined purpose.
* Don’t Repeat Yourself (DRY): Eliminate redundancy by creating general solutions that handle multiple scenarios.
* Ruby Readability Guidelines (Week 9 Notes):
** Guideline: Variable names should be neither too short nor too long.
** Guideline: Names should not be redundant.
** Guideline: A method should do only one thing and do it well.
* Visitor Pattern: Utilize this pattern to separate emailing functionalities from the main class.

=== Implementation Plan ===

The refactoring will proceed as follows:

1. Analyze and Refactor Current Code Structure

* Review and understand the existing structure and dependencies within feedback_response_map.rb.
* Identify areas of redundancy, complexity, and inefficiency, particularly in feedback_response_report, to create a clear plan for refactoring.
* Try to reduce character count and improve readability with aliasing (this way we do not break any code that relies on being able to call specific methods).

2. Refactor the feedback_response_report Method

* Consolidate containers for each review round to address DRY violations. By using a single structure to store review data, we will eliminate hard-coded repetition.
* Generalize logic to accommodate both scenarios where rubrics vary by round and where they do not, without duplicating code paths.
* Replace inefficient structures, such as multiple arrays, with more flexible and memory-efficient options, like a 2D array or a hash, to reduce memory usage and improve scalability.

3. Introduce Helper Methods for Reusable Logic (for feedback_response_report)

* Extract frequently used or complex code blocks into helper methods, reducing the size of primary methods and enhancing reusability.
* Use helper methods for specific actions, like handling rounds or retrieving assignment data, to make the code cleaner and better organized.
* Emphasis on adhering to the guideline: A method should do only one thing and do it well.

4. Research Future Refactoring for email Method

* The email method is convoluted and the functionality should be refactored into a different class in the future.
* This is because this visitor pattern violation is present in many classes, and is beyond the scope of a one-class re-implementation.

5. Improve Variable Naming and Structure

* Replace ambiguous variable names with clearer alternatives that convey purpose, such as renaming @temp_review_responses and @temp_response_map_ids to more meaningful names.
* Simplify long method names to make the code more readable and approachable for new contributors.

=== Implementation ===

1. Analyze and Refactor Current Code Structure

Before refactoring, the FeedbackResponseMap class contains 6 methods, with the majority of the code in self.feedback_response_report:

[[File:FeedbackResponseMap_before.png |250px]]

We aim to change that by splitting up this method into three helper methods, as seen in the following:

[[File:FeedbackResponseMap_after.png |350px]]

To go into more detail, here is the code for the feedback_response_report method, and how we intend to split it up:

[[File:E2451_after_code1.png |600px]]

[[File:E2451_after_code2.png |600px]]

The red section of code will be self.get_feedback_authors, yellow will be self.varying_rubrics_report, and green will be self.static_rubrics_report. Each separated group will be its own method, and self.varying_rubrics_report and self.static_rubrics_report (the yellow and green methods) will be returned at the end of the new feedback_response_report.

2. Refactor the feedback_response_report Method

The following are the original arrays used to statically represent the review rounds.

[[File:E2451-OriginalArrayRounds.png]]

We can take these multiple arrays, and use dictionaries instead, where each round is called by its key value (integer value).

[[File:E2451-UpdatedArraysMain.png | 600px]]

The code found in the feedback_response_report method that use the arrays were moved to the two helper methods, seen as follows:

[[File:E2451-UpdatedArrays1.png | 600px]]

[[File:E2451-UpdatedArrays2.png | 600px]]

Additionally, Rubocop was used to analyze the code and adhere to proper Ruby Guidelines. The command below was used to search for any code smells that we missed.

rubocop app/models/feedback_response_map.rb

Originally, there were only three offenses, but this largely grew as we continued to refactor the code. All of the offenses can be seen below:

[[File:E2451-Rubocop1.png | 600px]]

[[File:E2451-Rubocop2.png | 600px]]

[[File:E2451-Rubocop3.png | 600px]]

[[File:E2451-Rubocop4.png | 600px]]

All of these offenses were fixed. The following three offenses were the original ones. For the first and third offenses, the colon after the method headers were simply removed. For the second offense, the “return” keyword caused errors, thus, it was removed, because a ruby method will return its last statement. The two other private methods containing “return” also had that keyword removed.

[[File:E2451-RubocopOriginal.png | 600px]]

Lastly, commenting was added throughout the files, to improve readability.

3. Introduce Helper Methods for Reusable Logic (for feedback_response_report)

As planned in step 1, the feedback_response_report method was split up into 3 private helper methods: get_feedback_authors(id), varying_rubrics_report(review_responses, response_map_ids), and static_rubrics_report(review_responses, response_map_ids). One change we made that was different from the UML diagram was the addition of an id parameter in the get_feedback_authors method, in order to access id, since it was a parameter given to feedback_response_report. Each helper method was planned in order to stick to the guideline of “A method should do only one thing and do it well.”

Final UML for FeedbackResponseMap

[[File:E2451_FeedbackResponseMap_final.drawio.png | 600px]]

Authors

This image contains comments showing what the implementation looked like before:

[[File:E2451_authors_before_1.png]]

This image shows the construction of the private method we implemented to replace it, reducing complexity and improving readability in the process:

[[File:E2451_authors_after_1.png]]

Report

This image contains comments showing what the implementation looked like before (this image is out of date, the return functionality for the varying rubric report rounds has since been generalized, please see the repo for the updated version) (The updated version does not include the old version comments, which is why this screenshot is used):

[[File:E2451_reports_before_1.png]]

These images show the construction of the private methods we implemented to replace it, reducing complexity and improving readability in the process:

[[File:E2451_reports_varying_1.png]]

[[File:E2451_report_static_1.png]]

Notice that in both the original self.feedback_response_report method and the private methods, comments are included to explain each non-obvious step of the process.

Complexity changes

Previously, Rubocop reported the following failures on behalf of the self.feedback_response_report method:

Metrics/PerceivedComplexity: Perceived complexity for feedback_response_report is too high. [14/8]
Metrics/CyclomaticComplexity: Cyclomatic complexity for feedback_response_report is too high. [12/7]
Metrics/AbcSize: Assignment Branch Condition size for feedback_response_report is too high. [<14, 46, 16> 50.68/20]

Now, neither self.feedback_response_report nor any of its associated private methods trigger any of these Metric violations!
(Note that the email method does trigger a AbcSize violation when the protective comments are removed, but adjusting that method is beyond the scope of this project for reasons listed in the Implementation Plan)

4. Research Future Refactoring for email Method

As discussed in the implementation plan, the email method was left as is. Any changes would require the addition of a new class and/or major refactoring for the functionality.

5. Improve Variable Naming and Structure

The two sets of variables discussed in the plan, @temp_response_map_ids and @temp_review_responses were modified as needed. First, the @temp_response_map_ids was moved to the helper methods varying_rubrics_report and static_rubrics_report, to be initialized, and changed to response_map_ids.

Secondly, @temp_review_responses was changed to review_responses in the helper methods that call it: varying_rubrics_report and static_rubrics_report

=== Testing ===

1. Adapt Existing Tests for Refactored Methods

* Any new helper methods will be private, and so by the "Magic Tricks of Testing" guide, should not be tested (both query and command messages sent to self are ignored in the test plan).
* Use mocks to isolate components during testing, especially for external dependencies like Mailer, to ensure that email functionality works as expected without direct integration.

2. Document Code for Clarity

* Write detailed comments explaining the purpose of each method, input and output, and any critical logic that might be complex for future developers to understand.
* Create or update documentation and diagrams to illustrate the newly designed structure, making it easier for new developers to contribute or modify functionality.

=== Documentation ===

Ensure all code is well-documented, with comments explaining purpose, inputs, outputs, and any complex logic. Maintain updated documentation for all modified and newly added classes and methods, allowing for ease of understanding and maintenance.

=== Files ===

The files that were added or modified to our repository are shown below.

==== Models ====

The following files were copied from the expertiza/expertiza repository:
* analytic/assignment_team_analytic.rb
* assignment_team.rb
* feedback_response_map.rb

Added assignment_team.rb and assignment_team_analytic.rb as the existing spec tests depended on those 2 files. No changes were made to these files other than commenting out include Scoring in assignment_team.rb

feedback_response_map.rb

Many comments were placed throughout the document in order to make code more readable.

The main changes were taking feedback_response_report method and scanning it, to find different functionalities that could be taken out of it and turned into the following private helper methods: get_feedback_authors, varying_rubrics_report, static_rubrics_report.

Additionally, the variable @temp_response_map_ids was changed into response_map_ids both inside and outside the helper methods that used this variable. The variable @temp_review_responses was not changed except for being called review_responses in the helper methods.

==== Database ====

migrate/20241203083135_add_missing_reponse_map_fields.rb

One class is added, called AddMissingResponseMapFields, with a change of adding columns to response_maps and type and calibrate_to.

db/schema.rb

The only things changed in this file were a version change, as well as the addition of a t.string of "type" and a t.integer of "calibrate_to".

==== Spec ====

factories.rb

This file was modified to use single quotation marks instead of double quotation marks to adhere to RuboCop.

factories/factories.rb

We populated the factory with necessary factories such as response, course, institution, and role, as well as fixing the factory formatting to function properly.

feedback_response_map.rb

The code was updated to adhere to RuboCop guidelines. Secondly, tests and parts of tests were commented out if they were reliant on functionality that was not yet implemented in reimplementation-back-end.

=== Video ===

https://youtu.be/SbmDoJNm4Q4

=== Pull Request ===

https://github.com/expertiza/reimplementation-back-end/pull/144

=== Conclusion ===

By refactoring feedback_response_map.rb, this project enhances Expertiza’s backend maintainability and readability, ensuring a modular, efficient, and more secure implementation.

== Team Information ==

=== Mentor ===

* Aniruddha Rajnekar (aarajnek@ncsu.edu)

=== Members ===

* Riya Bihani (rbihani@ncsu.edu)

* Nayan Taori (ntaori@ncsu.edu)

* Chandrakant Koneti (ckoneti@ncsu.edu)

* ChatGPT (Honorary Member)

CSC/ECE 517 Spring 2025

2025-03-23T17:56:01Z

Ntaori: Adding the topic of implementation Reimplement feedback_response_map.rb

* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Fall 2024 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]