Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-05-02T04:03:18Z

Gkogant:

This page provides information about the documentation of E2241: Heatgrid fixes and improvements as part of CSC/ECE 517 Spring 2022 Final project.
__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
*Nicholas Himes (nnhimes)
<h3> Team Members (PinkPatterns) </h3>
* Eshwar Chandra Vidhyasagar Thedla (ethedla)
* Gokul Krishna Koganti (gkogant)
* Jyothi Sumer Goud Maduru (jmaduru)
* Suneha Bose (sbose2)

<h2> Heat Grid </h2>

Heat Grid refers to a part of view in Expertiza that shows review scores of all the reviews done for a particular assignment. It shows scores given for each rubric by peer reviewers. This is used by instructors to assign scores to individual assignments and by students to view review scores of their assignment. Our project scope involves dealing with fixing issues related to the heat grid and any subsequent bugs that might arrive.

<h2> Issues identified </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work</h3>
<p> There are some instances where a student was shown as reviewing his/her team even though the "Allow Self Review" checkbox was not checked by the instructor. This situation should not arise for practical purposes. Test cases must be extensively added so that we can be notified if the bug occurs again. </p>

[[File:Screen Shot 2022-04-06 at 10.37.56 PM.png|center|450px]]

<h3> Issue #1869: Deal with the metrics of the heat grid</h3>
<p> <b>metric-1</b> column name in the heat grid follows bad naming convention. It doesn't explain what the column refers to. This must be changed to make the column name more apt.</p>
<p> As of now, the heat grid uses only one metric (metric-1). We must facilitate the system for addition of new metrics. Instructors should be able to toggle between various metrics as per their preferences. This can be done by the use of a drop down menu.</p>

[[File:Screen Shot 2022-04-06 at 10.34.47 PM.png|center|550px]]

<h2> Design Principle </h2>
<p>
For Issue #1869 we plan to use the Factory Design Pattern since we are dealing with the creation of multiple kinds of metrics. As part of our implementation, we plan on using a metric interface, which can be implemented by different concrete metric classes. A factory class acts as a middleman between the implementations and the main class that instantiates the objects. Based on the instructor's selection, the main class requests the metric object from the factory class, rather than dealing with the creation logic on its own. This pattern, therefore, enforces encapsulation and results in the low coupling, the principle which is our primary target for this project scope.
</p>
<p>
The previous implementation has dealt with issue #1869. But the drawback with the implementation is that it renders a code that is highly coupled. Whenever a new metric is added two files (assignments/edit/_general.html.erb and grades/view_team.html.erb) are to be changed, resulting in high coupling. As a consequence, tests pertaining to the highly coupled codes require new tests as a new metric is added. This is undesirable. So, the principle of low coupling is the main focus of our implementation. This principle will enable a common set of tests that would be valid for any number of metrics that will potentially be added in the future.
</p>
<h2> Files to be targeted </h2>

<h3>Issue #2019</h3>
<p> Test file for adding test cases to implement self-reviews checks </p>
* spec/controllers/grades_controller_spec.rb

<h3>Issue #1869</h3>
<p>For Heat grid view</p>
* app/views/grades/_view_heatgrid.html.erb
* app/views/grades/view_team.html.erb
* app/helpers/grades_helper.rb
* app/controllers/grades_controller.rb
* app/models/vm_question_response.rb
* app/models/vm_question_row.rb
* assets/view_team_in_grades.js
<p>For Assignment view</p>
* app/views/assignment/edit/_general.html.erb
* app/controllers/assignments_controller.rb

<h2> Implementation of Issue 1869</h2>

<h3> Previous team’s implementation </h3>

<p> The previous team has dealt with the issue by changing “metric-1” to “verbose comment count”, which is relevant to what metric-1 refers to. For the latter half of the issue, they have provided a metric dropdown for the instructor to select while creating the assignment. This consequently requires only one metric to be displayed on the heat grid for which they’ve given a toggle option to show and hide the metric.
</p>

<h4> Changes reflected in the UI </h4>

<ul>
<li> <b> metric-1 </b> changed to verbose comment count </li>
[[File:Heatgrid-metric.png|600px]]

<li> Metric dropdown provided while creating an assignment </li>
[[File:Assignment General page.png|600px]]

</ul>

<h4> Issue with previous team's implementation </h4>

<p> The critical problem with their changes was, when in future a new metric is added, it forces a change in two view files: one time in assignments/edit/_general.html.erb and two times in grades/view_team.html.erb. Requiring these changes in view files that have little relevance to the heat grid is essentially causing high coupling. </p>

<h3> Current implementation </h3>

<h4> Issue Goal </h4>
<p> Our mentor has required us to display metrics in the heat grid with a toggle option for the user to select only the required metrics according to their preferences. This should be done keeping in mind low coupling as the primary design goal. These changes should be accompanied by minor changes such as adding comments and changing the name of “metric-1” to a self-indicative name. </p>

<h4> Implementation details </h4>
<p>
In the original beta implementation, whenever the relevant view file is loaded, it is calling the method "populate_view_model" present in the "grades_controller.rb" file. This method, is explicitly calling another model method to calculate metric. Whenever a new metric is added, we will have to make a call to that metric in the populate view model. This is not ideal as each new metric added is introducing a new line of code in the controller body. It is also not possible to determine the metrics present dynamically. To deal with this problem, we introduced a new parent method "calculate_metrics" in model file "vm_question_response.rb". This method is responsible for calling other individual methods that calculate metrics. The call to this method is replacing the explicit calls to metric calculation in the controller. This essentially is breaking the dependency between new metric introduction and the controller. Now, whenever a new metric is added, there is no need to introduce any code changes in the controller, instead we just have to change the code in relevant model file.
</p>
<p>
[[File:Heatgrid-2022-10.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-11.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-13.png|600px]] <br/>
</p>

<p>A new hashmap is introduced to store the values of the metrics in the form of key value pairs. Instead of explicitly calling metrics by name in the view file, this hashmap is used to iterate over the metrics and displayed</p>

<p>
[[File:Heatgrid-2022-20.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-21.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-22.png|600px]] <br/>
</p>

Toggle feature is implemented in "view_team_in_grades.js" file. When the checkbox is clicked, function in javascript file is called and appropriate elements are hidden.

<p>
[[File:Heatgrid-2022-23.png|600px]] <br/>
</p>

<h4> Adding a new metric in future </h4>

<p> To introduce new metric, a new method should be added in "vm_question_response.rb" file. This newly added method should be called from "calculate_metrics" method </p>

<p>
[[File:Heatgrid-2022-30.png|600px]] <br/>
</p>

<p>
[[File:Heatgrid-2022-31.png|600px]] <br/>
</p>

<h4>Changes reflected in the UI</h4>

<p>
[[File:Heatgrid-2022-40.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-41.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-43.png|600px]] <br/>
</p>

<h4> Manual Testing </h4>

<pre>
Scenario: Visibility of all the unchecked metric checkboxes in View Scores view
Given user has logged in
When user visits View Scores page
Then all the unchecked metric checkboxes are present above the heat grid
</pre>

<pre>
Scenario: Default invisibility of metric columns in View Scores view
Given user has logged in
When user visits View Scores page
Then metric columns are not visible in the heat grid
</pre>

<pre>
Scenario: Checking a metric checkbox displays the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on unchecked comments#10 metric
Then column with column name " comments#10" gets displayed with corresponding values
</pre>

<pre>
Scenario: Unchecking a metric checkbox hides the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on checked comments#10 metric
Then column with column name " comments#10" and corresponding values get hidden
</pre>

<h4> Unit Testing </h4>
<p>As our project does not deal with actually adding new metrics, but just facilitating a low-coupling addition of new metrics, we need not add any unit test cases for metric implementations. There is only one metric in the system as of now for which test cases are already written.</p>

<h2>Implementation of Issue 2019</h2>
<p> This issue encompasses many problems such as review reports not displaying correctly and a user being able to review his/her work. Each problem has been dealt with individually. Main problems identified as part of this issue and relevant observations and corrections are jotted down in this section. </p>

<h3> Problem 1 : A user being able to review his/her own work.</h3>

<h4> Problem comment </h4>
<p> On Madeup Problem 3, assignment 1055, there are several anomalies in the review report. User 9277 reviewed Team_2323 and gave this comment: "This question seems a little suspicious. It is nearly identical to Question 4a on page 327 in the 2016 edition book. The only thing change was variable name A to B and value 2 to 3." However, according to the View Submissions page, User 9277 is the only member of Team_2323. </p>

<h4> Issue Reproduction and Observations </h4>
<p> We tried reproducing the issue as specified in the issue comment, but we could not find Madeup Problem 3, assignment 1055. So, we have created two assignments with different parameters to check if the instructor is able to assign a reviewer his/her own work. </p>

<p> We have created an assignment "Noself review" with allow self review option unchecked. Then, from the instructor page, we have created a team with student13 and student 14 as teammates. Then we logged into student14 account and submitted a hyperlink for that assignment. After that, from the instructor page we clicked on the assign review button and tried assigning student13 as the reviewer for that work and then tried the same with student14. In both the cases, the assignment failed by rendering a flash error message, "You cannot assign this student to review his/her own artifact." </p>
<ul>
<li> Unchecked allow self-review option in "Noself review" assignment </li>
[[File:self-review-option-unchecked.png|600px]]<br/>

<li> Participants page containing add reviewer button </li>
[[File:Duo-team-submission.png|600px]]<br/>

<li> Adding student13 as reviewer for his/her own work </li>
[[File:Self-assign-review.png|600px]]<br/>

<li> Flash error message displayed</li>
[[File:self-review-unchecked.png|600px]]<br/>
</ul>
<p> We followed the same process for "self_review assignment", which gave student an option to self review his/her own work immediately after submitting their work. However, when the instructor tried assigning the user with his/her own work, same flash error message was displayed, not allowing the user to review their work.</p>

<li> Checked allow self-review option in "self_review assignment" </li>
[[File:Self-review-checked.png|600px]]<br/>

<li> Participants page of self review assignment</li>
[[File:Participants_page_for_self-review_assignment.png|600px]]<br/>

<li> Assigning student13 as reviewer for own work</li>
[[File:Student-13-self-review.png|600px]]<br/>

<li> Display of error message after assigning own artifact</li>
[[File: Error-message-checked.png|600px]]<br/>

<h4> Test case added</h4>
<p> Previously implemented test cases of review_map controller have covered most of the tests pertaining to a user being assigned review work for his own artifact. These test cases primarily focused on the add_reviewer function of the review_mapping controller. However a test case checking for the display of flash error message on trying to assign reviewer to his/her own work was not covered, which we have added in the respective spec file. </p>

<pre>
Scenario: Display of flash error message when instructor tries student their own artifact for reviewing
Given instructor has logged in
When the instructor visits the assignment page and
When the instructor clicks on assign reviewer for an assignment and
when the instructor tries to assign the owner of the artifact as the reviewer
Then a flash error message is displayed saying "You cannot assign this student to review his/her own artifact."
</pre>

<pre>
context 'when instructor tries to assign a student their own artifact for reviewing' do
it 'flashes an error message' do
allow(TeamsUser).to receive(:exists?).with(team_id: '1', user_id: 1).and_return(true)
post :add_reviewer, @params
expect(flash[:error]).to eq('You cannot assign this student to review his/her own artifact.')
expect(response).to redirect_to '/review_mapping/list_mappings?id=1'
end
end
</pre>

<h3> Problem 2 : Review comments from the first round not being displayed</h3>

<h4> Problem comment </h4>
<p> The Round 1 review (and the Round 1 heat grid) are missing when the instructor (instructor6) goes to Assign Grade for Student 9277. The Round 1 review should be in the first heat grid on the Assign Grades page. </p>

<h4> Issue Reproduction and Observations </h4>
<p> For this problem, we have tried the similar thing as the first problem. We have observed that if the instructor checks the option "review rubric varies by round" when the instructor creates an assignment, reviews from all the rounds are displayed in the heat grid. When the instructor unchecks that option, only the most recent review set is being displayed. As this is dependent on the user preference, we identified this not to be a problem. </p>

<ul>
<li> Review rubric varies by round option, which is unchecked by default </li>
[[File: Unchecked-rubric-varies.jpeg|600px]]<br/>

<li> Display of only the reviews of latest round when "Review rubric varies by round" is unchecked</li>
[[File:Latest_review_on_uncheck.jpeg|600px]]<br/>

<li> Display of reviews of all the rounds when "Review rubric varies by round" is checked</li>
[[File:All-round-display.jpeg|600px]]<br/>

</ul>

<h2> Important Links </h2>
* GitHub repository link: https://github.com/EshwarCVS/expertiza
* Project Description Document: https://docs.google.com/document/d/1H0BjzMBz5it7Wckhegq4LXhMi8RVctTwVzP2x9gnFCo/edit#heading=h.tqdrrd12xs4x
* GitHub Issue #1869: https://github.com/expertiza/expertiza/issues/1869
* GitHub Issue #2019: https://github.com/expertiza/expertiza/issues/2019

File:All-round-display.jpeg

2022-05-02T04:01:02Z

Gkogant:

File:Latest review on uncheck.jpeg

2022-05-02T03:58:49Z

Gkogant:

File:Unchecked-rubric-varies.jpeg

2022-05-02T03:52:25Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-05-02T03:30:34Z

Gkogant:

This page provides information about the documentation of E2241: Heatgrid fixes and improvements as part of CSC/ECE 517 Spring 2022 Final project.
__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
*Nicholas Himes (nnhimes)
<h3> Team Members (PinkPatterns) </h3>
* Eshwar Chandra Vidhyasagar Thedla (ethedla)
* Gokul Krishna Koganti (gkogant)
* Jyothi Sumer Goud Maduru (jmaduru)
* Suneha Bose (sbose2)

<h2> Heat Grid </h2>

Heat Grid refers to a part of view in Expertiza that shows review scores of all the reviews done for a particular assignment. It shows scores given for each rubric by peer reviewers. This is used by instructors to assign scores to individual assignments and by students to view review scores of their assignment. Our project scope involves dealing with fixing issues related to the heat grid and any subsequent bugs that might arrive.

<h2> Issues identified </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work</h3>
<p> There are some instances where a student was shown as reviewing his/her team even though the "Allow Self Review" checkbox was not checked by the instructor. This situation should not arise for practical purposes. Test cases must be extensively added so that we can be notified if the bug occurs again. </p>

[[File:Screen Shot 2022-04-06 at 10.37.56 PM.png|center|450px]]

<h3> Issue #1869: Deal with the metrics of the heat grid</h3>
<p> <b>metric-1</b> column name in the heat grid follows bad naming convention. It doesn't explain what the column refers to. This must be changed to make the column name more apt.</p>
<p> As of now, the heat grid uses only one metric (metric-1). We must facilitate the system for addition of new metrics. Instructors should be able to toggle between various metrics as per their preferences. This can be done by the use of a drop down menu.</p>

[[File:Screen Shot 2022-04-06 at 10.34.47 PM.png|center|550px]]

<h2> Design Principle </h2>
<p>
For Issue #1869 we plan to use the Factory Design Pattern since we are dealing with the creation of multiple kinds of metrics. As part of our implementation, we plan on using a metric interface, which can be implemented by different concrete metric classes. A factory class acts as a middleman between the implementations and the main class that instantiates the objects. Based on the instructor's selection, the main class requests the metric object from the factory class, rather than dealing with the creation logic on its own. This pattern, therefore, enforces encapsulation and results in the low coupling, the principle which is our primary target for this project scope.
</p>
<p>
The previous implementation has dealt with issue #1869. But the drawback with the implementation is that it renders a code that is highly coupled. Whenever a new metric is added two files (assignments/edit/_general.html.erb and grades/view_team.html.erb) are to be changed, resulting in high coupling. As a consequence, tests pertaining to the highly coupled codes require new tests as a new metric is added. This is undesirable. So, the principle of low coupling is the main focus of our implementation. This principle will enable a common set of tests that would be valid for any number of metrics that will potentially be added in the future.
</p>
<h2> Files to be targeted </h2>

<h3>Issue #2019</h3>
<p> Test file for adding test cases to implement self-reviews checks </p>
* spec/controllers/grades_controller_spec.rb

<h3>Issue #1869</h3>
<p>For Heat grid view</p>
* app/views/grades/_view_heatgrid.html.erb
* app/views/grades/view_team.html.erb
* app/helpers/grades_helper.rb
* app/controllers/grades_controller.rb
* app/models/vm_question_response.rb
* app/models/vm_question_row.rb
* assets/view_team_in_grades.js
<p>For Assignment view</p>
* app/views/assignment/edit/_general.html.erb
* app/controllers/assignments_controller.rb

<h2> Implementation of Issue 1869</h2>

<h3> Previous team’s implementation </h3>

<p> The previous team has dealt with the issue by changing “metric-1” to “verbose comment count”, which is relevant to what metric-1 refers to. For the latter half of the issue, they have provided a metric dropdown for the instructor to select while creating the assignment. This consequently requires only one metric to be displayed on the heat grid for which they’ve given a toggle option to show and hide the metric.
</p>

<h4> Changes reflected in the UI </h4>

<ul>
<li> <b> metric-1 </b> changed to verbose comment count </li>
[[File:Heatgrid-metric.png|600px]]

<li> Metric dropdown provided while creating an assignment </li>
[[File:Assignment General page.png|600px]]

</ul>

<h4> Issue with previous team's implementation </h4>

<p> The critical problem with their changes was, when in future a new metric is added, it forces a change in two view files: one time in assignments/edit/_general.html.erb and two times in grades/view_team.html.erb. Requiring these changes in view files that have little relevance to the heat grid is essentially causing high coupling. </p>

<h3> Current implementation </h3>

<h4> Issue Goal </h4>
<p> Our mentor has required us to display metrics in the heat grid with a toggle option for the user to select only the required metrics according to their preferences. This should be done keeping in mind low coupling as the primary design goal. These changes should be accompanied by minor changes such as adding comments and changing the name of “metric-1” to a self-indicative name. </p>

<h4> Implementation details </h4>
<p>
In the original beta implementation, whenever the relevant view file is loaded, it is calling the method "populate_view_model" present in the "grades_controller.rb" file. This method, is explicitly calling another model method to calculate metric. Whenever a new metric is added, we will have to make a call to that metric in the populate view model. This is not ideal as each new metric added is introducing a new line of code in the controller body. It is also not possible to determine the metrics present dynamically. To deal with this problem, we introduced a new parent method "calculate_metrics" in model file "vm_question_response.rb". This method is responsible for calling other individual methods that calculate metrics. The call to this method is replacing the explicit calls to metric calculation in the controller. This essentially is breaking the dependency between new metric introduction and the controller. Now, whenever a new metric is added, there is no need to introduce any code changes in the controller, instead we just have to change the code in relevant model file.
</p>
<p>
[[File:Heatgrid-2022-10.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-11.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-13.png|600px]] <br/>
</p>

<p>A new hashmap is introduced to store the values of the metrics in the form of key value pairs. Instead of explicitly calling metrics by name in the view file, this hashmap is used to iterate over the metrics and displayed</p>

<p>
[[File:Heatgrid-2022-20.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-21.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-22.png|600px]] <br/>
</p>

Toggle feature is implemented in "view_team_in_grades.js" file. When the checkbox is clicked, function in javascript file is called and appropriate elements are hidden.

<p>
[[File:Heatgrid-2022-23.png|600px]] <br/>
</p>

<h4> Adding a new metric in future </h4>

<p> To introduce new metric, a new method should be added in "vm_question_response.rb" file. This newly added method should be called from "calculate_metrics" method </p>

<p>
[[File:Heatgrid-2022-30.png|600px]] <br/>
</p>

<p>
[[File:Heatgrid-2022-31.png|600px]] <br/>
</p>

<h4>Changes reflected in the UI</h4>

<p>
[[File:Heatgrid-2022-40.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-41.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-43.png|600px]] <br/>
</p>

<h4> Manual Testing </h4>

<pre>
Scenario: Visibility of all the unchecked metric checkboxes in View Scores view
Given user has logged in
When user visits View Scores page
Then all the unchecked metric checkboxes are present above the heat grid
</pre>

<pre>
Scenario: Default invisibility of metric columns in View Scores view
Given user has logged in
When user visits View Scores page
Then metric columns are not visible in the heat grid
</pre>

<pre>
Scenario: Checking a metric checkbox displays the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on unchecked comments#10 metric
Then column with column name " comments#10" gets displayed with corresponding values
</pre>

<pre>
Scenario: Unchecking a metric checkbox hides the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on checked comments#10 metric
Then column with column name " comments#10" and corresponding values get hidden
</pre>

<h4> Unit Testing </h4>
<p>As our project does not deal with actually adding new metrics, but just facilitating a low-coupling addition of new metrics, we need not add any unit test cases for metric implementations. There is only one metric in the system as of now for which test cases are already written.</p>

<h2>Implementation of Issue 2019</h2>
<p> This issue encompasses many problems such as review reports not displaying correctly and a user being able to review his/her work. Each problem has been dealt with individually. Main problems identified as part of this issue and relevant observations and corrections are jotted down in this section. </p>

<h3> Problem 1 : A user being able to review his/her own work.</h3>

<h4> Problem comment </h4>
<p> On Madeup Problem 3, assignment 1055, there are several anomalies in the review report. User 9277 reviewed Team_2323 and gave this comment: "This question seems a little suspicious. It is nearly identical to Question 4a on page 327 in the 2016 edition book. The only thing change was variable name A to B and value 2 to 3." However, according to the View Submissions page, User 9277 is the only member of Team_2323. </p>

<h4> Issue Reproduction and Observations </h4>
<p> We tried reproducing the issue as specified in the issue comment, but we could not find Madeup Problem 3, assignment 1055. So, we have created two assignments with different parameters to check if the instructor is able to assign a reviewer his/her own work. </p>

<p> We have created an assignment "Noself review" with allow self review option unchecked. Then, from the instructor page, we have created a team with student13 and student 14 as teammates. Then we logged into student14 account and submitted a hyperlink for that assignment. After that, from the instructor page we clicked on the assign review button and tried assigning student13 as the reviewer for that work and then tried the same with student14. In both the cases, the assignment failed by rendering a flash error message, "You cannot assign this student to review his/her own artifact." </p>
<ul>
<li> Unchecked allow self-review option in "Noself review" assignment </li>
[[File:self-review-option-unchecked.png|600px]]<br/>

<li> Participants page containing add reviewer button </li>
[[File:Duo-team-submission.png|600px]]<br/>

<li> Adding student13 as reviewer for his/her own work </li>
[[File:Self-assign-review.png|600px]]<br/>

<li> Flash error message displayed</li>
[[File:self-review-unchecked.png|600px]]<br/>
</ul>
<p> We followed the same process for "self_review assignment", which gave student an option to self review his/her own work immediately after submitting their work. However, when the instructor tried assigning the user with his/her own work, same flash error message was displayed, not allowing the user to review their work.</p>

<li> Checked allow self-review option in "self_review assignment" </li>
[[File:Self-review-checked.png|600px]]<br/>

<li> Participants page of self review assignment</li>
[[File:Participants_page_for_self-review_assignment.png|600px]]<br/>

<li> Assigning student13 as reviewer for own work</li>
[[File:Student-13-self-review.png|600px]]<br/>

<li> Display of error message after assigning own artifact</li>
[[File: Error-message-checked.png|600px]]<br/>

<h4> Test case added</h4>
<p> Previously implemented test cases of review_map controller have covered most of the tests pertaining to a user being assigned review work for his own artifact. These test cases primarily focused on the add_reviewer function of the review_mapping controller. However a test case checking for the display of flash error message on trying to assign reviewer to his/her own work was not covered, which we have added in the respective spec file. /p>

<pre>
Scenario: Display of flash error message when instructor tries student their own artifact for reviewing
Given instructor has logged in
When the instructor visits the assignment page and
When the instructor clicks on assign reviewer for an assignment and
when the instructor tries to assign the owner of the artifact as the reviewer
Then a flash error message is displayed saying "You cannot assign this student to review his/her own artifact."
</pre>

<pre>
context 'when instructor tries to assign a student their own artifact for reviewing' do
it 'flashes an error message' do
allow(TeamsUser).to receive(:exists?).with(team_id: '1', user_id: 1).and_return(true)
post :add_reviewer, @params
expect(flash[:error]).to eq('You cannot assign this student to review his/her own artifact.')
expect(response).to redirect_to '/review_mapping/list_mappings?id=1'
end
end
</pre>

<h2> Important Links </h2>
* GitHub repository link: https://github.com/EshwarCVS/expertiza
* Project Description Document: https://docs.google.com/document/d/1H0BjzMBz5it7Wckhegq4LXhMi8RVctTwVzP2x9gnFCo/edit#heading=h.tqdrrd12xs4x
* GitHub Issue #1869: https://github.com/expertiza/expertiza/issues/1869
* GitHub Issue #2019: https://github.com/expertiza/expertiza/issues/2019

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-05-02T03:28:16Z

Gkogant:

This page provides information about the documentation of E2241: Heatgrid fixes and improvements as part of CSC/ECE 517 Spring 2022 Final project.
__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
*Nicholas Himes (nnhimes)
<h3> Team Members (PinkPatterns) </h3>
* Eshwar Chandra Vidhyasagar Thedla (ethedla)
* Gokul Krishna Koganti (gkogant)
* Jyothi Sumer Goud Maduru (jmaduru)
* Suneha Bose (sbose2)

<h2> Heat Grid </h2>

Heat Grid refers to a part of view in Expertiza that shows review scores of all the reviews done for a particular assignment. It shows scores given for each rubric by peer reviewers. This is used by instructors to assign scores to individual assignments and by students to view review scores of their assignment. Our project scope involves dealing with fixing issues related to the heat grid and any subsequent bugs that might arrive.

<h2> Issues identified </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work</h3>
<p> There are some instances where a student was shown as reviewing his/her team even though the "Allow Self Review" checkbox was not checked by the instructor. This situation should not arise for practical purposes. Test cases must be extensively added so that we can be notified if the bug occurs again. </p>

[[File:Screen Shot 2022-04-06 at 10.37.56 PM.png|center|450px]]

<h3> Issue #1869: Deal with the metrics of the heat grid</h3>
<p> <b>metric-1</b> column name in the heat grid follows bad naming convention. It doesn't explain what the column refers to. This must be changed to make the column name more apt.</p>
<p> As of now, the heat grid uses only one metric (metric-1). We must facilitate the system for addition of new metrics. Instructors should be able to toggle between various metrics as per their preferences. This can be done by the use of a drop down menu.</p>

[[File:Screen Shot 2022-04-06 at 10.34.47 PM.png|center|550px]]

<h2> Design Principle </h2>
<p>
For Issue #1869 we plan to use the Factory Design Pattern since we are dealing with the creation of multiple kinds of metrics. As part of our implementation, we plan on using a metric interface, which can be implemented by different concrete metric classes. A factory class acts as a middleman between the implementations and the main class that instantiates the objects. Based on the instructor's selection, the main class requests the metric object from the factory class, rather than dealing with the creation logic on its own. This pattern, therefore, enforces encapsulation and results in the low coupling, the principle which is our primary target for this project scope.
</p>
<p>
The previous implementation has dealt with issue #1869. But the drawback with the implementation is that it renders a code that is highly coupled. Whenever a new metric is added two files (assignments/edit/_general.html.erb and grades/view_team.html.erb) are to be changed, resulting in high coupling. As a consequence, tests pertaining to the highly coupled codes require new tests as a new metric is added. This is undesirable. So, the principle of low coupling is the main focus of our implementation. This principle will enable a common set of tests that would be valid for any number of metrics that will potentially be added in the future.
</p>
<h2> Files to be targeted </h2>

<h3>Issue #2019</h3>
<p> Test file for adding test cases to implement self-reviews checks </p>
* spec/controllers/grades_controller_spec.rb

<h3>Issue #1869</h3>
<p>For Heat grid view</p>
* app/views/grades/_view_heatgrid.html.erb
* app/views/grades/view_team.html.erb
* app/helpers/grades_helper.rb
* app/controllers/grades_controller.rb
* app/models/vm_question_response.rb
* app/models/vm_question_row.rb
* assets/view_team_in_grades.js
<p>For Assignment view</p>
* app/views/assignment/edit/_general.html.erb
* app/controllers/assignments_controller.rb

<h2> Implementation of Issue 1869</h2>

<h3> Previous team’s implementation </h3>

<p> The previous team has dealt with the issue by changing “metric-1” to “verbose comment count”, which is relevant to what metric-1 refers to. For the latter half of the issue, they have provided a metric dropdown for the instructor to select while creating the assignment. This consequently requires only one metric to be displayed on the heat grid for which they’ve given a toggle option to show and hide the metric.
</p>

<h4> Changes reflected in the UI </h4>

<ul>
<li> <b> metric-1 </b> changed to verbose comment count </li>
[[File:Heatgrid-metric.png|600px]]

<li> Metric dropdown provided while creating an assignment </li>
[[File:Assignment General page.png|600px]]

</ul>

<h4> Issue with previous team's implementation </h4>

<p> The critical problem with their changes was, when in future a new metric is added, it forces a change in two view files: one time in assignments/edit/_general.html.erb and two times in grades/view_team.html.erb. Requiring these changes in view files that have little relevance to the heat grid is essentially causing high coupling. </p>

<h3> Current implementation </h3>

<h4> Issue Goal </h4>
<p> Our mentor has required us to display metrics in the heat grid with a toggle option for the user to select only the required metrics according to their preferences. This should be done keeping in mind low coupling as the primary design goal. These changes should be accompanied by minor changes such as adding comments and changing the name of “metric-1” to a self-indicative name. </p>

<h4> Implementation details </h4>
<p>
In the original beta implementation, whenever the relevant view file is loaded, it is calling the method "populate_view_model" present in the "grades_controller.rb" file. This method, is explicitly calling another model method to calculate metric. Whenever a new metric is added, we will have to make a call to that metric in the populate view model. This is not ideal as each new metric added is introducing a new line of code in the controller body. It is also not possible to determine the metrics present dynamically. To deal with this problem, we introduced a new parent method "calculate_metrics" in model file "vm_question_response.rb". This method is responsible for calling other individual methods that calculate metrics. The call to this method is replacing the explicit calls to metric calculation in the controller. This essentially is breaking the dependency between new metric introduction and the controller. Now, whenever a new metric is added, there is no need to introduce any code changes in the controller, instead we just have to change the code in relevant model file.
</p>
<p>
[[File:Heatgrid-2022-10.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-11.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-13.png|600px]] <br/>
</p>

<p>A new hashmap is introduced to store the values of the metrics in the form of key value pairs. Instead of explicitly calling metrics by name in the view file, this hashmap is used to iterate over the metrics and displayed</p>

<p>
[[File:Heatgrid-2022-20.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-21.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-22.png|600px]] <br/>
</p>

Toggle feature is implemented in "view_team_in_grades.js" file. When the checkbox is clicked, function in javascript file is called and appropriate elements are hidden.

<p>
[[File:Heatgrid-2022-23.png|600px]] <br/>
</p>

<h4> Adding a new metric in future </h4>

<p> To introduce new metric, a new method should be added in "vm_question_response.rb" file. This newly added method should be called from "calculate_metrics" method </p>

<p>
[[File:Heatgrid-2022-30.png|600px]] <br/>
</p>

<p>
[[File:Heatgrid-2022-31.png|600px]] <br/>
</p>

<h4>Changes reflected in the UI</h4>

<p>
[[File:Heatgrid-2022-40.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-41.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-43.png|600px]] <br/>
</p>

<h4> Manual Testing </h4>

<pre>
Scenario: Visibility of all the unchecked metric checkboxes in View Scores view
Given user has logged in
When user visits View Scores page
Then all the unchecked metric checkboxes are present above the heat grid
</pre>

<pre>
Scenario: Default invisibility of metric columns in View Scores view
Given user has logged in
When user visits View Scores page
Then metric columns are not visible in the heat grid
</pre>

<pre>
Scenario: Checking a metric checkbox displays the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on unchecked comments#10 metric
Then column with column name " comments#10" gets displayed with corresponding values
</pre>

<pre>
Scenario: Unchecking a metric checkbox hides the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on checked comments#10 metric
Then column with column name " comments#10" and corresponding values get hidden
</pre>

<h4> Unit Testing </h4>
<p>As our project does not deal with actually adding new metrics, but just facilitating a low-coupling addition of new metrics, we need not add any unit test cases for metric implementations. There is only one metric in the system as of now for which test cases are already written.</p>

<h2>Implementation of Issue 2019</h2>
<p> This issue encompasses many problems such as review reports not displaying correctly and a user being able to review his/her work. Each problem has been dealt with individually. Main problems identified as part of this issue and relevant observations and corrections are jotted down in this section. </p>

<h3> Problem 1 : A user being able to review his/her own work.</h3>

<h4> Problem comment </h4>
<p> On Madeup Problem 3, assignment 1055, there are several anomalies in the review report. User 9277 reviewed Team_2323 and gave this comment: "This question seems a little suspicious. It is nearly identical to Question 4a on page 327 in the 2016 edition book. The only thing change was variable name A to B and value 2 to 3." However, according to the View Submissions page, User 9277 is the only member of Team_2323. </p>

<h4> Issue Reproduction and Observations </h4>
<p> We tried reproducing the issue as specified in the issue comment, but we could not find Madeup Problem 3, assignment 1055. So, we have created two assignments with different parameters to check if the instructor is able to assign a reviewer his/her own work. </p>

<p> We have created an assignment "Noself review" with allow self review option unchecked. Then, from the instructor page, we have created a team with student13 and student 14 as teammates. Then we logged into student14 account and submitted a hyperlink for that assignment. After that, from the instructor page we clicked on the assign review button and tried assigning student13 as the reviewer for that work and then tried the same with student14. In both the cases, the assignment failed by rendering a flash error message, "You cannot assign this student to review his/her own artifact." </p>
<ul>
<li> Unchecked allow self-review option in "Noself review" assignment </li>
[[File:self-review-option-unchecked.png|600px]]<br/>

<li> Participants page containing add reviewer button </li>
[[File:Duo-team-submission.png|600px]]<br/>

<li> Adding student13 as reviewer for his/her own work </li>
[[File:Self-assign-review.png|600px]]<br/>

<li> Flash error message displayed</li>
[[File:self-review-unchecked.png|600px]]<br/>
</ul>
<p> We followed the same process for "self_review assignment", which gave student an option to self review his/her own work immediately after submitting their work. However, when the instructor tried assigning the user with his/her own work, same flash error message was displayed, not allowing the user to review their work.</p>

<li> Checked allow self-review option in "self_review assignment" </li>
[[File:Self-review-checked.png|600px]]<br/>

<li> Participants page of self review assignment</li>
[[File:Participants_page_for_self-review_assignment.png|600px]]<br/>

<li> Assigning student13 as reviewer for own work</li>
[[File:Student-13-self-review.png|600px]]<br/>

<li> Display of error message after assigning own artifact</li>
[[File:Error-message-checked.png.png|600px]]<br/>

<h4> Test case added</h4>
<p> Previously implemented test cases of review_map controller have covered most of the tests pertaining to a user being assigned review work for his own artifact. These test cases primarily focused on the add_reviewer function of the review_mapping controller. However a test case checking for the display of flash error message on trying to assign reviewer to his/her own work was not covered, which we have added in the respective spec file. /p>

<pre>
Scenario: Display of flash error message when instructor tries student their own artifact for reviewing
Given instructor has logged in
When the instructor visits the assignment page and
When the instructor clicks on assign reviewer for an assignment and
when the instructor tries to assign the owner of the artifact as the reviewer
Then a flash error message is displayed saying "You cannot assign this student to review his/her own artifact."
</pre>

<pre>
context 'when instructor tries to assign a student their own artifact for reviewing' do
it 'flashes an error message' do
allow(TeamsUser).to receive(:exists?).with(team_id: '1', user_id: 1).and_return(true)
post :add_reviewer, @params
expect(flash[:error]).to eq('You cannot assign this student to review his/her own artifact.')
expect(response).to redirect_to '/review_mapping/list_mappings?id=1'
end
end
</pre>

<h2> Important Links </h2>
* GitHub repository link: https://github.com/EshwarCVS/expertiza
* Project Description Document: https://docs.google.com/document/d/1H0BjzMBz5it7Wckhegq4LXhMi8RVctTwVzP2x9gnFCo/edit#heading=h.tqdrrd12xs4x
* GitHub Issue #1869: https://github.com/expertiza/expertiza/issues/1869
* GitHub Issue #2019: https://github.com/expertiza/expertiza/issues/2019

File:Student-13-self-review.png

2022-05-02T03:27:55Z

Gkogant:

File:Error-message-checked.png

2022-05-02T03:27:18Z

Gkogant:

File:Participants page for self-review assignment.png

2022-05-02T03:24:59Z

Gkogant:

File:Self-review-checked.png

2022-05-02T03:19:20Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-05-02T03:12:53Z

Gkogant:

This page provides information about the documentation of E2241: Heatgrid fixes and improvements as part of CSC/ECE 517 Spring 2022 Final project.
__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
*Nicholas Himes (nnhimes)
<h3> Team Members (PinkPatterns) </h3>
* Eshwar Chandra Vidhyasagar Thedla (ethedla)
* Gokul Krishna Koganti (gkogant)
* Jyothi Sumer Goud Maduru (jmaduru)
* Suneha Bose (sbose2)

<h2> Heat Grid </h2>

Heat Grid refers to a part of view in Expertiza that shows review scores of all the reviews done for a particular assignment. It shows scores given for each rubric by peer reviewers. This is used by instructors to assign scores to individual assignments and by students to view review scores of their assignment. Our project scope involves dealing with fixing issues related to the heat grid and any subsequent bugs that might arrive.

<h2> Issues identified </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work</h3>
<p> There are some instances where a student was shown as reviewing his/her team even though the "Allow Self Review" checkbox was not checked by the instructor. This situation should not arise for practical purposes. Test cases must be extensively added so that we can be notified if the bug occurs again. </p>

[[File:Screen Shot 2022-04-06 at 10.37.56 PM.png|center|450px]]

<h3> Issue #1869: Deal with the metrics of the heat grid</h3>
<p> <b>metric-1</b> column name in the heat grid follows bad naming convention. It doesn't explain what the column refers to. This must be changed to make the column name more apt.</p>
<p> As of now, the heat grid uses only one metric (metric-1). We must facilitate the system for addition of new metrics. Instructors should be able to toggle between various metrics as per their preferences. This can be done by the use of a drop down menu.</p>

[[File:Screen Shot 2022-04-06 at 10.34.47 PM.png|center|550px]]

<h2> Design Principle </h2>
<p>
For Issue #1869 we plan to use the Factory Design Pattern since we are dealing with the creation of multiple kinds of metrics. As part of our implementation, we plan on using a metric interface, which can be implemented by different concrete metric classes. A factory class acts as a middleman between the implementations and the main class that instantiates the objects. Based on the instructor's selection, the main class requests the metric object from the factory class, rather than dealing with the creation logic on its own. This pattern, therefore, enforces encapsulation and results in the low coupling, the principle which is our primary target for this project scope.
</p>
<p>
The previous implementation has dealt with issue #1869. But the drawback with the implementation is that it renders a code that is highly coupled. Whenever a new metric is added two files (assignments/edit/_general.html.erb and grades/view_team.html.erb) are to be changed, resulting in high coupling. As a consequence, tests pertaining to the highly coupled codes require new tests as a new metric is added. This is undesirable. So, the principle of low coupling is the main focus of our implementation. This principle will enable a common set of tests that would be valid for any number of metrics that will potentially be added in the future.
</p>
<h2> Files to be targeted </h2>

<h3>Issue #2019</h3>
<p> Test file for adding test cases to implement self-reviews checks </p>
* spec/controllers/grades_controller_spec.rb

<h3>Issue #1869</h3>
<p>For Heat grid view</p>
* app/views/grades/_view_heatgrid.html.erb
* app/views/grades/view_team.html.erb
* app/helpers/grades_helper.rb
* app/controllers/grades_controller.rb
* app/models/vm_question_response.rb
* app/models/vm_question_row.rb
* assets/view_team_in_grades.js
<p>For Assignment view</p>
* app/views/assignment/edit/_general.html.erb
* app/controllers/assignments_controller.rb

<h2> Implementation of Issue 1869</h2>

<h3> Previous team’s implementation </h3>

<p> The previous team has dealt with the issue by changing “metric-1” to “verbose comment count”, which is relevant to what metric-1 refers to. For the latter half of the issue, they have provided a metric dropdown for the instructor to select while creating the assignment. This consequently requires only one metric to be displayed on the heat grid for which they’ve given a toggle option to show and hide the metric.
</p>

<h4> Changes reflected in the UI </h4>

<ul>
<li> <b> metric-1 </b> changed to verbose comment count </li>
[[File:Heatgrid-metric.png|600px]]

<li> Metric dropdown provided while creating an assignment </li>
[[File:Assignment General page.png|600px]]

</ul>

<h4> Issue with previous team's implementation </h4>

<p> The critical problem with their changes was, when in future a new metric is added, it forces a change in two view files: one time in assignments/edit/_general.html.erb and two times in grades/view_team.html.erb. Requiring these changes in view files that have little relevance to the heat grid is essentially causing high coupling. </p>

<h3> Current implementation </h3>

<h4> Issue Goal </h4>
<p> Our mentor has required us to display metrics in the heat grid with a toggle option for the user to select only the required metrics according to their preferences. This should be done keeping in mind low coupling as the primary design goal. These changes should be accompanied by minor changes such as adding comments and changing the name of “metric-1” to a self-indicative name. </p>

<h4> Implementation details </h4>
<p>
In the original beta implementation, whenever the relevant view file is loaded, it is calling the method "populate_view_model" present in the "grades_controller.rb" file. This method, is explicitly calling another model method to calculate metric. Whenever a new metric is added, we will have to make a call to that metric in the populate view model. This is not ideal as each new metric added is introducing a new line of code in the controller body. It is also not possible to determine the metrics present dynamically. To deal with this problem, we introduced a new parent method "calculate_metrics" in model file "vm_question_response.rb". This method is responsible for calling other individual methods that calculate metrics. The call to this method is replacing the explicit calls to metric calculation in the controller. This essentially is breaking the dependency between new metric introduction and the controller. Now, whenever a new metric is added, there is no need to introduce any code changes in the controller, instead we just have to change the code in relevant model file.
</p>
<p>
[[File:Heatgrid-2022-10.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-11.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-13.png|600px]] <br/>
</p>

<p>A new hashmap is introduced to store the values of the metrics in the form of key value pairs. Instead of explicitly calling metrics by name in the view file, this hashmap is used to iterate over the metrics and displayed</p>

<p>
[[File:Heatgrid-2022-20.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-21.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-22.png|600px]] <br/>
</p>

Toggle feature is implemented in "view_team_in_grades.js" file. When the checkbox is clicked, function in javascript file is called and appropriate elements are hidden.

<p>
[[File:Heatgrid-2022-23.png|600px]] <br/>
</p>

<h4> Adding a new metric in future </h4>

<p> To introduce new metric, a new method should be added in "vm_question_response.rb" file. This newly added method should be called from "calculate_metrics" method </p>

<p>
[[File:Heatgrid-2022-30.png|600px]] <br/>
</p>

<p>
[[File:Heatgrid-2022-31.png|600px]] <br/>
</p>

<h4>Changes reflected in the UI</h4>

<p>
[[File:Heatgrid-2022-40.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-41.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-43.png|600px]] <br/>
</p>

<h4> Manual Testing </h4>

<pre>
Scenario: Visibility of all the unchecked metric checkboxes in View Scores view
Given user has logged in
When user visits View Scores page
Then all the unchecked metric checkboxes are present above the heat grid
</pre>

<pre>
Scenario: Default invisibility of metric columns in View Scores view
Given user has logged in
When user visits View Scores page
Then metric columns are not visible in the heat grid
</pre>

<pre>
Scenario: Checking a metric checkbox displays the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on unchecked comments#10 metric
Then column with column name " comments#10" gets displayed with corresponding values
</pre>

<pre>
Scenario: Unchecking a metric checkbox hides the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on checked comments#10 metric
Then column with column name " comments#10" and corresponding values get hidden
</pre>

<h4> Unit Testing </h4>
<p>As our project does not deal with actually adding new metrics, but just facilitating a low-coupling addition of new metrics, we need not add any unit test cases for metric implementations. There is only one metric in the system as of now for which test cases are already written.</p>

<h2>Implementation of Issue 2019</h2>
<p> This issue encompasses many problems such as review reports not displaying correctly and a user being able to review his/her work. Each problem has been dealt with individually. Main problems identified as part of this issue and relevant observations and corrections are jotted down in this section. </p>

<h3> Problem 1 : A user being able to review his/her own work.</h3>

<h4> Problem comment </h4>
<p> On Madeup Problem 3, assignment 1055, there are several anomalies in the review report. User 9277 reviewed Team_2323 and gave this comment: "This question seems a little suspicious. It is nearly identical to Question 4a on page 327 in the 2016 edition book. The only thing change was variable name A to B and value 2 to 3." However, according to the View Submissions page, User 9277 is the only member of Team_2323. </p>

<h4> Issue Reproduction and Observations </h4>
<p> We tried reproducing the issue as specified in the issue comment, but we could not find Madeup Problem 3, assignment 1055. So, we have created two assignments with different parameters to check if the instructor is able to assign a reviewer his/her own work. </p>

<p> We have created an assignment "Noself review" with allow self review option unchecked. Then, from the instructor page, we have created a team with student13 and student 14 as teammates. Then we logged into student14 account and submitted a hyperlink for that assignment. After that, from the instructor page we clicked on the assign review button and tried assigning student13 as the reviewer for that work and then tried the same with student14. In both the cases, the assignment failed by rendering a flash error message, "You cannot assign this student to review his/her own artifact." </p>
<ul>
<li> Unchecked allow self-review option in "Noself review" assignment </li>
[[File:self-review-option-unchecked.png|600px]]<br/>

<li> Participants page containing add reviewer button </li>
[[File:Duo-team-submission.png|600px]]<br/>

<li> Adding student13 as reviewer for his/her own work </li>
[[File:Self-assign-review.png|600px]]<br/>

<li> Flash error message displayed</li>
[[File:self-review-unchecked.png|600px]]<br/>
</ul>
<p> We followed the same process for "self review" assignment, which gave student an option to self review his/her own work immediately after submitting their work. However, when the instructor tried assigning the user with his/her own work, same flash error message was displayed, not allowing the user to review their work.</p>

<h4> Test case added</h4>
<p> Previously implemented test cases of review_map controller have covered most of the tests pertaining to a user being assigned review work for his own artifact. These test cases primarily focused on the add_reviewer function of the review_mapping controller. However a test case checking for the display of flash error message on trying to assign reviewer to his/her own work was not covered, which we have added in the respective spec file. /p>

<pre>
Scenario: Display of flash error message when instructor tries student their own artifact for reviewing
Given instructor has logged in
When the instructor visits the assignment page and
When the instructor clicks on assign reviewer for an assignment and
when the instructor tries to assign the owner of the artifact as the reviewer
Then a flash error message is displayed saying "You cannot assign this student to review his/her own artifact."
</pre>

<pre>
context 'when instructor tries to assign a student their own artifact for reviewing' do
it 'flashes an error message' do
allow(TeamsUser).to receive(:exists?).with(team_id: '1', user_id: 1).and_return(true)
post :add_reviewer, @params
expect(flash[:error]).to eq('You cannot assign this student to review his/her own artifact.')
expect(response).to redirect_to '/review_mapping/list_mappings?id=1'
end
end
</pre>

<h2> Important Links </h2>
* GitHub repository link: https://github.com/EshwarCVS/expertiza
* Project Description Document: https://docs.google.com/document/d/1H0BjzMBz5it7Wckhegq4LXhMi8RVctTwVzP2x9gnFCo/edit#heading=h.tqdrrd12xs4x
* GitHub Issue #1869: https://github.com/expertiza/expertiza/issues/1869
* GitHub Issue #2019: https://github.com/expertiza/expertiza/issues/2019

File:Self-assign-review.png

2022-05-02T03:10:01Z

Gkogant:

File:Duo-team-submission.png

2022-05-02T03:06:20Z

Gkogant:

File:Self-review-option-unchecked.png

2022-05-02T03:03:02Z

Gkogant:

File:Self-review-unchecked.png

2022-05-02T02:56:30Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-05-02T02:52:18Z

Gkogant:

This page provides information about the documentation of E2241: Heatgrid fixes and improvements as part of CSC/ECE 517 Spring 2022 Final project.
__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
*Nicholas Himes (nnhimes)
<h3> Team Members (PinkPatterns) </h3>
* Eshwar Chandra Vidhyasagar Thedla (ethedla)
* Gokul Krishna Koganti (gkogant)
* Jyothi Sumer Goud Maduru (jmaduru)
* Suneha Bose (sbose2)

<h2> Heat Grid </h2>

Heat Grid refers to a part of view in Expertiza that shows review scores of all the reviews done for a particular assignment. It shows scores given for each rubric by peer reviewers. This is used by instructors to assign scores to individual assignments and by students to view review scores of their assignment. Our project scope involves dealing with fixing issues related to the heat grid and any subsequent bugs that might arrive.

<h2> Issues identified </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work</h3>
<p> There are some instances where a student was shown as reviewing his/her team even though the "Allow Self Review" checkbox was not checked by the instructor. This situation should not arise for practical purposes. Test cases must be extensively added so that we can be notified if the bug occurs again. </p>

[[File:Screen Shot 2022-04-06 at 10.37.56 PM.png|center|450px]]

<h3> Issue #1869: Deal with the metrics of the heat grid</h3>
<p> <b>metric-1</b> column name in the heat grid follows bad naming convention. It doesn't explain what the column refers to. This must be changed to make the column name more apt.</p>
<p> As of now, the heat grid uses only one metric (metric-1). We must facilitate the system for addition of new metrics. Instructors should be able to toggle between various metrics as per their preferences. This can be done by the use of a drop down menu.</p>

[[File:Screen Shot 2022-04-06 at 10.34.47 PM.png|center|550px]]

<h2> Design Principle </h2>
<p>
For Issue #1869 we plan to use the Factory Design Pattern since we are dealing with the creation of multiple kinds of metrics. As part of our implementation, we plan on using a metric interface, which can be implemented by different concrete metric classes. A factory class acts as a middleman between the implementations and the main class that instantiates the objects. Based on the instructor's selection, the main class requests the metric object from the factory class, rather than dealing with the creation logic on its own. This pattern, therefore, enforces encapsulation and results in the low coupling, the principle which is our primary target for this project scope.
</p>
<p>
The previous implementation has dealt with issue #1869. But the drawback with the implementation is that it renders a code that is highly coupled. Whenever a new metric is added two files (assignments/edit/_general.html.erb and grades/view_team.html.erb) are to be changed, resulting in high coupling. As a consequence, tests pertaining to the highly coupled codes require new tests as a new metric is added. This is undesirable. So, the principle of low coupling is the main focus of our implementation. This principle will enable a common set of tests that would be valid for any number of metrics that will potentially be added in the future.
</p>
<h2> Files to be targeted </h2>

<h3>Issue #2019</h3>
<p> Test file for adding test cases to implement self-reviews checks </p>
* spec/controllers/grades_controller_spec.rb

<h3>Issue #1869</h3>
<p>For Heat grid view</p>
* app/views/grades/_view_heatgrid.html.erb
* app/views/grades/view_team.html.erb
* app/helpers/grades_helper.rb
* app/controllers/grades_controller.rb
* app/models/vm_question_response.rb
* app/models/vm_question_row.rb
* assets/view_team_in_grades.js
<p>For Assignment view</p>
* app/views/assignment/edit/_general.html.erb
* app/controllers/assignments_controller.rb

<h2> Implementation of Issue 1869</h2>

<h3> Previous team’s implementation </h3>

<p> The previous team has dealt with the issue by changing “metric-1” to “verbose comment count”, which is relevant to what metric-1 refers to. For the latter half of the issue, they have provided a metric dropdown for the instructor to select while creating the assignment. This consequently requires only one metric to be displayed on the heat grid for which they’ve given a toggle option to show and hide the metric.
</p>

<h4> Changes reflected in the UI </h4>

<ul>
<li> <b> metric-1 </b> changed to verbose comment count </li>
[[File:Heatgrid-metric.png|600px]]

<li> Metric dropdown provided while creating an assignment </li>
[[File:Assignment General page.png|600px]]

</ul>

<h4> Issue with previous team's implementation </h4>

<p> The critical problem with their changes was, when in future a new metric is added, it forces a change in two view files: one time in assignments/edit/_general.html.erb and two times in grades/view_team.html.erb. Requiring these changes in view files that have little relevance to the heat grid is essentially causing high coupling. </p>

<h3> Current implementation </h3>

<h4> Issue Goal </h4>
<p> Our mentor has required us to display metrics in the heat grid with a toggle option for the user to select only the required metrics according to their preferences. This should be done keeping in mind low coupling as the primary design goal. These changes should be accompanied by minor changes such as adding comments and changing the name of “metric-1” to a self-indicative name. </p>

<h4> Implementation details </h4>
<p>
In the original beta implementation, whenever the relevant view file is loaded, it is calling the method "populate_view_model" present in the "grades_controller.rb" file. This method, is explicitly calling another model method to calculate metric. Whenever a new metric is added, we will have to make a call to that metric in the populate view model. This is not ideal as each new metric added is introducing a new line of code in the controller body. It is also not possible to determine the metrics present dynamically. To deal with this problem, we introduced a new parent method "calculate_metrics" in model file "vm_question_response.rb". This method is responsible for calling other individual methods that calculate metrics. The call to this method is replacing the explicit calls to metric calculation in the controller. This essentially is breaking the dependency between new metric introduction and the controller. Now, whenever a new metric is added, there is no need to introduce any code changes in the controller, instead we just have to change the code in relevant model file.
</p>
<p>
[[File:Heatgrid-2022-10.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-11.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-13.png|600px]] <br/>
</p>

<p>A new hashmap is introduced to store the values of the metrics in the form of key value pairs. Instead of explicitly calling metrics by name in the view file, this hashmap is used to iterate over the metrics and displayed</p>

<p>
[[File:Heatgrid-2022-20.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-21.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-22.png|600px]] <br/>
</p>

Toggle feature is implemented in "view_team_in_grades.js" file. When the checkbox is clicked, function in javascript file is called and appropriate elements are hidden.

<p>
[[File:Heatgrid-2022-23.png|600px]] <br/>
</p>

<h4> Adding a new metric in future </h4>

<p> To introduce new metric, a new method should be added in "vm_question_response.rb" file. This newly added method should be called from "calculate_metrics" method </p>

<p>
[[File:Heatgrid-2022-30.png|600px]] <br/>
</p>

<p>
[[File:Heatgrid-2022-31.png|600px]] <br/>
</p>

<h4>Changes reflected in the UI</h4>

<p>
[[File:Heatgrid-2022-40.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-41.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-43.png|600px]] <br/>
</p>

<h4> Manual Testing </h4>

<pre>
Scenario: Visibility of all the unchecked metric checkboxes in View Scores view
Given user has logged in
When user visits View Scores page
Then all the unchecked metric checkboxes are present above the heat grid
</pre>

<pre>
Scenario: Default invisibility of metric columns in View Scores view
Given user has logged in
When user visits View Scores page
Then metric columns are not visible in the heat grid
</pre>

<pre>
Scenario: Checking a metric checkbox displays the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on unchecked comments#10 metric
Then column with column name " comments#10" gets displayed with corresponding values
</pre>

<pre>
Scenario: Unchecking a metric checkbox hides the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on checked comments#10 metric
Then column with column name " comments#10" and corresponding values get hidden
</pre>

<h4> Unit Testing </h4>
<p>As our project does not deal with actually adding new metrics, but just facilitating a low-coupling addition of new metrics, we need not add any unit test cases for metric implementations. There is only one metric in the system as of now for which test cases are already written.</p>

<h2>Implementation of Issue 2019</h2>
<p> This issue encompasses many problems such as review reports not displaying correctly and a user being able to review his/her work. Each problem has been dealt with individually. Main problems identified as part of this issue and relevant observations and corrections are jotted down in this section. </p>

<h3> Problem 1 : A user being able to review his/her own work.</h3>

<h4> Problem comment </h4>
<p> On Madeup Problem 3, assignment 1055, there are several anomalies in the review report. User 9277 reviewed Team_2323 and gave this comment: "This question seems a little suspicious. It is nearly identical to Question 4a on page 327 in the 2016 edition book. The only thing change was variable name A to B and value 2 to 3." However, according to the View Submissions page, User 9277 is the only member of Team_2323. </p>

<h4> Issue Reproduction and Observations </h4>
<p> We tried reproducing the issue as specified in the issue comment, but we could not find Madeup Problem 3, assignment 1055. So, we have created two assignments with different parameters to check if the instructor is able to assign a reviewer his/her own work. </p>

<p> We have created an assignment "Noself review" with allow self review option unchecked. Then, from the instructor page, we have created a team with student13 and student 14 as teammates. Then we logged into student14 account and submitted a hyperlink for that assignment. After that, from the instructor page we clicked on the assign review button and tried assigning student13 as the reviewer for that work and then tried the same with student14. In both the cases, the assignment failed by rendering a flash error message, "You cannot assign this student to review his/her own artifact." </p>

<p> We followed the same process for "self review" assignment, which gave student an option to self review his/her own work immediately after submitting their work. However, when the instructor tried assigning the user with his/her own work, same flash error message was displayed, not allowing the user to review their work.</p>

<h4> Test case added</h4>
<p> Previously implemented test cases of review_map controller have covered most of the tests pertaining to a user being assigned review work for his own artifact. These test cases primarily focused on the add_reviewer function of the review_mapping controller. However a test case checking for the display of flash error message on trying to assign reviewer to his/her own work was not covered, which we have added in the respective spec file. /p>

<pre>
Scenario: Display of flash error message when instructor tries student their own artifact for reviewing
Given instructor has logged in
When the instructor visits the assignment page and
When the instructor clicks on assign reviewer for an assignment and
when the instructor tries to assign the owner of the artifact as the reviewer
Then a flash error message is displayed saying "You cannot assign this student to review his/her own artifact."
</pre>

<pre>
context 'when instructor tries to assign a student their own artifact for reviewing' do
it 'flashes an error message' do
allow(TeamsUser).to receive(:exists?).with(team_id: '1', user_id: 1).and_return(true)
post :add_reviewer, @params
expect(flash[:error]).to eq('You cannot assign this student to review his/her own artifact.')
expect(response).to redirect_to '/review_mapping/list_mappings?id=1'
end
end
</pre>

<h2> Important Links </h2>
* GitHub repository link: https://github.com/EshwarCVS/expertiza
* Project Description Document: https://docs.google.com/document/d/1H0BjzMBz5it7Wckhegq4LXhMi8RVctTwVzP2x9gnFCo/edit#heading=h.tqdrrd12xs4x
* GitHub Issue #1869: https://github.com/expertiza/expertiza/issues/1869
* GitHub Issue #2019: https://github.com/expertiza/expertiza/issues/2019

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-05-01T17:41:01Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-05-01T17:39:47Z

Gkogant:

This page provides information about the documentation of E2241: Heatgrid fixes and improvements as part of CSC/ECE 517 Spring 2022 Final project.
__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
*Nicholas Himes (nnhimes)
<h3> Team Members (PinkPatterns) </h3>
* Eshwar Chandra Vidhyasagar Thedla (ethedla)
* Gokul Krishna Koganti (gkogant)
* Jyothi Sumer Goud Maduru (jmaduru)
* Suneha Bose (sbose2)

<h2> Heat Grid </h2>

Heat Grid refers to a part of view in Expertiza that shows review scores of all the reviews done for a particular assignment. It shows scores given for each rubric by peer reviewers. This is used by instructors to assign scores to individual assignments and by students to view review scores of their assignment. Our project scope involves dealing with fixing issues related to the heat grid and any subsequent bugs that might arrive.

<h2> Issues identified </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work</h3>
<p> There are some instances where a student was shown as reviewing his/her team even though the "Allow Self Review" checkbox was not checked by the instructor. This situation should not arise for practical purposes. Test cases must be extensively added so that we can be notified if the bug occurs again. </p>

[[File:Screen Shot 2022-04-06 at 10.37.56 PM.png|center|450px]]

<h3> Issue #1869: Deal with the metrics of the heat grid</h3>
<p> <b>metric-1</b> column name in the heat grid follows bad naming convention. It doesn't explain what the column refers to. This must be changed to make the column name more apt.</p>
<p> As of now, the heat grid uses only one metric (metric-1). We must facilitate the system for addition of new metrics. Instructors should be able to toggle between various metrics as per their preferences. This can be done by the use of a drop down menu.</p>

[[File:Screen Shot 2022-04-06 at 10.34.47 PM.png|center|550px]]

<h2> Plan of work </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work </h3>
<p>Relevant bug of this issue can’t be reproduced to deal with it. So comprehensive test cases must be written to be notified if the bug arises again. We are planning to add rspec unit tests covering the following cases:
</p>
<ul>
<li><b> If the instructor unchecks “ Allow self review” option</b></li>
<ol>
<li> Instructor should not be able to assign a student to review work that he/she has submitted. </li>
<li> Instructor should not be able to assign a student to review work that their teammate has submitted.</li>
<li> Students should not be able to review work he/she has submitted.</li>
<li> Students should not be able to review work a teammate has submitted.</li>
</ol>
<li><b> If the instructor checks “ Allow self review” option</b></li>
<ol>
<li> Instructor should be able to assign a student to review work that he/she has submitted.</li>
<li> Instructor should be able to assign a student to review work that their teammate has submitted.</li>
<li> Students should be able to review work he/she has submitted. </li>
<li> Students should be able to review work a teammate has submitted.</li>
</ol>
</ul>

<h3> Issue #1869: Deal with the metrics of the heat grid </h3>
<p>The new metrics can be added to the Metrics table that we will create. While creating an assignment/ editing an assignment, the instructor can select a metric from the Metrics table which will be available as a dropdown menu. We will retrieve the metric selected for the assignment by the instructor and display it in the Heatgrid Map of reviews.</p>

* In create/edit assignment, the instructor will see ‘Metric Type’ drop down which has list of metrics based on the values in the database
* Save the selected metric type and update the value in the database
* Retrieve the metric type from the assignment and calculate the value of the metric
* Display the values of the metric in the Heatgrid view

<h4> Proposed Control Flow </h4>

[[File:Proposed_Control_Flow.drawio.png]]

<h4>UML Diagram </h4>

[[File:UML diagram E2241.png|center|600px]]

<h2> Design Principle </h2>
<p>
For Issue #1869 we plan to use the Factory Design Pattern since we are dealing with the creation of multiple kinds of metrics. As part of our implementation, we plan on using a metric interface, which can be implemented by different concrete metric classes. A factory class acts as a middleman between the implementations and the main class that instantiates the objects. Based on the instructor's selection, the main class requests the metric object from the factory class, rather than dealing with the creation logic on its own. This pattern, therefore, enforces encapsulation and results in the low coupling, the principle which is our primary target for this project scope.
</p>
<p>
The previous implementation has dealt with issue #1869. But the drawback with the implementation is that it renders a code that is highly coupled. Whenever a new metric is added two files (assignments/edit/_general.html.erb and grades/view_team.html.erb) are to be changed, resulting in high coupling. As a consequence, tests pertaining to the highly coupled codes require new tests as a new metric is added. This is undesirable. So, the principle of low coupling is the main focus of our implementation. This principle will enable a common set of tests that would be valid for any number of metrics that will potentially be added in the future.
</p>
<h2> Files to be targeted </h2>

<h3>Issue #2019</h3>
<p> Test file for adding test cases to implement self-reviews checks </p>
* spec/controllers/grades_controller_spec.rb

<h3>Issue #1869</h3>
<p>For Heat grid view</p>
* app/views/grades/_view_heatgrid.html.erb
* app/views/grades/view_team.html.erb
* app/helpers/grades_helper.rb
* app/controllers/grades_controller.rb
* app/models/vm_question_response.rb
* app/models/vm_question_row.rb
* assets/view_team_in_grades.js
<p>For Assignment view</p>
* app/views/assignment/edit/_general.html.erb
* app/controllers/assignments_controller.rb

<h2> Implementation of Issue 1869</h2>

<h3> Previous team’s implementation </h3>

<p> The previous team has dealt with the issue by changing “metric-1” to “verbose comment count”, which is relevant to what metric-1 refers to. For the latter half of the issue, they have provided a metric dropdown for the instructor to select while creating the assignment. This consequently requires only one metric to be displayed on the heat grid for which they’ve given a toggle option to show and hide the metric.
</p>

<h4> Changes reflected in the UI </h4>

<ul>
<li> <b> metric-1 </b> changed to verbose comment count </li>
[[File:Heatgrid-metric.png|600px]]

<li> Metric dropdown provided while creating an assignment </li>
[[File:Assignment General page.png|600px]]

</ul>

<h4> Issue with previous team's implementation </h4>

<p> The critical problem with their changes was, when in future a new metric is added, it forces a change in two view files: one time in assignments/edit/_general.html.erb and two times in grades/view_team.html.erb. Requiring these changes in view files that have little relevance to the heat grid is essentially causing high coupling. </p>

<h3> Current implementation </h3>

<h4> Issue Goal </h4>
<p> Our mentor has required us to display metrics in the heat grid with a toggle option for the user to select only the required metrics according to their preferences. This should be done keeping in mind low coupling as the primary design goal. These changes should be accompanied by minor changes such as adding comments and changing the name of “metric-1” to a self-indicative name. </p>

<h4> Implementation details </h4>
<p>
In the original beta implementation, whenever the relevant view file is loaded, it is calling the method "populate_view_model" present in the "grades_controller.rb" file. This method, is explicitly calling another model method to calculate metric. Whenever a new metric is added, we will have to make a call to that metric in the populate view model. This is not ideal as each new metric added is introducing a new line of code in the controller body. It is also not possible to determine the metrics present dynamically. To deal with this problem, we introduced a new parent method "calculate_metrics" in model file "vm_question_response.rb". This method is responsible for calling other individual methods that calculate metrics. The call to this method is replacing the explicit calls to metric calculation in the controller. This essentially is breaking the dependency between new metric introduction and the controller. Now, whenever a new metric is added, there is no need to introduce any code changes in the controller, instead we just have to change the code in relevant model file.
</p>
<p>
[[File:Heatgrid-2022-10.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-11.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-13.png|600px]] <br/>
</p>

<p>A new hashmap is introduced to store the values of the metrics in the form of key value pairs. Instead of explicitly calling metrics by name in the view file, this hashmap is used to iterate over the metrics and displayed</p>

<p>
[[File:Heatgrid-2022-20.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-21.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-22.png|600px]] <br/>
</p>

Toggle feature is implemented in "view_team_in_grades.js" file. When the checkbox is clicked, function in javascript file is called and appropriate elements are hidden.

<p>
[[File:Heatgrid-2022-23.png|600px]] <br/>
</p>

<h4> Adding a new metric in future </h4>

<p> To introduce new metric, a new method should be added in "vm_question_response.rb" file. This newly added method should be called from "calculate_metrics" method </p>

<p>
[[File:Heatgrid-2022-30.png|600px]] <br/>
</p>

<p>
[[File:Heatgrid-2022-31.png|600px]] <br/>
</p>

<h4>Changes reflected in the UI</h4>

<p>
[[File:Heatgrid-2022-40.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-41.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-43.png|600px]] <br/>
</p>

<h4> Manual Testing </h4>

<pre>
Scenario: Visibility of all the unchecked metric checkboxes in View Scores view
Given user has logged in
When user visits View Scores page
Then all the unchecked metric checkboxes are present above the heat grid
</pre>

<pre>
Scenario: Default invisibility of metric columns in View Scores view
Given user has logged in
When user visits View Scores page
Then metric columns are not visible in the heat grid
</pre>

<pre>
Scenario: Checking a metric checkbox displays the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on unchecked comments#10 metric
Then column with column name " comments#10" gets displayed with corresponding values
</pre>

<pre>
Scenario: Unchecking a metric checkbox hides the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on checked comments#10 metric
Then column with column name " comments#10" and corresponding values get hidden
</pre>

<h4> Unit Testing </h4>
As our project does not deal with actually adding new metrics, but just facilitating a low-coupling addition of new metrics, we need not add any unit test cases for metric implementations. There is only one metric in the system as of now for which test cases are already written.
<h2>Implementation of Issue 2019</h2>

<h2> Important Links </h2>
* GitHub repository link: https://github.com/EshwarCVS/expertiza
* Project Description Document: https://docs.google.com/document/d/1H0BjzMBz5it7Wckhegq4LXhMi8RVctTwVzP2x9gnFCo/edit#heading=h.tqdrrd12xs4x
* GitHub Issue #1869: https://github.com/expertiza/expertiza/issues/1869
* GitHub Issue #2019: https://github.com/expertiza/expertiza/issues/2019

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-05-01T07:35:40Z

Gkogant:

This page provides information about the documentation of E2241: Heatgrid fixes and improvements as part of CSC/ECE 517 Spring 2022 Final project.
__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
*Nicholas Himes (nnhimes)
<h3> Team Members (PinkPatterns) </h3>
* Eshwar Chandra Vidhyasagar Thedla (ethedla)
* Gokul Krishna Koganti (gkogant)
* Jyothi Sumer Goud Maduru (jmaduru)
* Suneha Bose (sbose2)

<h2> Heat Grid </h2>

Heat Grid refers to a part of view in Expertiza that shows review scores of all the reviews done for a particular assignment. It shows scores given for each rubric by peer reviewers. This is used by instructors to assign scores to individual assignments and by students to view review scores of their assignment. Our project scope involves dealing with fixing issues related to the heat grid and any subsequent bugs that might arrive.

<h2> Issues identified </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work</h3>
<p> There are some instances where a student was shown as reviewing his/her team even though the "Allow Self Review" checkbox was not checked by the instructor. This situation should not arise for practical purposes. Test cases must be extensively added so that we can be notified if the bug occurs again. </p>

[[File:Screen Shot 2022-04-06 at 10.37.56 PM.png|center|450px]]

<h3> Issue #1869: Deal with the metrics of the heat grid</h3>
<p> <b>metric-1</b> column name in the heat grid follows bad naming convention. It doesn't explain what the column refers to. This must be changed to make the column name more apt.</p>
<p> As of now, the heat grid uses only one metric (metric-1). We must facilitate the system for addition of new metrics. Instructors should be able to toggle between various metrics as per their preferences. This can be done by the use of a drop down menu.</p>

[[File:Screen Shot 2022-04-06 at 10.34.47 PM.png|center|550px]]

<h2> Plan of work </h2>
<h3> Issue #2019: Restrict teammates from reviewing their own work </h3>
<p>Relevant bug of this issue can’t be reproduced to deal with it. So comprehensive test cases must be written to be notified if the bug arises again. We are planning to add rspec unit tests covering the following cases:
</p>
<ul>
<li><b> If the instructor unchecks “ Allow self review” option</b></li>
<ol>
<li> Instructor should not be able to assign a student to review work that he/she has submitted. </li>
<li> Instructor should not be able to assign a student to review work that their teammate has submitted.</li>
<li> Students should not be able to review work he/she has submitted.</li>
<li> Students should not be able to review work a teammate has submitted.</li>
</ol>
<li><b> If the instructor checks “ Allow self review” option</b></li>
<ol>
<li> Instructor should be able to assign a student to review work that he/she has submitted.</li>
<li> Instructor should be able to assign a student to review work that their teammate has submitted.</li>
<li> Students should be able to review work he/she has submitted. </li>
<li> Students should be able to review work a teammate has submitted.</li>
</ol>
</ul>

<h3> Issue #1869: Deal with the metrics of the heat grid </h3>
<p>The new metrics can be added to the Metrics table that we will create. While creating an assignment/ editing an assignment, the instructor can select a metric from the Metrics table which will be available as a dropdown menu. We will retrieve the metric selected for the assignment by the instructor and display it in the Heatgrid Map of reviews.</p>

* In create/edit assignment, the instructor will see ‘Metric Type’ drop down which has list of metrics based on the values in the database
* Save the selected metric type and update the value in the database
* Retrieve the metric type from the assignment and calculate the value of the metric
* Display the values of the metric in the Heatgrid view

<h4> Proposed Control Flow </h4>

[[File:Proposed_Control_Flow.drawio.png]]

<h4>UML Diagram </h4>

[[File:UML diagram E2241.png|center|600px]]

<h2> Design Principle </h2>
<p>
For Issue #1869 we plan to use the Factory Design Pattern since we are dealing with the creation of multiple kinds of metrics. As part of our implementation, we plan on using a metric interface, which can be implemented by different concrete metric classes. A factory class acts as a middleman between the implementations and the main class that instantiates the objects. Based on the instructor's selection, the main class requests the metric object from the factory class, rather than dealing with the creation logic on its own. This pattern, therefore, enforces encapsulation and results in the low coupling, the principle which is our primary target for this project scope.
</p>
<p>
The previous implementation has dealt with issue #1869. But the drawback with the implementation is that it renders a code that is highly coupled. Whenever a new metric is added two files (assignments/edit/_general.html.erb and grades/view_team.html.erb) are to be changed, resulting in high coupling. As a consequence, tests pertaining to the highly coupled codes require new tests as a new metric is added. This is undesirable. So, the principle of low coupling is the main focus of our implementation. This principle will enable a common set of tests that would be valid for any number of metrics that will potentially be added in the future.
</p>
<h2> Files to be targeted </h2>

<h3>Issue #2019</h3>
<p> Test file for adding test cases to implement self-reviews checks </p>
* spec/controllers/grades_controller_spec.rb

<h3>Issue #1869</h3>
<p>For Heat grid view</p>
* app/views/grades/_view_heatgrid.html.erb
* app/views/grades/view_team.html.erb
* app/helpers/grades_helper.rb
* app/controllers/grades_controller.rb
* app/models/vm_question_response.rb
* app/models/vm_question_row.rb
* assets/view_team_in_grades.js
<p>For Assignment view</p>
* app/views/assignment/edit/_general.html.erb
* app/controllers/assignments_controller.rb

<h2> Implementation of Issue 1869</h2>

<h3> Previous team’s implementation </h3>

<p> The previous team has dealt with the issue by changing “metric-1” to “verbose comment count”, which is relevant to what metric-1 refers to. For the latter half of the issue, they have provided a metric dropdown for the instructor to select while creating the assignment. This consequently requires only one metric to be displayed on the heat grid for which they’ve given a toggle option to show and hide the metric.
</p>

<h4> Changes reflected in the UI </h4>

<ul>
<li> <b> metric-1 </b> changed to verbose comment count </li>
[[File:Heatgrid-metric.png|600px]]

<li> Metric dropdown provided while creating an assignment </li>
[[File:Assignment General page.png|600px]]

</ul>

<h4> Issue with previous team's implementation </h4>

<p> The critical problem with their changes was, when in future a new metric is added, it forces a change in two view files: one time in assignments/edit/_general.html.erb and two times in grades/view_team.html.erb. Requiring these changes in view files that have little relevance to the heat grid is essentially causing high coupling. </p>

<h3> Current implementation </h3>

<h4> Issue Goal </h4>
<p> Our mentor has required us to display metrics in the heat grid with a toggle option for the user to select only the required metrics according to their preferences. This should be done keeping in mind low coupling as the primary design goal. These changes should be accompanied by minor changes such as adding comments and changing the name of “metric-1” to a self-indicative name. </p>

<h4> Implementation details </h4>
<p>
In the original beta implementation, whenever the relevant view file is loaded, it is calling the method "populate_view_model" present in the "grades_controller.rb" file. This method, is explicitly calling another model method to calculate metric. Whenever a new metric is added, we will have to make a call to that metric in the populate view model. This is not ideal as each new metric added is introducing a new line of code in the controller body. It is also not possible to determine the metrics present dynamically. To deal with this problem, we introduced a new parent method "calculate_metrics" in model file "vm_question_response.rb". This method is responsible for calling other individual methods that calculate metrics. The call to this method is replacing the explicit calls to metric calculation in the controller. This essentially is breaking the dependency between new metric introduction and the controller. Now, whenever a new metric is added, there is no need to introduce any code changes in the controller, instead we just have to change the code in relevant model file.
</p>
<p>
[[File:Heatgrid-2022-10.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-11.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-13.png|600px]] <br/>
</p>

<p>A new hashmap is introduced to store the values of the metrics in the form of key value pairs. Instead of explicitly calling metrics by name in the view file, this hashmap is used to iterate over the metrics and displayed</p>

<p>
[[File:Heatgrid-2022-20.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-21.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-22.png|600px]] <br/>
</p>

Toggle feature is implemented in "view_team_in_grades.js" file. When the checkbox is clicked, function in javascript file is called and appropriate elements are hidden.

<p>
[[File:Heatgrid-2022-23.png|600px]] <br/>
</p>

<h4> Adding a new metric in future </h4>

<p> To introduce new metric, a new method should be added in "vm_question_response.rb" file. This newly added method should be called from "calculate_metrics" method </p>

<p>
[[File:Heatgrid-2022-30.png|600px]] <br/>
</p>

<p>
[[File:Heatgrid-2022-31.png|600px]] <br/>
</p>

<h4>Changes reflected in the UI</h4>

<p>
[[File:Heatgrid-2022-40.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-41.png|600px]] <br/>
</p>
<p>
[[File:Heatgrid-2022-43.png|600px]] <br/>
</p>

<h4> Manual Testing </h4>

<pre>
Scenario: Visibility of all the unchecked metric checkboxes in View Scores view
Given user has logged in
When user visits View Scores page
Then all the unchecked metric checkboxes are present above the heat grid
</pre>

<pre>
Scenario: Default invisibility of metric columns in View Scores view
Given user has logged in
When user visits View Scores page
Then metric columns are not visible in the heat grid
</pre>

<pre>
Scenario: Checking a metric checkbox displays the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on unchecked comments#10 metric
Then column with column name " comments#10" gets displayed with corresponding values
</pre>

<pre>
Scenario: Unchecking a metric checkbox hides the corresponding metric column
Given user has logged in
When user visits View Scores page and
When user clicks on checked comments#10 metric
Then column with column name " comments#10" and corresponding values get hidden
</pre>

<h4>Unit Tests</h4>

<pre>
Scenario: The output for the metric “Comment Count”
Given: Instructor is logged in
When: Instructor selects metric as “Comment Count” for an assignment
Then: outputs 15 for the comment “The team has documented everything on the wiki page very properly following all the guidelines”
</pre>

<pre>
Scenario: The output for the metric “Comment Count”
Given: Instructor is logged in
When: Instructor selects metric as “Comment Count” for an assignment
Then: outputs 0 for the comment “”
</pre>

<h2>Implementation of Issue 2019</h2>

<h2> Important Links </h2>
* GitHub repository link: https://github.com/EshwarCVS/expertiza
* Project Description Document: https://docs.google.com/document/d/1H0BjzMBz5it7Wckhegq4LXhMi8RVctTwVzP2x9gnFCo/edit#heading=h.tqdrrd12xs4x
* GitHub Issue #1869: https://github.com/expertiza/expertiza/issues/1869
* GitHub Issue #2019: https://github.com/expertiza/expertiza/issues/2019

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-04-12T03:46:40Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-04-07T03:31:21Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-04-07T03:25:29Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-04-07T02:09:58Z

Gkogant:

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
*Nicholas Himes (nnhimes)
<h3> Team Members (PinkPatterns) </h3>
* Eshwar Chandra Vidhyasagar Thedla (ethedla)
* Gokul Krishna Koganti (gkogant)
* Jyothi Sumer Goud Maduru (jmaduru)
* Suneha Bose (sbose2)

<h2> Heat Grid </h2>

Heat Grid refers to a part of view in expertiza that shows review scores of all the reviews done for a particular assignment. It shows scores given for each rubric by peer reviewers. This is used by instructors to assign scores to individual assignments and by students to view review scores of their assignment. Our project scope involves dealing with fixing issues related to the heat grid and any subsequent bugs that might arrive.

<h2> Issues identified </h2>
<h3> Restrict teammates from reviewing their own work (Issue #2019)</h3>
<p> There are some instances where a student was shown as reviewing his/her team. This is impossible and is classified as a bug. This must be dealt with. Test cases must be extensively added so that we can be notified if the bug occurs again. </p>
<h3> Deal with the metrics of the heat grid (Issue #1869)</h3>
<p> <b>metric-1</b> column name in the heat grid follows bad naming convention. It doesn't explain what the column refers to. This must be changed to make the column name more apt.</p>
<p> As of now, the heat grid uses only one metric (metric-1). We must facilitate the system for addition of new metrics. Instructors should be able to toggle between various metrics as per their preferences. This can be done by the use of a drop down menu.</p>

<h2> Current Implementation </h2>
<h2> Plan of work </h2>
<h3> Restrict teammates from reviewing their own work (Issue #2019)</h3>
<p>Relevant bug of this issue can’t be reproduced to deal with it. So comprehensive test cases must be written to be notified if the bug arises again. We are planning to add rspec unit tests covering the following cases:
</p>
<ul>
<li><b> If the instructor unchecks “ Allow self review” option</b></li>
<ol>
<li> Instructor should not be able to assign a student to review work that he/she has submitted. </li>
<li> Instructor should not be able to assign a student to review work that their teammate has submitted.</li>
<li> Students should not be able to review work he/she has submitted.</li>
<li> Students should not be able to review work a teammate has submitted.</li>
</ol>
<li><b> If the instructor checks “ Allow self review” option</b></li>
<ol>
<li> Instructor should be able to assign a student to review work that he/she has submitted.</li>
<li> Instructor should be able to assign a student to review work that their teammate has submitted.</li>
<li> Students should be able to review work he/she has submitted. </li>
<li> Students should be able to review work a teammate has submitted.</li>
</ol>
</ul>
<h2> Files to be targeted </h2>
<h3>Issue #1869</h3>
<p>For Heat grid</p>
* app/views/grades/_view_heatgrid.html.erb
* app/views/grades/view_team.html.erb
* app/helpers/grades_helper.rb
* app/controllers/grades_controller.rb
* app/models/vm_question_response.rb
* app/models/vm_question_row.rb
<p>For Assignment</p>
* app/views/assignment/edit/_general.html.erb
* app/controllers/assignments_controller.rb

<h2> Test Plan </h2>
* Capybara Test cases for testing the UI of heat grid view with the expected metric for the respective assignment and the UI of team view with relevant metric selected with all other metrics in the dropdown
* Spec test cases for testing the grades controller and assignment controller to check if they are returning the values as expected
* Unit test cases will be added to verify the logic behind the methods to calculate the values for their metrics

<h2> Important Links </h2>
* GitHub repository link: https://github.com/EshwarCVS/expertiza
* Project Description Document: https://docs.google.com/document/d/1H0BjzMBz5it7Wckhegq4LXhMi8RVctTwVzP2x9gnFCo/edit#heading=h.tqdrrd12xs4x
* GitHub Issue #1869: https://github.com/expertiza/expertiza/issues/1869
* GitHub Issue #2019: https://github.com/expertiza/expertiza/issues/2019

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-03-31T21:56:23Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements

2022-03-31T21:54:44Z

Gkogant: Created page with "This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project. __TOC__ <h2> Team </h2> <h3> Mentor </h3>..."

CSC/ECE 517 Spring 2022

2022-03-31T21:47:11Z

Gkogant:

== OSS Projects ==

* [[CSC/ECE 517 Spring 2022 - E2200: Testing advice_controller]]
* [[CSC/ECE 517 Spring 2022 - E2203: Adding tests for courses_controller, eula_controller]]
* [[CSC/ECE 517 Spring 2022 - E2204: Adding tests for markup_styles_controller, lock_controller]]
* [[CSC/ECE 517 Spring 2022 - E2208: Testing for submission_records_controller, profile_controller]]
* [[CSC/ECE 517 Spring 2022 - E2218: Refactor response_controller]]
* [[CSC/ECE 517 Spring 2022 - E2217: Refactor questionnaires_controller]]
* [[CSC/ECE 517 Spring 2022 - E2216: Refactor late_policies_controller]]
* [[CSC/ECE 517 Spring 2022 - E2215: Refactor student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor teams_controller]]
* [[CSC/ECE 517 Spring 2022 - E2219: Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2211: Testing for summary_helper]]
* [[CSC/ECE 517 Spring 2022 - E2225: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2221: Refactor submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2206: Testing for users_controller]]
* [[CSC/ECE 517 Spring 2022 - E2207: Testing for submitted_content_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2205: Testing for participants_controller, versions_controller]]
* [[CSC/ECE 517 Spring 2022 - E2212: Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2022 - S2200: Refactoring evaluation of SQL queries (Java/JUnit)]]
* [[CSC/ECE 517 Spring 2022 - S2222: Refactor impersonate_controller]]
* [[CSC/ECE 517 Spring 2022 - E2202- Testing for badges_controller, publishing_controller]]
*[[CSC/ECE 517 Spring 2022 - E2220: Refactor reputation_web_service_controller]]
* [[CSC/ECE 517 Spring 2022 - E2224: Refactor review_mapping_controller]]
* [[CSC/ECE 517 Spring 2022 - E2209: Testing for analytic helper.rb, join team requests helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix]]
* [[CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2201: Testing for assignment_questionnaire_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2243. Refactor student_teams functionality]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements]]

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-23T18:34:10Z

Gkogant:

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments. It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issues pertaining to the below mentioned fixes and had to debug the file extensively. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b> method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. <br/>
get_peer_reviews uses get_peer_reviews_for_responses method, which further calls get_valid_answers_for_response, get_max_question_score , calculate_peer_review_grade methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
generate_json_for_peer_reviews calls get_peer_reviews and generate_json_body methods.<br/>
get_peer_reviews calls get_peer_reviews_for_responses method.<br/>
generate_json_for_quiz_scores calls get_quiz_score and generate_json_body methods.<br/>
get_quiz_score calls get_ids_list and get_scores methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods.<br/>
prepare_request_method uses add_expert_grades, add_quiz_scores, add_hamer_reputation_values, add_lauw_reputation_values, encrypt_request_body, format_into_JSON to prepare the request body.<br/> process_response_body makes use of decrypt_response and update_participants to process the response received.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>

<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned. Proper convention is followed in accordance with the industry standards for the method descriptions, parameters and return specifications.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2291/commits/673fe2099991c21237c59c71d7ee51f063e55b70

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make the code compact</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/36bc4fa30d7c6548cb64e59ebca2a3afe4c9c4a9

<h2> Manual Testing </h2>

To test the changes manually use the following link to access the reputation web service endpoint.
<br/>http://152.7.177.155:8080/reputation_web_service/client<br/>
<b> Username :</b> instructor6 <br/>
<b>Password :</b> password <br/>

<br/>
<p> Enter assignment id which is a mandatory field, the secondary assignment id is optional. Enter the round number for which we want to calculate the reputation for (1-3) </p>
<p> Select the type of algorithm to calculate the reputation for the peer reviews.</p>
<p> Based on the type of algorithm selected, some of the additional information is automatically passed. Other additional information is optional.
<p> Click send request (This might take a few minutes, please be patient)</p>
<p> On clicking the send request, the JSON for the post request to the reputation web service is formed, and then sent. <br/>On receiving the response, we parse it and update the reputation of participants of the assignment provided. <br/>The request and response JSONs can be seen in both minified and beautified versions.
<br/> There is also a summary of the choices selected above the beautified JSONs.
<br/>
[[File:Manual_Testing.png|800px]]

<h2> Testing via rspec </h2>
Only a few methods and flows have automated test cases. Adding test cases is not in the scope of this project, and will be taken up later, to make the entire controller robust.<br/> However, we have made sure that all the existing test cases are not broken and working as they are supposed to be.</p>
<p> To run the automated rspec cases run the below command to verify if all the test cases are working.</p>
<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> Formatting string into JSON can be improved. Instead of prepending characters like '{', dictionaries can be used and then converted into JSON.</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T04:34:37Z

Gkogant:

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments . It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issues pertaining to the below mentioned fixes and had to debug the file extensively. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b> method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. <br/>
get_peer_reviews uses get_peer_reviews_for_responses method, which further calls get_valid_answers_for_response, get_max_question_score , calculate_peer_review_grade methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
generate_json_for_peer_reviews calls get_peer_reviews and generate_json_body methods.<br/>
get_peer_reviews calls get_peer_reviews_for_responses method.<br/>
generate_json_for_quiz_scores calls get_quiz_score and generate_json_body methods.<br/>
get_quiz_score calls get_ids_list and get_scores methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods.<br/>
prepare_request_method uses add_expert_grades, add_quiz_scores, add_hamer_reputation_values, add_lauw_reputation_values, encrypt_request_body, format_into_JSON to prepare the request body.<br/> process_response_body makes use of decrypt_response and update_participants to process the response received.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>

<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned. Proper convention is followed in accordance with the industry standards for the method descriptions, parameters and return specifications.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2291/commits/673fe2099991c21237c59c71d7ee51f063e55b70

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make the code compact</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/36bc4fa30d7c6548cb64e59ebca2a3afe4c9c4a9

<h2> Manual Testing </h2>

[[File:Manual_Testing.png|800px]]

<p>Before sending the request, please assign values for assignment_id and round, choose an algorithm.</p>

<h2> Testing via rspec </h2>

<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> Formatting string into JSON can be improved. Instead of prepending characters like '{', dictionaries can be used and then converted into JSON.</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T04:04:30Z

Gkogant:

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments . It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issues pertaining to the below mentioned fixes and had to debug the file extensively. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b> method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. <br/>
get_peer_reviews uses get_peer_reviews_for_responses method, which further calls get_valid_answers_for_response, get_max_question_score , calculate_peer_review_grade methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
generate_json_for_peer_reviews calls get_peer_reviews and generate_json_body methods.<br/>
get_peer_reviews calls get_peer_reviews_for_responses method.<br/>
generate_json_for_quiz_scores calls get_quiz_score and generate_json_body methods.<br/>
get_quiz_score calls get_ids_list and get_scores methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods.<br/>
prepare_request_method uses add_expert_grades, add_quiz_scores, add_hamer_reputation_values, add_lauw_reputation_values, encrypt_request_body, format_into_JSON to prepare the request body.<br/> process_response_body makes use of decrypt_response and update_participants to process the response received.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>

<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned. Proper convention is followed in accordance with the industry standards for the method descriptions, parameters and return specifications.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make the code compact</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/36bc4fa30d7c6548cb64e59ebca2a3afe4c9c4a9

<h2> Manual Testing </h2>

[[File:Manual_Testing.png|800px]]

<p>Before sending the request, please assign values for assignment_id and round, choose an algorithm.</p>

<h2> Testing via rspec </h2>

<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> Formatting string into JSON can be improved. Instead of prepending characters like '{', dictionaries can be used and then converted into JSON.</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T03:56:56Z

Gkogant:

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments . It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issued pertaining to the below mentioned fixes and had to debug the file extensively to make the below fixes. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b>method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. <br/>
get_peer_reviews uses get_peer_reviews_for_responses method, which further calls get_valid_answers_for_response, get_max_question_score , calculate_peer_review_grade methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
generate_json_for_peer_reviews calls get_peer_reviews and generate_json_body methods.<br/>
get_peer_reviews calls get_peer_reviews_for_responses method.<br/>
generate_json_for_quiz_scores calls get_quiz_score and generate_json_body methods.<br/>
get_quiz_score calls get_ids_list and get_scores methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods.<br/>
prepare_request_method uses add_expert_grades, add_quiz_scores, add_hamer_reputation_values, add_lauw_reputation_values, encrypt_request_body, format_into_JSON to prepare the request body.<br/> process_response_body makes use of decrypt_response and update_participants to process the response received.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>

<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned. Proper convention is followed in accordance with the industry standards for the method descriptions, parameters and return specifications.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make some changes</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/36bc4fa30d7c6548cb64e59ebca2a3afe4c9c4a9

<h2> Manual Testing </h2>

[[File:Manual_Testing.png|800px]]

<p>Before sending the request, please assign values for assignment_id and round, choose an algorithm.</p>

<h2> Testing via rspec </h2>

<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> Formatting string into JSON can be improved. Instead of prepending characters like '{', dictionaries can be used and then converted into JSON.</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T03:55:28Z

Gkogant:

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments . It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issued pertaining to the below mentioned fixes and had to debug the file extensively to make the below fixes. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b>method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. <br/>
get_peer_reviews uses get_peer_reviews_for_responses method, which further calls get_valid_answers_for_response, get_max_question_score , calculate_peer_review_grade methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
generate_json_for_peer_reviews calls get_peer_reviews and generate_json_body methods.<br/>
get_peer_reviews calls get_peer_reviews_for_responses method.<br/>
generate_json_for_quiz_scores calls get_quiz_score and generate_json_body methods.<br/>
get_quiz_score calls get_ids_list and get_scores methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods.<br/>
prepare_request_method uses add_expert_grades, add_quiz_scores, add_hamer_reputation_values, add_lauw_reputation_values, encrypt_request_body, format_into_JSON to prepare the request body.<br/> process_response_body makes use of decrypt_response and update_participants to process the response received.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>

<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make some changes</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/36bc4fa30d7c6548cb64e59ebca2a3afe4c9c4a9

<h2> Manual Testing </h2>

[[File:Manual_Testing.png|800px]]

<p>Before sending the request, please assign values for assignment_id and round, choose an algorithm.</p>

<h2> Testing via rspec </h2>

<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> Formatting string into JSON can be improved. Instead of prepending characters like '{', dictionaries can be used and then converted into JSON.</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T03:47:59Z

Gkogant:

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments . It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issued pertaining to the below mentioned fixes and had to debug the file extensively to make the below fixes. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b>method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. <br/>
get_peer_reviews uses get_peer_reviews_for_responses method, which further calls get_valid_answers_for_response, get_max_question_score , calculate_peer_review_grade methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods.<br/>
prepare_request_method uses add_expert_grades, add_quiz_scores, add_hamer_reputation_values, add_lauw_reputation_values, encrypt_request_body, format_into_JSON to prepare the request body.<br/> process_response_body makes use of decrypt_response and update_participants to process the response received.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>

<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make some changes</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/36bc4fa30d7c6548cb64e59ebca2a3afe4c9c4a9

<h2> Manual Testing </h2>

[[File:Manual_Testing.png|800px]]

<p>Before sending the request, please assign values for assignment_id and round, choose an algorithm.</p>

<h2> Testing via rspec </h2>

<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> Formatting string into JSON can be improved. Instead of prepending characters like '{', dictionaries can be used and then converted into JSON.</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T03:30:58Z

Gkogant:

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments . It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Password for a private key is place in the code. As this code is open-sourced, this causes security concerns and must be handled.</li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issued pertaining to the below mentioned fixes and had to debug the file extensively to make the below fixes. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b>method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. These functions further use helper methods to abide by the SRP principle. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods. These functions further use helper methods to abide by the SRP principle.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>
<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make some changes</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b>

<h2> Manual Testing </h2>

[[File:Manual_Testing.png|800px]]

<p>Before sending the request, please assign values for assignment_id and round, choose an algorithm.</p>

<h2> Testing via rspec </h2>

<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T02:33:22Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T02:17:24Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T01:16:54Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T00:38:21Z

Gkogant:

File:Send post references.png

2022-03-21T23:41:00Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-21T23:39:07Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-21T23:26:59Z

Gkogant:

File:Commented code.png

2022-03-21T23:16:09Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-21T22:58:01Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-21T22:54:38Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-21T20:33:52Z

Gkogant:

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-21T20:29:21Z

Gkogant:

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments . It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issue identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Password for a private key is place in the code. As this code is open-sourced, this causes security concerns and must be handled.</li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>
<h2> Enhancements </h2>

<h2> Testing </h2>
<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-21T20:05:14Z

Gkogant:

__TOC__

<h2> Expertiza </h2>

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issue identified </h2>
1. Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task.
2. In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed.
3. Password for a private key is place in the code. As this code is open-sourced, this causes security concerns and must be handled.
4. Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.
5. Detailed method descriptions are needed to be inserted into the code as comments.
6. Client is a bad method name and needs to be changed.
7. There is a lot of unused/commented code, which should be removed.
8. Some spelling mistakes are identified in the code.
<h2> Enhancements </h2>
<h2> Testing </h2>

<h2> Team </h2>
* Eshwar Chandra Vidhyasagar Theda
* Gokul Krishna Koganti
* Krishna Saurabh Vankadaru
* Naman Shrimali (Mentor)

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-21T20:00:07Z

Gkogant: Created page with " __TOC__ <h2> Expertiza </h2> <h2> Background of reputation web service controller </h2> Expertiza provides a way for students to peer review others' works. The motive of..."

__TOC__

<h2> Expertiza </h2>

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issue identified </h2>
1. Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task.
2. In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed.
3. Password for a private key is place in the code. As this code is open-sourced, this causes security concerns and must be handled.
4. Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.
5. Detailed method descriptions are needed to be inserted into the code as comments.
6. Client is a bad method name and needs to be changed.
7. There is a lot of unused/commented code, which should be removed.
8. Some spelling mistakes are identified in the code.
<h2> Enhancements </h2>

<h2> Team </h2>
* Eshwar Chandra Vidhyasagar Theda
* Gokul Krishna Koganti
* Krishna Saurabh Vankadaru
* Naman Shrimali (Mentor)

CSC/ECE 517 Spring 2022

2022-03-21T19:57:05Z

Gkogant:

[[Link title]]== OSS Projects ==

* [[CSC/ECE 517 Spring 2022 - E2203: Adding tests for courses_controller, eula_controller]]
* [[CSC/ECE 517 Spring 2022 - E2204: Adding tests for markup_styles_controller, lock_controller]]
* [[CSC/ECE 517 Spring 2022 - E2218: Refactor response_controller]]
* [[CSC/ECE 517 Spring 2022 - E2217: Refactor questionnaires_controller]]
* [[CSC/ECE 517 Spring 2022 - E2216: Refactor late_policies_controller]]
* [[CSC/ECE 517 Spring 2022 - E2215: Refactor student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor teams_controller]]
* [[CSC/ECE 517 Spring 2022 - E2219: Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2211: Testing for summary_helper]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2221: Refactor submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2206: Testing for users_controller]]
* [[CSC/ECE 517 Spring 2022 - E2205: Testing for participants_controller, versions_controller]]
* [[CSC/ECE 517 Spring 2022 - E2212: Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2022 - S2200: Refactoring evaluation of SQL queries (Java/JUnit)]]
* [[CSC/ECE 517 Spring 2022 - S2222: Refactor impersonate_controller]]
* [[CSC/ECE 517 Spring 2022 - E2202- Testing for badges_controller, publishing_controller]]
*[[CSC/ECE 517 Spring 2022 - E2220: Refactor reputation_web_service_controller]]
* [[CSC/ECE 517 Spring 2022 - E2224: Refactor review_mapping_controller]]

== Final Projects ==