CSC/ECE 517 Fall 2016/oss E1639

This wiki page describes changes made under E1639 OSS project assignment for Fall 2016, CSC/ECE 517.

Expertiza Background

Expertiza is a web application for educational purposes. It is an open source project based on Ruby on Rails framework. Expertiza has been created and maintained by faculty and students of NCSU. It helps teachers set up assignments for students who can then make submissions. Students can also review work of other students and give feedback to help incorporate improvements.

Project Description

The following OSS project deals mainly with the ResponseController. The goal of this project is make the code more readable, maintainable and to improve elegance of the code. We would like ResponseController to adhere to the DRY principle. It focuses on refactoring some of the more complex methods and removing some redundant code. At present, ResponseController has methods that would better be located in other controllers. The project relocates such methods to its appropriate Controller class.

Files modified

Following files were mainly modified for this project namely:
1. response_controller.rb
2. response_controller_spec.rb
3. review_mapping_controller.rb
4. review_mapping_controller_spec.rb
5. routes.rb
6. _reviews.html.erb
7. _scores_submitted_work.html.erb 8. _self_review.html.erb

ResponseController

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ReponseMap, which provides details about reviewer, reviewee and reviewed entity.

List of changes

We worked on the following work items(WIs)
WI1 : Refactor calculate_all_penalties method into smaller methods
WI2 : Move the repeated code in conflict_notification & edit methods to a separate method list_questions.
WI3 : Refactor the code as per the Ruby style guidelines and incorporate the good practices
WI4 : Test the conflict_notification method to test the changes made.
WI5 : Move the repeated code in view and view_my_scores methods to a separate method retrieve_questions

Solutions Implemented and Delivered

• Refactoring calculate_all_penalties method

This is used to calculate various penalty values for each assignment if penalty is applicable.

The following changes were made:

1. This method was very complex, performing too many functions within a single method and had to be broken into 3 smaller methods each having a more well defined function. 2. The following 3 methods were created after splitting the first method

  i.  calculate_all_penalties

  ii. calculate_penatly_attributes

  iii. assign_all_penalties

3. Changes were also made to make the code follow ruby style.The language was made more ruby friendly. 4. Finally some redundant code was commented out as it was non-functional.

Refactoring into smaller more specific methods:

Removal of non-functional code :

Change of language to make it more Ruby friendly:

• Move the redundant piece of code from conflict_notification & edit methods to a new method list_questions

The conflict_notification method is used to help the instructors decide if one of the reviews are unfair or inaccurate. This was again split into 2 methods with some part of the code which is repeated in another method refactored into a new method.

Refactored #Created a method which was a duplicate in conflict_notification and edit methods

edit method:

This method is used to edit the questionnaires. This method again has code which is repeated in the conflict_notification method and thus the repeated section was split into a new method.

New method: Refactored #Created a method which was a duplicate in conflict_notification and edit methods

Similar refactoring was performed to obtain the retrieve_questions method:

This is the new method created after the above refactoring:

Testing Details

RSpec

There were no existing test cases for the GradesController. We have added a new spec file 'grades_spec.rb' which covers testing scenario for the newly added method. The specs were run on the previous and current files and they return the same results implying that the refactored code does not break anything. As the model was not changed, no test cases were added for the model.

UI Testing

Following steps needs to be performed to test this code from UI:
1. Login as instructor. Create a course and an assignment under that course.
2. Keep the has team checkbox checked while creating the assignment. Add a grading rubric to it. Add at least two students as participants to the assignment.
3. Create topics for the assignment.
4. Sign in as one of the students who were added to the assignment.
5. Go to the assignment and sign up for a topic.
6. Submit student's work by clicking 'Your work' under that assignment.
7. Sign in as a different student which is participant of the assignment.
8. Go to Assignments--><assignment name>-->Others' work (If the link is disabled, login as instructor and change the due date of the assignment to current time).
9. Give reviews on first student's work.
10. Login as instructor or first student to look at the review grades.

Scope for future improvement

1. The construct_table method in GradesHelper is not used anywhere. It has no reference in the project. So we feel it can be safely removed.
2. The has_team_and_metareview? method in GradesHelper can be broken down into separate methods, one each for team and metareview. This will provide improved flexibility. It needs some analysis though, as both the entities(team & metareview) are currently checked in conjuction from all the views they are referenced from.