Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-25T01:41:59Z

Aitha: /* Screencast */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. The method self.final_versions_from_reviewer in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. We removed the "latest_feedback" method from the feedback_response_map.rb. Modified the methods "self.feedback_response_report_by_round(" of the "feedback_response_map.rb" and "self.review_response_report" of the "review_response_map.rb". The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

2. For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

[[File:E2338_visitor_sample_1.png | 1000px]]

[[File:E2338_visitor_sample_2.png | 1000px]]

[[File:E2338_visitor_sample_3.png | 1000px]]

[[File:E2338_visitor_sample_4.png | 1000px]]

3. A more flexible and extensible codebase is made possible by polymorphism, which enables objects of several classes to be viewed as belonging to the same class. This implies that, depending on their own implementation, objects of different classes may reply to the same message or method in various ways. For instance, a "Vehicle" superclass can have subclasses like "Car," "Bus," and "Truck," each having its own implementation of the "drive()" method. Despite the fact that each of these subclasses may drive differently in this situation, polymorphism enables the identical 'drive()' function to be used on any of them. An application's maintainability and flexibility are improved by polymorphism, which also helps to reduce code duplication and create reusable code.

Just as in the above example, there is a common method named "title" in all the subclasses of response_map.rb. We implemented polymorphism and defined the method in the base class.

[[File:E2338_polymorphism_sample_1.png | 1000px]]

4. There are many methods that are not used and defined in the response_map.rb. We removed some of the methods that are not used by any other child classes.

[[File:E2338_method_removal_sample_1.png | 1000px]]

5. When a class is extended, it creates a tightly coupled relationship between the parent and child class, which can make it difficult to modify the behavior of the child class independently. In contrast, when a class is included, it creates a looser coupling and allows the child class to access the methods and attributes of the parent class without being tied to its implementation. This approach provides greater flexibility and makes it easier to modify the behavior of the child class without affecting the parent class. Additionally, including a class allows for multiple inheritances, where a class can inherit from multiple parent classes, providing even more flexibility and code reuse.

"Scoring" class is extended by the "response_map.rb". Changes are made to "include" this class rather than extending it.

==Testing==

===Test Plan===

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

The following is a small code snippet added for the review_response_map.rb

[[File:E2314_test_review_sample_1.png | 1000px]]

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

The following is a small code snippet added for the teammate_response_map.rb and the email functionality.

[[File:E2314_test_teammate_sample_1.png | 1000px]]

[[File:E2314_test_email_teammate_sample_1.png | 1000px]]

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

The following is a small code snippet for the response_map.rb

[[File:E2314_test_response_sample_1.png | 1000px]]

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

The following is a small code snippet from the feedback_response_map.rb

[[File:E2314_test_feedback_sample_1.png | 1000px]]

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

The Iterator design pattern is a behavioral pattern that offers a mechanism to access an aggregate object's elements progressively without disclosing the implementation's inner workings. The pattern specifies a distinct object called an iterator that contains the iteration logic and offers a consistent interface for navigating the aggregate's elements. The Iterator pattern encourages loose coupling between the two by separating the traversal logic from the aggregate object, making it simpler to alter the implementation of one without impacting the other. When we need to traverse a collection of items in a specified order but don't want to reveal the collection's internal workings to the client code, we can use this pattern.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==
https://www.youtube.com/watch?v=nWO_WLE4ClA

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-25T00:29:44Z

Aitha: /* Our Solution */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. The method self.final_versions_from_reviewer in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. We removed the "latest_feedback" method from the feedback_response_map.rb. Modified the methods "self.feedback_response_report_by_round(" of the "feedback_response_map.rb" and "self.review_response_report" of the "review_response_map.rb". The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

2. For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

[[File:E2338_visitor_sample_1.png | 1000px]]

[[File:E2338_visitor_sample_2.png | 1000px]]

[[File:E2338_visitor_sample_3.png | 1000px]]

[[File:E2338_visitor_sample_4.png | 1000px]]

3. A more flexible and extensible codebase is made possible by polymorphism, which enables objects of several classes to be viewed as belonging to the same class. This implies that, depending on their own implementation, objects of different classes may reply to the same message or method in various ways. For instance, a "Vehicle" superclass can have subclasses like "Car," "Bus," and "Truck," each having its own implementation of the "drive()" method. Despite the fact that each of these subclasses may drive differently in this situation, polymorphism enables the identical 'drive()' function to be used on any of them. An application's maintainability and flexibility are improved by polymorphism, which also helps to reduce code duplication and create reusable code.

Just as in the above example, there is a common method named "title" in all the subclasses of response_map.rb. We implemented polymorphism and defined the method in the base class.

[[File:E2338_polymorphism_sample_1.png | 1000px]]

4. There are many methods that are not used and defined in the response_map.rb. We removed some of the methods that are not used by any other child classes.

[[File:E2338_method_removal_sample_1.png | 1000px]]

5. When a class is extended, it creates a tightly coupled relationship between the parent and child class, which can make it difficult to modify the behavior of the child class independently. In contrast, when a class is included, it creates a looser coupling and allows the child class to access the methods and attributes of the parent class without being tied to its implementation. This approach provides greater flexibility and makes it easier to modify the behavior of the child class without affecting the parent class. Additionally, including a class allows for multiple inheritances, where a class can inherit from multiple parent classes, providing even more flexibility and code reuse.

"Scoring" class is extended by the "response_map.rb". Changes are made to "include" this class rather than extending it.

==Testing==

===Test Plan===

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

The following is a small code snippet added for the review_response_map.rb

[[File:E2314_test_review_sample_1.png | 1000px]]

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

The following is a small code snippet added for the teammate_response_map.rb and the email functionality.

[[File:E2314_test_teammate_sample_1.png | 1000px]]

[[File:E2314_test_email_teammate_sample_1.png | 1000px]]

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

The following is a small code snippet for the response_map.rb

[[File:E2314_test_response_sample_1.png | 1000px]]

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

The following is a small code snippet from the feedback_response_map.rb

[[File:E2314_test_feedback_sample_1.png | 1000px]]

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

The Iterator design pattern is a behavioral pattern that offers a mechanism to access an aggregate object's elements progressively without disclosing the implementation's inner workings. The pattern specifies a distinct object called an iterator that contains the iteration logic and offers a consistent interface for navigating the aggregate's elements. The Iterator pattern encourages loose coupling between the two by separating the traversal logic from the aggregate object, making it simpler to alter the implementation of one without impacting the other. When we need to traverse a collection of items in a specified order but don't want to reveal the collection's internal workings to the client code, we can use this pattern.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-25T00:29:13Z

Aitha: /* Test Plan */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. The method self.final_versions_from_reviewer in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. We removed the "latest_feedback" method from the feedback_response_map.rb. Modified the methods "self.feedback_response_report_by_round(" of the "feedback_response_map.rb" and "self.review_response_report" of the "review_response_map.rb". The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

2. For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

[[File:E2338_visitor_sample_1.png]]

[[File:E2338_visitor_sample_2.png]]

[[File:E2338_visitor_sample_3.png]]

[[File:E2338_visitor_sample_4.png]]

3. A more flexible and extensible codebase is made possible by polymorphism, which enables objects of several classes to be viewed as belonging to the same class. This implies that, depending on their own implementation, objects of different classes may reply to the same message or method in various ways. For instance, a "Vehicle" superclass can have subclasses like "Car," "Bus," and "Truck," each having its own implementation of the "drive()" method. Despite the fact that each of these subclasses may drive differently in this situation, polymorphism enables the identical 'drive()' function to be used on any of them. An application's maintainability and flexibility are improved by polymorphism, which also helps to reduce code duplication and create reusable code.

Just as in the above example, there is a common method named "title" in all the subclasses of response_map.rb. We implemented polymorphism and defined the method in the base class.

[[File:E2338_polymorphism_sample_1.png | 1000px]]

4. There are many methods that are not used and defined in the response_map.rb. We removed some of the methods that are not used by any other child classes.

[[File:E2338_method_removal_sample_1.png | 1000px]]

5. When a class is extended, it creates a tightly coupled relationship between the parent and child class, which can make it difficult to modify the behavior of the child class independently. In contrast, when a class is included, it creates a looser coupling and allows the child class to access the methods and attributes of the parent class without being tied to its implementation. This approach provides greater flexibility and makes it easier to modify the behavior of the child class without affecting the parent class. Additionally, including a class allows for multiple inheritances, where a class can inherit from multiple parent classes, providing even more flexibility and code reuse.

"Scoring" class is extended by the "response_map.rb". Changes are made to "include" this class rather than extending it.

==Testing==

===Test Plan===

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

The following is a small code snippet added for the review_response_map.rb

[[File:E2314_test_review_sample_1.png | 1000px]]

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

The following is a small code snippet added for the teammate_response_map.rb and the email functionality.

[[File:E2314_test_teammate_sample_1.png | 1000px]]

[[File:E2314_test_email_teammate_sample_1.png | 1000px]]

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

The following is a small code snippet for the response_map.rb

[[File:E2314_test_response_sample_1.png | 1000px]]

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

The following is a small code snippet from the feedback_response_map.rb

[[File:E2314_test_feedback_sample_1.png | 1000px]]

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

The Iterator design pattern is a behavioral pattern that offers a mechanism to access an aggregate object's elements progressively without disclosing the implementation's inner workings. The pattern specifies a distinct object called an iterator that contains the iteration logic and offers a consistent interface for navigating the aggregate's elements. The Iterator pattern encourages loose coupling between the two by separating the traversal logic from the aggregate object, making it simpler to alter the implementation of one without impacting the other. When we need to traverse a collection of items in a specified order but don't want to reveal the collection's internal workings to the client code, we can use this pattern.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

File:E2314 test email teammate sample 1.png

2023-04-25T00:28:01Z

Aitha: test for email functionality of teammate_response.rb

test for email functionality of teammate_response.rb

File:E2314 test response sample 1.png

2023-04-25T00:25:48Z

Aitha: tests for response_map.rb

tests for response_map.rb

File:E2314 test review sample 1.png

2023-04-25T00:24:29Z

Aitha: tests for review_response_map.rb

tests for review_response_map.rb

File:E2314 test teammate sample 1.png

2023-04-25T00:22:00Z

Aitha: test for teammate_response_map.rb

test for teammate_response_map.rb

File:E2314 test feedback sample 1.png

2023-04-25T00:19:59Z

Aitha: test sample for feedback_response_map.rb

test sample for feedback_response_map.rb

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T17:05:39Z

Aitha:

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. The method self.final_versions_from_reviewer in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. We removed the "latest_feedback" method from the feedback_response_map.rb. Modified the methods "self.feedback_response_report_by_round(" of the "feedback_response_map.rb" and "self.review_response_report" of the "review_response_map.rb". The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

2. For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

3. A more flexible and extensible codebase is made possible by polymorphism, which enables objects of several classes to be viewed as belonging to the same class. This implies that, depending on their own implementation, objects of different classes may reply to the same message or method in various ways. For instance, a "Vehicle" superclass can have subclasses like "Car," "Bus," and "Truck," each having its own implementation of the "drive()" method. Despite the fact that each of these subclasses may drive differently in this situation, polymorphism enables the identical 'drive()' function to be used on any of them. An application's maintainability and flexibility are improved by polymorphism, which also helps to reduce code duplication and create reusable code.

Just as in the above example, there is a common method named "title" in all the subclasses of response_map.rb. We implemented polymorphism and defined the method in the base class.

[[File:E2338_polymorphism_sample_1.png | 1000px]]

4. There are many methods that are not used and defined in the response_map.rb. We removed some of the methods that are not used by any other child classes.

[[File:E2338_method_removal_sample_1.png | 1000px]]

5. When a class is extended, it creates a tightly coupled relationship between the parent and child class, which can make it difficult to modify the behavior of the child class independently. In contrast, when a class is included, it creates a looser coupling and allows the child class to access the methods and attributes of the parent class without being tied to its implementation. This approach provides greater flexibility and makes it easier to modify the behavior of the child class without affecting the parent class. Additionally, including a class allows for multiple inheritances, where a class can inherit from multiple parent classes, providing even more flexibility and code reuse.

"Scoring" class is extended by the "response_map.rb". Changes are made to "include" this class rather than extending it.

==Testing==

===Test Plan===

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

The Iterator design pattern is a behavioral pattern that offers a mechanism to access an aggregate object's elements progressively without disclosing the implementation's inner workings. The pattern specifies a distinct object called an iterator that contains the iteration logic and offers a consistent interface for navigating the aggregate's elements. The Iterator pattern encourages loose coupling between the two by separating the traversal logic from the aggregate object, making it simpler to alter the implementation of one without impacting the other. When we need to traverse a collection of items in a specified order but don't want to reveal the collection's internal workings to the client code, we can use this pattern.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T17:02:13Z

Aitha: /* Design Patterns Used */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. The method self.final_versions_from_reviewer in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. We removed the "latest_feedback" method from the feedback_response_map.rb. Modified the methods "self.feedback_response_report_by_round(" of the "feedback_response_map.rb" and "self.review_response_report" of the "review_response_map.rb". The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

2. For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

3. A more flexible and extensible codebase is made possible by polymorphism, which enables objects of several classes to be viewed as belonging to the same class. This implies that, depending on their own implementation, objects of different classes may reply to the same message or method in various ways. For instance, a "Vehicle" superclass can have subclasses like "Car," "Bus," and "Truck," each having its own implementation of the "drive()" method. Despite the fact that each of these subclasses may drive differently in this situation, polymorphism enables the identical 'drive()' function to be used on any of them. An application's maintainability and flexibility are improved by polymorphism, which also helps to reduce code duplication and create reusable code.

Just as in the above example, there is a common method named "title" in all the subclasses of response_map.rb. We implemented polymorphism and defined the method in the base class.

[[File:E2338_polymorphism_sample_1.png | 1000px]]

4. There are many methods that are not used and defined in the response_map.rb. We removed some of the methods that are not used by any other child classes.

[[File:E2338_method_removal_sample_1.png | 1000px]]

5. When a class is extended, it creates a tightly coupled relationship between the parent and child class, which can make it difficult to modify the behavior of the child class independently. In contrast, when a class is included, it creates a looser coupling and allows the child class to access the methods and attributes of the parent class without being tied to its implementation. This approach provides greater flexibility and makes it easier to modify the behavior of the child class without affecting the parent class. Additionally, including a class allows for multiple inheritances, where a class can inherit from multiple parent classes, providing even more flexibility and code reuse.

"Scoring" class is extended by the "response_map.rb". Changes are made to "include" this class rather than extending it.

==Testing==

==Test Plan==

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

The Iterator design pattern is a behavioral pattern that offers a mechanism to access an aggregate object's elements progressively without disclosing the implementation's inner workings. The pattern specifies a distinct object called an iterator that contains the iteration logic and offers a consistent interface for navigating the aggregate's elements. The Iterator pattern encourages loose coupling between the two by separating the traversal logic from the aggregate object, making it simpler to alter the implementation of one without impacting the other. When we need to traverse a collection of items in a specified order but don't want to reveal the collection's internal workings to the client code, we can use this pattern.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T16:57:26Z

Aitha: /* Problem Statement */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. The method self.final_versions_from_reviewer in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. We removed the "latest_feedback" method from the feedback_response_map.rb. Modified the methods "self.feedback_response_report_by_round(" of the "feedback_response_map.rb" and "self.review_response_report" of the "review_response_map.rb". The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

2. For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

3. A more flexible and extensible codebase is made possible by polymorphism, which enables objects of several classes to be viewed as belonging to the same class. This implies that, depending on their own implementation, objects of different classes may reply to the same message or method in various ways. For instance, a "Vehicle" superclass can have subclasses like "Car," "Bus," and "Truck," each having its own implementation of the "drive()" method. Despite the fact that each of these subclasses may drive differently in this situation, polymorphism enables the identical 'drive()' function to be used on any of them. An application's maintainability and flexibility are improved by polymorphism, which also helps to reduce code duplication and create reusable code.

Just as in the above example, there is a common method named "title" in all the subclasses of response_map.rb. We implemented polymorphism and defined the method in the base class.

[[File:E2338_polymorphism_sample_1.png | 1000px]]

4. There are many methods that are not used and defined in the response_map.rb. We removed some of the methods that are not used by any other child classes.

[[File:E2338_method_removal_sample_1.png | 1000px]]

5. When a class is extended, it creates a tightly coupled relationship between the parent and child class, which can make it difficult to modify the behavior of the child class independently. In contrast, when a class is included, it creates a looser coupling and allows the child class to access the methods and attributes of the parent class without being tied to its implementation. This approach provides greater flexibility and makes it easier to modify the behavior of the child class without affecting the parent class. Additionally, including a class allows for multiple inheritances, where a class can inherit from multiple parent classes, providing even more flexibility and code reuse.

"Scoring" class is extended by the "response_map.rb". Changes are made to "include" this class rather than extending it.

==Testing==

==Test Plan==

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T16:56:20Z

Aitha: /* Our Solution */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. There is a questionnaire method implemented in each sub class where the "reviewer" or "reviewee" is assigned. This functionality can be implemented in the super class and assign the value based on the class name.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

12. The method responses_for_team_round in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. We removed the "latest_feedback" method from the feedback_response_map.rb. Modified the methods "self.feedback_response_report_by_round(" of the "feedback_response_map.rb" and "self.review_response_report" of the "review_response_map.rb". The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

2. For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

3. A more flexible and extensible codebase is made possible by polymorphism, which enables objects of several classes to be viewed as belonging to the same class. This implies that, depending on their own implementation, objects of different classes may reply to the same message or method in various ways. For instance, a "Vehicle" superclass can have subclasses like "Car," "Bus," and "Truck," each having its own implementation of the "drive()" method. Despite the fact that each of these subclasses may drive differently in this situation, polymorphism enables the identical 'drive()' function to be used on any of them. An application's maintainability and flexibility are improved by polymorphism, which also helps to reduce code duplication and create reusable code.

Just as in the above example, there is a common method named "title" in all the subclasses of response_map.rb. We implemented polymorphism and defined the method in the base class.

[[File:E2338_polymorphism_sample_1.png | 1000px]]

4. There are many methods that are not used and defined in the response_map.rb. We removed some of the methods that are not used by any other child classes.

[[File:E2338_method_removal_sample_1.png | 1000px]]

5. When a class is extended, it creates a tightly coupled relationship between the parent and child class, which can make it difficult to modify the behavior of the child class independently. In contrast, when a class is included, it creates a looser coupling and allows the child class to access the methods and attributes of the parent class without being tied to its implementation. This approach provides greater flexibility and makes it easier to modify the behavior of the child class without affecting the parent class. Additionally, including a class allows for multiple inheritances, where a class can inherit from multiple parent classes, providing even more flexibility and code reuse.

"Scoring" class is extended by the "response_map.rb". Changes are made to "include" this class rather than extending it.

==Testing==

==Test Plan==

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T16:32:53Z

Aitha: /* Our Solution */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. There is a questionnaire method implemented in each sub class where the "reviewer" or "reviewee" is assigned. This functionality can be implemented in the super class and assign the value based on the class name.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

12. The method responses_for_team_round in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

2. For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

3. A more flexible and extensible codebase is made possible by polymorphism, which enables objects of several classes to be viewed as belonging to the same class. This implies that, depending on their own implementation, objects of different classes may reply to the same message or method in various ways. For instance, a "Vehicle" superclass can have subclasses like "Car," "Bus," and "Truck," each having its own implementation of the "drive()" method. Despite the fact that each of these subclasses may drive differently in this situation, polymorphism enables the identical 'drive()' function to be used on any of them. An application's maintainability and flexibility are improved by polymorphism, which also helps to reduce code duplication and create reusable code.

Just as in the above example, there is a common method named "title" in all the subclasses of response_map.rb. We implemented polymorphism and defined the method in the base class.

[[File:E2338_polymorphism_sample_1.png | 1000px]]

4. There is a lot of code and methods that are not used and defined in the response_map.rb. We removed some of the methods that are not used by any other child classes.

[[File:E2338_method_removal_sample_1.png | 1000px]]

==Testing==

==Test Plan==

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

File:E2338 method removal sample 1.png

2023-04-24T16:32:18Z

Aitha: Remove unwanted methods

Remove unwanted methods

File:E2338 polymorphism sample 1.png

2023-04-24T16:29:31Z

Aitha: polymorphism for 'title' method

polymorphism for 'title' method

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T16:23:52Z

Aitha: /* Implementation */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. There is a questionnaire method implemented in each sub class where the "reviewer" or "reviewee" is assigned. This functionality can be implemented in the super class and assign the value based on the class name.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

12. The method responses_for_team_round in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

===Our Solution===
1. The Iterator Pattern is a behavioral design pattern that offers a method for sequentially accessing the components of an aggregate object without disclosing how it was really implemented. It offers a uniform interface for object collection traversal so that client code can traverse through collections of objects uniformly regardless of the collection type. The Iterator, which specifies the interface for navigating the collection, and the Aggregate, which defines the interface for constructing an Iterator object, make up the two primary parts of the pattern. The Iterator Pattern enables client programs to iterate over collections without worrying about the specifics of how they are implemented since it separates collection traversal from implementation.

The Original code was returning data structures in multiple methods. We used Iterator Design Pattern to avoid returning structures that need an understanding at the receiver. The following are some of the code snippets.

[[File:E2338_iterator_sample_1.png | 1000px]]

[[File:E2338_iterator_sample_2.png | 1000px]]

[[File:E2338_iterator_sample_3.png | 1000px]]

For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

==Testing==

==Test Plan==

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

File:E2338 iterator sample 3.png

2023-04-24T16:23:00Z

Aitha: Iterator class for feedback_response_map

Iterator class for feedback_response_map

File:E2338 iterator sample 2.png

2023-04-24T16:21:40Z

Aitha: Iterator pattern for feedback_response_map.rb

Iterator pattern for feedback_response_map.rb

File:E2338 iterator sample 1.png

2023-04-24T16:20:31Z

Aitha: Iterator Pattern code change for review_response_map.rb

Iterator Pattern code change for review_response_map.rb

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T15:59:19Z

Aitha: /* How to Test */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. There is a questionnaire method implemented in each sub class where the "reviewer" or "reviewee" is assigned. This functionality can be implemented in the super class and assign the value based on the class name.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

12. The method responses_for_team_round in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

==Testing==

==Test Plan==

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T15:57:07Z

Aitha: /* Design Pattern */

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. There is a questionnaire method implemented in each sub class where the "reviewer" or "reviewee" is assigned. This functionality can be implemented in the super class and assign the value based on the class name.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

12. The method responses_for_team_round in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

==Testing==

==Test Plan==

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Patterns Used==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T15:56:51Z

Aitha:

==Introduction==

===Expertiza Background===

When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

===Problem Statement===
We are refactoring the code which are being implemented previously for Re-implementation of response map hierarchy (E2314[[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2314._Reimplement_the_response_map_hierarchy]]). Some of the changes which are being pointed out till now are as follows-

*In the previous re-implementation, some of the methods are defined in class level which can be modified to instance level methods for better functionality and adhering to the Object Oriented Design principles.

*A few of the methods which are also present in the existing project should be moved to other classes according to their functionality in order to increase cohesion of the classes.

*Some of the methods also needs to be renamed in this refactoring process for better understanding of the developers who will be working on the project later on.

The detailed problem statement is as follows:-

1. The function show_review inside feedback_response_map.rb file needs to be removed as reviews belongs to a response_map and hence one response_map can have lot of reviews.

2. Accordingly, the relation between the Review class and the Response_map class needs to be changed.

3. The name of the method '''questionnaires''' is more localized in nature and it should be changed to '''“author_feedback_questionnaire”''' which will provide better understanding for the functionality of the method. Also it should be checked that if this method is required at all as author_feedback_questionnaire can be extracted from the Database directly very easily and whether this should be put into a separate method or not.

4. A method named "latest_feedback" which is present in the existing code should be removed from the feedback_response_map.rb class. Instead a method can be added to return a particular feedback according to the review_id which will reduce unnecessary data being provided to the user of this method.

5. The scoring class should be included with the "response_map" class so that it can add methods only to an instance of a class other than adding methods to the class.

6. Remove few of the methods from response_map.rb which are not relevant and should instead be used in the controller class.

7. Throughout the project, polymorphism needs to be implemented in some of the places where if-else are being used to make the design adhere to Object Oriented Programming.

8. There is a questionnaire method implemented in each sub class where the "reviewer" or "reviewee" is assigned. This functionality can be implemented in the super class and assign the value based on the class name.

9. title method is implemented to uniquely identify the response_maps belonging to that sub class. Reimplement this in the super class.

10. The email method is written in each subclass to suit the response locally. Visitor Pattern can be used here to attach the functionality rather than making it a part of each subclass.

11. The after_initialize function present in review_response_map.rb allows a team to review rather than individuals if needed. Verify if any database normalization principles are violated and take a decision on reimplementing it.

12. The method responses_for_team_round in review_response_map.rb is returning a data structure that contains responses from all the rounds. Reimplement it so that the calling function queries for a specific round and only one response is returned rather than the complete data structure.

==Implementation==
===Overall Impact of our Design===

[[File:E2314 design sample 1.png|1000px]]

===Classes impacted and their relationship===

[[File:E2338 design sample 2.png|1000px]]

==="How" we plan to solve the problems===
1. For showing each review present in the response_map, the map object is to be iterated in the controller class using the "Iterator Pattern".

2. The relationship is wrongly set as the review has a response_map, which needs to be changed to response_map has many reviews.

3. Rename the "questionnaire" method to "author_feedback_questionnaire".

4. Modify the "latest_feedback" method to return the data of a particular response_map and not a data structure. The input variable is to be set to receive the review id.

5. The "questionnaire" will be defined in the "response.rb" class. Polymorphism is to be used in the child classes to define its variation.

For implementation of the visitor pattern for send_email function, We have created a "email_sending_visitor" class which implements the visit method and "email_sending_method" which accepts a visitor. Then we extended these classes to create sub-classes according to the project requirement, for example defining "author_feedback_email_sending_method" for defining send_email method used in "feedback_response_map" and "teammate_review_email_sending_method" to implement the send_email method for "teammate_review_response_map". Then we call the send_email method from the appropriate classes which acts as a visitor to the original send_email method.

==Testing==

==Test Plan==

In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

We have implemented few of the tests previously but these tests needs to be modified according to the refactoring done on the project.

Tests to be added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

Tests to be added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Tests to be added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}

Tests to be added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

==Design Pattern==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names, '''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request. We may implement some more design patterns which we think might be necessary while refactoring the project.

For the "email" implementation, we plan to use '''Visitor Pattern'''. This will allow us to add new operations to the class without actually modifying it.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

==Screencast==

==References==

* [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]

*[https://github.com/sbiyer/reimplementation-back-end Github project]

==Team Members==

Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 

Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-24T15:55:58Z

Aitha: /* Team Members */

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-12T20:33:58Z

Aitha:

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-12T20:33:24Z

Aitha:

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-12T20:23:27Z

Aitha:

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-12T18:12:59Z

Aitha:

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-12T18:02:51Z

Aitha:

File:E2338 design sample 2.png

2023-04-12T18:00:23Z

Aitha: The classes impacted by the new design and their relationship.

The classes impacted by the new design and their relationship.

CSC/ECE 517 Spring 2023

2023-04-12T12:27:56Z

Aitha:

== OSS Projects ==

[[CSC/ECE 517 Spring_2023 -E2306. Refactor user_controller.rb, user.rb and its child classes]]

[[CSC/ECE 517 Spring_2023 - E2320. Reimplement the Question hierarchy]]

[[CSC/ECE 517 Spring_2023 - E2312 + E2313. Reimplement response.rb and responses_controller.rb]]

[[CSC/ECE 517 Spring_2023 - NTNX-1. Support provisioning MongoDb via NDB Kubernetes Operator]]

[[CSC/ECE 517 Spring_2023 - E2316. Reimplement sign_up_sheet_controller.rb]]

[[CSC/ECE 517 Spring_2023 - E2315. Reimplement signed_up_team.rb, sign_up_topic.rb, sign_up_sheet.rb]]

[[CSC/ECE 517 Spring_2023 - E2339. Reimplement signed_up_team.rb, sign_up_topic.rb, sign_up_sheet.rb (Project 4)]]

[[CSC/ECE 517 Spring_2023 - E2323. Refactor DueDate functionality from assignment.rb]]

[[CSC/ECE 517 Spring 2023 - E2317: Reimplement participant.rb]]

[[CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy]]

[[CSC/ECE 517 Spring 2023- NTNX-4. Extend NDB operator provision postregresql aws]]

[[CSC/ECE 517 Spring 2023 - E2321. Reimplement QuestionnairesController and QuestionsController]]

[[CSC/ECE 517 Spring 2023 - E2305. Grading audit trail]]

[[CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)]]

[[CSC/ECE 517 Spring 2023 - E2309. Refactor Node model and its subclasses]]

[[CSC/ECE 517 Spring 2023 - NTNX-2. Support provisioning mySQL databases via NDB Kubernetes Operator]]

[[CSC/ECE 517 Spring 2023 - E2300. Refactor E1858. Github metrics integration]]

[[CSC/ECE 517 Sping 2023 - E2322: Refactor Questionnaire View to display Bookmark Rating]]

[[CSC/ECE 517 Spring 2023 - NTNX-3. Refactor models to keep profiles (software, compute, network, etc) as optional and use default if not specified]]

[[CSC/ECE_517_Spring_2023_-_E2301._Refactor_review_maping_helper]]

[[CSC/ECE_517_Spring_2023_-_E2330._Reimplementation_Invitation_Controller]]

[[CSC/ECE_517_Spring_2023_-_E2337._Reimplement_node_hierarchy]]

[[CSC/ECE_517_Spring_2023_-_E2338._Reimplement_the_response_map_hierarchy]]

[[CSC/ECE_517_Spring_2023_-E2339._Reimplement signed_up_teams_controller and sign_up_topics_controller.rb]]

[[CSC/ECE_517_Spring_2023_-_E2320._Reimplement the Question Hierarchy]]

[[CSC/ECE_517_Spring_2023 - E2341. UI for Participants.rb]]

[[CSC/ECE_517_Spring_2023_-_E2336._Reimplement_response.rb]]

[[CSC/ECE_517_Spring_2023_-_E2345._Reimplement_QuestionnairesController_and_QuestionsController]]

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-07T13:47:47Z

Aitha: /* Problem Statement */

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-06T00:34:09Z

Aitha:

==Introduction==

===Expertiza Background===
===Problem Statement===

==Implementation==
===Flowchart===
===Refactoring===
====Refactoring method====
===Function placed in the view as partials===

==Testing==
===RSpec Testing===
===Manual Testing===

==Design Pattern==

==References==

==Team Members==

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-06T00:32:39Z

Aitha:

##Introduction

###Expertiza Background
###Problem Statement

##Implementation
### Flowchart
###Refactoring
####Refactoring method
###Function placed in the view as partials

##Testing
###RSpec Testing
###Manual Testing

##Design Pattern

##References

##Team Members

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-06T00:32:05Z

Aitha:

##Introduction##

###Expertiza Background
###Problem Statement###

##Implementation##
### Flowchart###
###Refactoring###
####Refactoring method####
###Function placed in the view as partials###

##Testing##
###RSpec Testing###
###Manual Testing###

##Design Pattern##

##References##

##Team Members##

CSC/ECE 517 Spring 2023 - E2338. Reimplement the response map hierarchy

2023-04-06T00:20:17Z

Aitha: Created page with "Index"

Index

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-28T00:46:24Z

Aitha:

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 Commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Test Plan===

====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====Note====
The scope of the project is limited to the model review_response_map. So, no controllers are used in the implementation. Due to this reason, it is not possible to perform functional testing or test the response using multiple controllers. We have stubbed dummy data necessary for testing the model and imitating the response from controllers. The in-built rails framework is used for Testing.

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Future Work==
The project required to use export functionality based on [https://expertiza.csc.ncsu.edu/index.php/CSC517_Spring_2019/E1923_New_Framework_For_Import/Export this] framework. However, both the import and export frameworks are not available on the main branch of the project. This can be done as future work once the main branch of Expertiza is updated with the framework.

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-28T00:11:46Z

Aitha: /* Test Plan */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 Commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Test Plan===

====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====Note====
The scope of the project is limited to the model review_response_map. So, no controllers are used in the implementation. Due to this reason, it is not possible to perform functional testing or test the response using multiple controllers. We have stubbed dummy data necessary for testing the model and imitating the response from controllers. The in-built rails framework is used for Testing.

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
{| class="wikitable"
|+ response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the review functionality
|-
| 2 || Test if feedback can be given to a review
|-
| 3 || Test if the response_map was metareviewed by metareviewer
|-
| 4 || Test if the metareviewer to this review(response) is assigned
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test if the right teammates are associated with a review
|}
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-28T00:04:21Z

Aitha: /* Test Plan */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 Commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Test Plan===

====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====Note====
The scope of the project is limited to the model review_response_map. So, no controllers are used in the implementation. Due to this reason, it is not possible to perform functional testing or test the response using multiple controllers. We have stubbed dummy data necessary for testing the model and imitating the response from controllers. The in-built rails framework is used for Testing.

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
{| class="wikitable"
|+ review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the right questionnaire is accessed
|-
| 2 || Tests if the right fields are exported
|-
| 3 || Tests if the metareview_response_maps function is working
|-
| 4 || Tests if the reviewer obtained is the right one
|-
| 5 || Tests if the reviewer can be retrieved with id
|-
| 6 || Tests if the last review for a team is available
|-
| 7 || Tests if the team email functionality is working
|-
| 8 || Tests if the prepare_final_review_versions function is returning right review id
|}

[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]
{| class="wikitable"
|+ teammate_review_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Test the working of questionnaire
|-
| 2 || Test if the team's questionnaire is accessable
|-
| 3 || Test the questionnaire with nil values
|-
| 4 || Test the questionnaire with non nil values
|-
| 5 || Test the reviewer details of a team review
|-
| 6 || Test the teammate_response_report functionality and see if right map is returned
|-
| 7 || Check the email functionality for a team assignment review
|}

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map

{| class="wikitable"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
|-
| 6 || Tests the email functionality
|}

[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-27T23:50:13Z

Aitha: /* New Test Cases */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 Commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Test Plan===

====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====Note====
The scope of the project is limited to the model review_response_map. So, no controllers are used in the implementation. Due to this reason, it is not possible to perform functional testing or test the response using multiple controllers. We have stubbed dummy data necessary for testing the model and imitating the response from controllers. The in-built rails framework is used for Testing.

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

feedback_response_map.rb testing

{| class="wikitable" style="margin-left:40px"
|+ feedback_response_map_test.rb
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
| -
| 6 || Tests if the email functionality is working
|-
|}

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-27T23:48:46Z

Aitha: /* Test Plan */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 Commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Test Plan===

====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====Note====
The scope of the project is limited to the model review_response_map. So, no controllers are used in the implementation. Due to this reason, it is not possible to perform functional testing or test the response using multiple controllers. We have stubbed dummy data necessary for testing the model and imitating the response from controllers. The in-built rails framework is used for Testing.

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

feedback_response_map.rb testing

{| class="wikitable" style="margin-left:40px"
|-
! Test No. !! Description
|-
| 1 || Tests if the assignment object is available
|-
| 2 || Tests the show_review
|-
| 3 || Tests if the title function is working
|-
| 4 || Tests the questionnaire function and if the right question ids are returned
|-
| 5 || Tests if the right contributor is returned
| -
| 6 || Tests if the email functionality is working
|}

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-27T23:30:52Z

Aitha: /* =Note */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 Commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Test Plan===

====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

====Note====
The scope of the project is limited to the model review_response_map. So, no controllers are used in the implementation. Due to this reason, it is not possible to perform functional testing or test the response using multiple controllers. The in-built rails framework is used for Testing.

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-27T23:29:13Z

Aitha: /* Testing */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 Commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Test Plan===
====Note===
The scope of the project is limited to the model review_response_map. So, no controllers are used in the implementation. Due to this reason, it is not possible to perform functional testing or test the response using multiple controllers.

====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-27T19:32:19Z

Aitha: /* Methods Moved to Response Class */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 Commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Testing===
====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-22T02:35:45Z

Aitha:

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png|1000px]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Testing===
====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==
[https://expertiza.ncsu.edu/submitted_content/download?current_folder%5Bname%5D=%2Fvar%2Fwww%2Fexpertiza%2Freleases%2F20210417040133%2Fpg_data%2Fefg%2Fcsc517%2Fs23%2Foss%2F0&download=CSC_517_OSS_Project_Tests.mp4&id=49700 Screencast]

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

The pull request raised to be merged with https://github.com/expertiza/reimplementation-back-end original implementation is found at https://github.com/expertiza/reimplementation-back-end/pull/21

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-22T02:30:47Z

Aitha: /* Design */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==
[[File:E2314 design sample 1.png]]

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Testing===
====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

File:E2314 design sample 1.png

2023-03-22T02:30:33Z

Aitha: Design diagram proposed with the new enhancements

Design diagram proposed with the new enhancements

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-22T02:29:22Z

Aitha: /* How to Test */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Testing===
====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|1000px]]
[[File:E2314 tests 2.png|1000px]]

==Screencast==

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-22T02:29:08Z

Aitha: /* How to Test */

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Testing===
====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==
Here are step-by-step instructions for setting up Expertiza backend repository on a CSC-517 Expertiza Development Environment VCL session.

1. Copy the "/root/setup_expertiza.sh" script to your home directory. sudo cp /root/setup_expertiza.sh ~/setup_expertiza.sh

2. Make the script executable. sudo chmod +x setup_expertiza.sh

3. Run the script. ./setup_expertiza.sh

4. Provide the GitHub repository URL. Once the script runs, you will be prompted to enter the GitHub repository URL for the project you want to work on.

5. Select the project type (Refactoring or Reimplementation)

6. Wait for the setup to complete and terminate the terminals.

7. Change the username in config/database.yml from root to dev on line 4 --- username: dev

8. cd into the root of the project

9. rake db:create

10. rake db:migrate

11. rake test TESTOPTS="-v"

[[File:E2314 tests 1.png|100px]]
[[File:E2314 tests 2.png|100px]]

==Screencast==

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]

CSC/ECE 517 Spring 2023

2023-03-22T01:09:47Z

Aitha:

== OSS Projects ==

[[CSC/ECE 517 Spring_2023 - E2320. Reimplement the Question hierarchy]]

[[CSC/ECE 517 Spring_2023 - E2312 + E2313. Reimplement response.rb and responses_controller.rb]]

[[CSC/ECE 517 Spring_2023 - CSC517. Support provisioning MongoDb via NDB Kubernetes Operator]]

[[CSC/ECE 517 Spring_2023 - E2316. Reimplement sign_up_sheet_controller.rb]]

[[CSC/ECE 517 Spring_2023 - E2315. Reimplement signed_up_team.rb, sign_up_topic.rb, sign_up_sheet.rb]]

[[CSC/ECE 517 Spring_2023 - E2323. Refactor DueDate functionality from assignment.rb]]

[[CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy]]

CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy

2023-03-22T00:44:42Z

Aitha:

==Background==
When someone writes a review in Expertiza, they are creating an instance of the Response class. Each Response is created based on a particular ResponseMap. The ResponseMap tells who the reviewer is (the reviewer_id), who the reviewee is (the reviewee_id), and what is being reviewed (the reviewed_object_id).
* The reviewer_id is normally a record in the Participants table, which specifies an AssignmentParticipant. However, if teams rather than individuals are doing reviews for this assignment, it may be an AssignmentTeam.
* For reviews of student work, the reviewee_id is always an AssignmentTeam. (If an assignment is set up so individuals rather than teams submit work, the reviewee will still be a 1-member AssignmentTeam.)
* For teammate reviews, the reviewee_id is always an AssignmentParticipant.
* The reviewed_object_id is normally an Assignment. But in the case of meta-reviews, the reviewed_object_id is another ResponseMap (because it is a review that is being reviewed).

==Project Requirements==
This project aims to re-implement the ResponseMap hierarchy in Expertiza to simplify its design and reduce the number of class methods. Specifically, this project will focus on re-implementing three of the ResponseMap subclasses: ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps.

The ResponseMap hierarchy is a critical component of Expertiza, as it defines the relationship between reviewers, reviewees, and the objects being reviewed. In the current implementation, there are several issues that need to be addressed to improve the overall design and functionality of the hierarchy. For example, the current hierarchy is cluttered with class methods, which makes it difficult to maintain and update. Additionally, some methods belong in the Response class while others belong in the ResponseMap subclasses.

To address these issues, this project will begin by creating a simplified version of the Response class that includes only the methods that belong in that class. This will make it easier to merge the new Response class with the ResponseMap subclasses that are being re-implemented.

Next, the ReviewResponseMap export operation will be re-implemented based on the new Response class framework. This will make the export operation simpler and easier to use. Additionally, the comparator method will be replaced by an overloading of the <=> operator.

Several methods that return Responses in the ResponseMap subclasses will be moved to the Response class. This will improve the overall organization of the hierarchy and make it easier to maintain and update in the future. Methods whose name begins with "get" will be renamed to follow Ruby conventions, as this will make the code easier to read and understand.

The FeedbackResponseMap is used for giving author feedback, which will be considered when re-implementing this subclass. Specifically, the methods in this subclass will be reviewed to ensure that they are properly named and that they follow Ruby conventions.

Overall, the main requirements for this project include:
* Re-implementing three of the ResponseMap subclasses (ReviewResponseMaps, FeedbackResponseMaps, and TeammateReviewResponseMaps)
* Simplifying the ResponseMap hierarchy to reduce the number of class methods
* Creating a simplified version of the Response class that includes only the methods that belong in that class
* Re-implementing the ReviewResponseMap export operation based on the new Response class framework
* Replacing the comparator method with overloading of the <=> operator
* Moving several methods that return Responses in the ResponseMap subclasses to the Response class
* Renaming methods whose name begins with "get" to follow Ruby conventions
* Reviewing the FeedbackResponseMap subclass to ensure its methods are appropriately named and follow Ruby conventions.

By completing these requirements, the ResponseMap hierarchy in Expertiza will be improved and easier to maintain and update in the future.

==Design==

==Our Enhancements==
===Comment Lines===
Each well-written code must contain comment lines that explain the purpose of each method's class. It is simpler for other developers to comprehend and use the code because these comment lines offer a concise and clear explanation of what the method performs. Also, comment lines contribute to the code's maintainability and scalability by supplying context and facilitating simpler debugging and modification. It can be difficult for other developers to comprehend a method's purpose without comment lines, especially if the code is complex or if they need to become more familiar with the programming language. Therefore, to ensure that the code is well-documented, maintainable, and scalable, it is crucial to include comment lines describing the purpose of a method in a class.

Each method has no comment lines in Expertiza's current implementation. All available methods in the response maps class have comment lines added as project guidelines require. The sample work with comment lines is below.

[[File:E2314 comment line sample 1.png|1000px]]

===Variable and Method names===
Using appropriate variable and method names while writing code is imperative for various reasons. The first benefit of giving code meaningful names is that they make it easier for future developers to read and comprehend the code. Clear and informative variable and method names simplify comprehending what a specific piece of code does, ultimately saving time and effort. Second, exact terms contribute to better code quality and error prevention. The likelihood that variables and methods may be misused, leading to problems or faults in the code, is reduced when their names appropriately reflect what they do. Finally, code is more scalable and maintainable when it has meaningful names. Well-chosen variable and method names simplify adapting and growing the code over time without creating errors or ambiguity. As a result of increased readability, reduced error rates, and increased maintainability and scalability, utilizing meaningful variable and method names is a critical best practice when writing code.

We have renamed many variable and method names as part of the project. To adhere to the Ruby standards, we have removed the word "get" when starting a method name. Our sample work is below.

[[File:E2314 naming sample 1.png|1000px]]

[[File:E2314 naming sample 2.png|1000px]]

Name of method changed from "email" to "send_email"
[[File:E2314 naming sample 3.png|1000px]]

===<=> Operators===
The rocket operator "<=>" is a built-in comparison operator in Ruby that offers a clear and effective way to sort and compare things. The rocket operator can sort items according to their attributes rather than creating our comparator function. The rocket operator yields 0 if the two objects under comparison are equal, -1 if the left object is smaller than the right object, and 1 if the left object is larger than the right object. The rocket operator offers a consistent and dependable technique to compare and classify objects while also saving time and effort. Creating our own comparator function may be more error-prone and less effective than the built-in operator. Also, employing the rocket operator can aid in reducing code complexity and enhancing readability because other writers are more likely to be familiar with the operator than with a unique comparator function. As a result, it is advised to use the rocket operator "<=>" wherever possible rather than creating our comparator function in Ruby to ensure effective and trustworthy sorting and comparison of items.

To stick to the above Ruby standard, we have replaced the self-defined comparator functions and replaced them with the inbuilt rocket.

[[File:E2314 rocket sample 1.png|1000px]]

===Methods Moved to Response Class===
It is crucial to create classes in object-oriented programming that are modular, maintainable, and scalable. Understanding the overall structure of the code and effectively modifying it cannot be easy when methods are dispersed across numerous subclasses. Additionally, having functions in the main class rather than a subclass makes more sense when they are closely related to the duties of the main class. Moving these methods to the main class may result in better code organization and a more straightforward program flow. Other subclasses can access the methods in the main class without redefining them, reducing code duplication and improving code reuse. Since this can result in more maintainable, scalable, and modular code, it is generally advised to move methods to the main class when closely related to its responsibilities.

The following table contains the names of methods moved from subclasses to the "response.rb" class located at "app/models/response.rb".

{| class="wikitable"
|+ Migrated Methods
|-
! File Name !! File Location !! Method Name !! Commit Details
|-
| response_map.rb || app/models/response_map.rb || self.assessments_for(team), self.reviewer_assessments_for(team, reviewer), <=>(other_response) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/7eb2b4e53cc71423fe3d46341ee5dac9a56a2273 Commit]
|-
| review_response_map.rb || app/models/review_response_map.rb || self.get_responses_for_team_round(team, round, type) || [https://github.com/sbiyer/reimplementation-back-end/pull/1/commits/b58442673c65d2fa9fe2847c299ded36217b9ef7 commit]
|}

===Remove Unused Code===
Unused code must be removed to maintain code quality, lower code complexity, and enhance program performance in software development. Unused code can expand the size and complexity of the codebase, making it more challenging to maintain, debug, and update. Additionally, it may cause developers to become confused and raise the risk of introducing bugs or security vulnerabilities. The size and complexity of the codebase can be decreased by removing unused code, which will make it simpler to comprehend and maintain. As the compiler or interpreter does not need to allocate memory or processing power to execute inactive code, it can also enhance program performance. As the codebase becomes cleaner and more organized and the likelihood of running into issues in the future decreases, removing unused code can also aid in reducing technical debt.

As part of this project, we identified unused code and removed it from the code base. One such example is below

[[File:E2314 unused sample 1.png|1000px]]

===Testing===
====Fix Broken Tests====
Significant changes were introduced into code, such as moving methods from sub-classes to the main class, as seen in the above implementations. It's common for test cases to break or no longer work as expected. It's essential to fix the test cases to ensure the code behaves as intended and to catch any potential bugs or issues introduced during the changes. By resolving the test cases, we confirmed that the code is still working as expected and that the changes have not inadvertently caused any problems. Additionally, fixing the test cases helps to identify and fix any issues that may have been present in the codebase before the changes were made. Some of the examples of test fixes made are given below.

[[File:E2314 tests sample 1.png|1000px]]

====New Test Cases====
In software development, testing, and unit tests are crucial because they ensure that the software works as intended and is free of bugs or errors. Before the software is made available to the general public, testing enables developers to find and address any issues, avoiding potential problems and saving time and resources. Because they test individual software units or components, unit tests are a crucial component of testing because they enable developers to pinpoint problems in a specific section of code and make targeted corrections. With this approach, developers can identify issues early on, saving time and resources while ensuring that the final product is high quality and meets users' needs. In conclusion, testing and unit testing is essential for guaranteeing the quality and dependability of software and ought to be a fundamental component of any software development process. For all the said reasons, we introduced test cases to test the response class as well as the sub classes review_response_map, teammate_review_response_map, response_map, and feedback_response_map.

Example of test cases added to test review_response_map
[[File:E2314 tests sample 3.png|1000px]]

Example of test cases added to test teammate_review_response_map
[[File:E2314 tests sample 2.png|1000px]]

Example of test cases added to test response_map
[[File:E2314 tests sample 4.png|1000px]]

Example of test cases added to test feedback_response_map
[[File:E2314 tests sample 5.png|1000px]]

==How to Test==

==Screencast==

==GitHub==
The code corresponding to this project is available as open source. The code is found at https://github.com/sbiyer/reimplementation-back-end

==Contributors==
Srini Iyer - [https://www.linkedin.com/in/sriniiyer LinkedIn] 
Aswin Itha - [https://www.linkedin.com/in/aswin-itha LinkedIn] 
Suparno Saha - [https://www.linkedin.com/in/suparno-saha-81a05a91 LinkedIn]