Expertiza_Wiki - User contributions [en]

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

2022-04-26T01:55:37Z

Jmaduru:

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> Test plan </h4>
<p> </p>

<h2>Implementation of Issue 2019</h2>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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-26T01:52:24Z

Jmaduru:

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>

Here is how the view looks like

<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> Test plan </h4>
<p> </p>

<h2>Implementation of Issue 2019</h2>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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-26T01:51:46Z

Jmaduru:

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>

Here is how the view looks like

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

<h4> Test plan </h4>
<p> </p>

<h2>Implementation of Issue 2019</h2>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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:Heatgrid-2022-43.png

2022-04-26T01:47:37Z

Jmaduru:

File:Heatgrid-2022-41.png

2022-04-26T01:47:15Z

Jmaduru:

File:Heatgrid-2022-40.png

2022-04-26T01:46:24Z

Jmaduru:

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

2022-04-26T01:40:57Z

Jmaduru:

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> Test plan </h4>
<p> </p>

<h2>Implementation of Issue 2019</h2>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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:Heatgrid-2022-31.png

2022-04-26T01:38:48Z

Jmaduru:

File:Heatgrid-2022-30.png

2022-04-26T01:38:29Z

Jmaduru:

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

2022-04-26T01:30:43Z

Jmaduru:

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> </p>

<h4> Test plan </h4>
<p> </p>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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:Heatgrid-2022-23.png

2022-04-26T01:20:25Z

Jmaduru:

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

2022-04-26T01:06:51Z

Jmaduru:

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. This has map is used to iterate over the metrics and display in the html page</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>

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

<h4> Test plan </h4>
<p> </p>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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:Heatgrid-2022-22.png

2022-04-26T01:04:35Z

Jmaduru:

File:Heatgrid-2022-21.png

2022-04-26T01:04:15Z

Jmaduru:

File:Heatgrid-2022-20.png

2022-04-26T01:03:58Z

Jmaduru:

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

2022-04-26T00:55:38Z

Jmaduru:

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>

[[File:Heatgrid-2022-10.png|600px]] <br/>
[[File:Heatgrid-2022-11.png|600px]] <br/>
[[File:Heatgrid-2022-13.png|600px]] <br/>

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

<h4> Test plan </h4>
<p> </p>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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-26T00:54:49Z

Jmaduru:

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>

[[File:Heatgrid-2022-10.png|600px]]
[[File:Heatgrid-2022-11.png|600px]]
[[File:Heatgrid-2022-13.png|600px]]

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

<h4> Test plan </h4>
<p> </p>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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:Heatgrid-2022-13.png

2022-04-26T00:52:50Z

Jmaduru:

File:Heatgrid-2022-11.png

2022-04-26T00:52:33Z

Jmaduru:

File:Heatgrid-2022-10.png

2022-04-26T00:51:49Z

Jmaduru:

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

2022-04-26T00:29:53Z

Jmaduru:

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>

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

<h4> Test plan </h4>
<p> </p>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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-26T00:02:55Z

Jmaduru:

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. However, 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>

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

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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-26T00:01:44Z

Jmaduru:

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. However, 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>

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

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

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

</ul>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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-25T23:50:39Z

Jmaduru:

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. However, 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>

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

<ul>
<li> <b> metric-1 </b> changed to verbose comment count </li>

</ul>

<h2> Test Plan </h2>

<h3>Video Demo</h3>

The video link will be provided after the final submission.

<h3>Primary Goal of Testing</h3>

* 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

<h3>RSpec Tests</h3>

<h4>Functional Tests</h4>

<pre>
Scenario: Visibility of Metric dropdown list in New Assignment
Given Instructor has logged in
When Instructor visits New Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of Metric dropdown list in Edit Assignment
Given Instructor has logged in
When Instructor visits Edit Assignment page
Then Metric dropdown list is visible
</pre>

<pre>
Scenario: Visibility of selected metric in instructor's Assign Grade view
Given Instructor has logged in
When Instructor visits on Assign Grade page
Then Selected metric is visible in heatgrid map
</pre>

<pre>
Scenario: Visibility of selected metric in student's View Scores view
Given Student has logged in
When Student visits View Scores page
Then Selected metric is visible in heatgrid map
</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>

<h3>Regression Tests</h3>

When the new functionalities are implemented and added, make sure the existing functionalities and test cases still pass.

<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-12T00:25:07Z

Jmaduru:

File:UML diagram E2241.png

2022-04-12T00:22:13Z

Jmaduru:

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

2022-04-07T03:22:21Z

Jmaduru: