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

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[[1]]). 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

Classes impacted and their relationship

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

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

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

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

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

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.

References

• Introduction to Refractoring in Ruby

• Github project

Team Members

Suparno Saha

Aswin Itha

Srini Iyer