CSC/ECE 517 Spring 2019 - Project E1924. Regulate changing of rubrics while projects are in progress: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(added team members and references)
No edit summary
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Here is a link to the [[https://drive.google.com/file/d/18rmtNqcmBw6u6Nx-cBq-Xp1z-ZBaYQog/view | video]], which the team emailed to the instructor.
''' Regulate changing of rubrics while projects are in progress '''
''' Regulate changing of rubrics while projects are in progress '''


Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). It consists of multiple features, one such feature is the ability to setup an assignment by an instructor. While setting up an assignment, the instructor would be asked to choose different kinds of rubrics. Any of these rubrics can later be edited or changed to a different rubric. A problem arises when an assignment is underway (students have already started reviewing) and a rubric is edited or changed. Some students started reviewing with the old rubric and the rest of the students who had not started a review will be presented with the updated rubric. This usually happens when an assignment is copied from a previous year and the rubrics are not updated to match the current topic. It could be at a later point that the instructor/TA realizes this and changes it. The goal of this project is two-fold: One, If a rubric is replaced, or the items/questions are changed, then all the reviews that have been done need to be redone and two, the system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects. If the change does not involve an addition/deletion of questions, it is termed as a minor change. If the change is deemed as a minor change, the refactoring should not make any changes to the current implementation
Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). It consists of multiple features, one such feature is the ability to setup an assignment by an instructor. While setting up an assignment, the instructor would be asked to choose different kinds of rubrics. Any of these rubrics can later be edited or changed to a different rubric. A problem arises when an assignment is underway (students have already started reviewing) and a rubric is edited or changed. Some students who had started reviewing with the old rubric are not notified of the change. Only the rest of the students who had not started a review will be presented with the updated rubric.
 
The goal of this project is two-fold:
1. If a rubric is replaced, or the items/questions are changed, then all the responses to that rubric need to be redone.
 
2. The system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.  
 
However, if the change does not involve an addition/deletion of questions, it is termed as a minor change. If the change is deemed as a minor change, the refactoring should not make any changes to the current implementation




Line 10: Line 20:
=='''Project Description'''==
=='''Project Description'''==
===Current Scenario===
===Current Scenario===
Currently, when an instructor updates a questionnaire rubric of an ongoing assignment, the reviews are not reset and moreover, no notifications are sent to reviewers to update them of the changes made. Moreover, the instructor, post making changes, would have to individually inform each reviewer of the changes made and ask them to change the reviews accordingly.
Currently, when an instructor updates a questionnaire rubric of an ongoing assignment, the reviews are not reset and moreover, no notifications are sent to reviewers to update them of the changes made. As of status quo, the instructor, post making changes, would have to individually inform each reviewer of the changes made and ask them to change the reviews accordingly.


===Expected Solution===
===Expected Solution===
Line 29: Line 39:


[[File:dfd_4.png]]
[[File:dfd_4.png]]
The main function of the code is to change the rubric questionnaire. There are three main functions to change the rubric of a questionnaire: add, remove or edit questions. Editing a question is considered a minor change as it does not change the general format(i.e. number of questions or their types) of the rubric. The two major changes are highlighted, they are adding or removing a question.
In case of a minor change the question in the database is simply updated, no other action/notification is required.
In case of a major change, the reviews given for that question need to be deleted in case the question has been removed and the consequent changes need to be relayed to the appropriate databases. Moreover, the reviewers, whose reviews have been removed, need to be informed about the changes made and be asked to update the reviews via email. The email-ids for these users have to be queried from the Users database.


=='''Proposed Solution'''==
=='''Proposed Solution'''==
Line 34: Line 51:


===Identification of edit===
===Identification of edit===
When a rubric is submitted after an edit, the update method is called. The current rubric is made such that the question type (Radio/Checkbox/True or False) is not editable, however, the wording of the question can be edited. The questions can be deleted and/or added. We term an edit as major edit if the change involves addition or deletion of a question and a minor edit corresponds to editing any existing questions. The params passed to the controller also includes a tag/identifier if a new question was added. We plan on using this identifier along with the number of questions to identify it the changes made were major or minor.
The primary metric for identification of a major change is when the ids of questions associated to a questionnaire change.
When a rubric is submitted after an edit, the update method is called. The current rubric is made such that the question type (Radio/Checkbox/True or False) is not editable, however, the wording of the question can be edited. As per the definition of a major change, it is obvious that there is no change in the question ids(records/objects) associated with the questionnaire. Hence this would be a minor change.
 
The questions can be deleted and/or added. We term an edit as major edit if the change involves addition or deletion of a question because it entails a change in the objects associated with the questionnaire. The params passed to the controller also includes a tag/identifier if a new question was added. We are using this tag to identify there was a new question added and hence major change.
[[File:edit_questionnaire_page.png|Edit questionnaire page]]
In the diagram shown above, the "Save teammate review questionnaire" would result in a minor change. Clicking on the highlighted add and remove would result in a change of the questions and is therefore a major change.




Line 40: Line 62:
Once this solution finds that the rubric has major edits and there exists some user who has started the response (corresponding records exist), email notification module is initiated. In this phase, these records are pulled from the ActiveRecord and sent to the user through email. Once the email is sent successfully, records are deleted from the DB.
Once this solution finds that the rubric has major edits and there exists some user who has started the response (corresponding records exist), email notification module is initiated. In this phase, these records are pulled from the ActiveRecord and sent to the user through email. Once the email is sent successfully, records are deleted from the DB.


At this stage, the user has all the details already added by them and when they click on "Review", the questions now correspond to the new rubric. This lets the user to edit on the new rubric without losing data for any question. One of the motives behind sending these responses as email is that the first few questions in the review may be similar across rubrics and the user may re-use the same responses when prompted with the new rubric.
At this stage, the user has all the details already added by them and when they click on "Review", the questions now correspond to the new rubric. This lets the user respond to the new rubric without losing data for any question. One of the motives behind sending these responses as email is that the first few questions in the review may be similar across rubrics and the user may re-use the same responses when prompted with the new rubric.
 
=='''Code Changes'''==
Firstly, we need to check if there has been a change in the questionnaire, i.e if any question has been added or deleted. For this we use the tags in the params. The view has been coded such that it adds a tag called ":add_new_questions" whenever there is a post method to add a new question. We have used this tag to identify a major change and redirected to necessary helper methods.  This is indicated in the image below:
 
[[File:new_question_added.jpg|identification of major change]]
 
Similarly, we have identified when a question is deleted and redirected again to helper methods.
 
The next step, is to look iterate through answers database and group the answers for the edited questionnaire per user/reviewer. The below UML diagram would assist in understanding the flow of information and the relation between the models.
 
[[File:UML_diagram.png|UML diagram showing the relationship between necessary models]]
 
Please note that FK stands for foreign key in the above diagram.
 
Using the question ids returned from view, we obtained the response id from the answer database. We tracked this response id through the response, response_map and user models to arrive at the user id. This has been achieved using the code shown below:


=='''Proposed Code Changes'''==
[[File:reviewer_answer_mapping.jpg|grouping of answers per reviewer]]
Firstly, we need to check if there has been a change in the questionnaire, i.e if any question has been added or deleted. For this we pull out the records from the active database of the questions and compare it with the number of question entries in the view. We get the number of questions from the code snippet as shown below from questionnare_controller.rb.


[[File:code2.png|Code]]


Now, we come across two cases.
Once we have identified the answers, user mail id and other associated information, this has to be mailed to the user and then the records deleted. This has been achieved using the code shown below:
In the first scenario, If there is a change in the number of questions we do the necessary changes. We delete all the response objects and answers and mail the changes to the user.


In the second scenario, If there is no change in the number of questions then there can be two possible cases. Either there really has been no change in the questions and we leave it as it is. Else, there has been equal number of additions and deletions and to detect this we check if the parameter add_new_questions is present. If it is, then there has been an update and we again do the required changes as discussed above. We check this through the code snippet below of the update method in questionnare_controller.rb.
[[File:mailer_function.jpg|Mailer function and deleting of associated records]]


[[File:code1.png|Code]]


=='''Test Plan'''==
=='''Test Plan'''==
The current rspec file describes various contexts for testing such as adding new questions if attributes weren't correctly entered etc. As stated in the earlier sections, the update method of the questionnaire controller would be edited to identify major changes and trigger emails and deletions of records of responses. A context corresponding to this in the spec file for questionnaire controller under the describe block for update would be added.
The current rspec file describes various contexts for testing such as adding new questions if attributes weren't correctly entered etc. As stated in the earlier sections, the update method of the questionnaire controller would be edited to identify major changes and trigger emails and deletions of records of responses. A context corresponding to this in the spec file for questionnaire controller under the describe block for update would be added.


At this moment we are thinking of at least 2 new test cases, both these cases correspond to editing a rubric:
Currently, we have added two tests:  
# If there is no new question added and the question id's match with the ones in the record - validate the existence of the record
#To verify whether a new question has been added or not and check whether the corresponding answers in the questionnaire have been appropriately deleted.
# If there is a new question added - assert if the email was sent
#To verify whether a question has been deleted or not and check whether the corresponding answers in the questionnaire have been appropriately deleted.


=='''Team members'''==
=='''Team members'''==

Latest revision as of 03:05, 6 May 2019

Here is a link to the [| video], which the team emailed to the instructor.

Regulate changing of rubrics while projects are in progress

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). It consists of multiple features, one such feature is the ability to setup an assignment by an instructor. While setting up an assignment, the instructor would be asked to choose different kinds of rubrics. Any of these rubrics can later be edited or changed to a different rubric. A problem arises when an assignment is underway (students have already started reviewing) and a rubric is edited or changed. Some students who had started reviewing with the old rubric are not notified of the change. Only the rest of the students who had not started a review will be presented with the updated rubric.

The goal of this project is two-fold:

1. If a rubric is replaced, or the items/questions are changed, then all the responses to that rubric need to be redone.

2. The system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.

However, if the change does not involve an addition/deletion of questions, it is termed as a minor change. If the change is deemed as a minor change, the refactoring should not make any changes to the current implementation


Setting up and Building the Project

Follow the Guidelines mentioned in the read me page of the project's Wiki Page for building the Project in a Local Environment.


Project Description

Current Scenario

Currently, when an instructor updates a questionnaire rubric of an ongoing assignment, the reviews are not reset and moreover, no notifications are sent to reviewers to update them of the changes made. As of status quo, the instructor, post making changes, would have to individually inform each reviewer of the changes made and ask them to change the reviews accordingly.

Expected Solution

The project aims to resolve the two main issue arising from the problems mentioned above:

  • If a rubric is replaced, or the items/questions are changed, then all the reviews that have been done need to be redone
  • The system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.

Further descriptions about how the project will be implemented and what files will be changed are mentioned in subsequent sections.

Design Diagrams

Use case Diagram

Use Case Diagram


Data Flow Diagram


The main function of the code is to change the rubric questionnaire. There are three main functions to change the rubric of a questionnaire: add, remove or edit questions. Editing a question is considered a minor change as it does not change the general format(i.e. number of questions or their types) of the rubric. The two major changes are highlighted, they are adding or removing a question.

In case of a minor change the question in the database is simply updated, no other action/notification is required.

In case of a major change, the reviews given for that question need to be deleted in case the question has been removed and the consequent changes need to be relayed to the appropriate databases. Moreover, the reviewers, whose reviews have been removed, need to be informed about the changes made and be asked to update the reviews via email. The email-ids for these users have to be queried from the Users database.

Proposed Solution

The solution is divided into 2 phases viz. Identification of edit and Notification.

Identification of edit

The primary metric for identification of a major change is when the ids of questions associated to a questionnaire change. When a rubric is submitted after an edit, the update method is called. The current rubric is made such that the question type (Radio/Checkbox/True or False) is not editable, however, the wording of the question can be edited. As per the definition of a major change, it is obvious that there is no change in the question ids(records/objects) associated with the questionnaire. Hence this would be a minor change.

The questions can be deleted and/or added. We term an edit as major edit if the change involves addition or deletion of a question because it entails a change in the objects associated with the questionnaire. The params passed to the controller also includes a tag/identifier if a new question was added. We are using this tag to identify there was a new question added and hence major change. Edit questionnaire page In the diagram shown above, the "Save teammate review questionnaire" would result in a minor change. Clicking on the highlighted add and remove would result in a change of the questions and is therefore a major change.


E-mail Notification

Once this solution finds that the rubric has major edits and there exists some user who has started the response (corresponding records exist), email notification module is initiated. In this phase, these records are pulled from the ActiveRecord and sent to the user through email. Once the email is sent successfully, records are deleted from the DB.

At this stage, the user has all the details already added by them and when they click on "Review", the questions now correspond to the new rubric. This lets the user respond to the new rubric without losing data for any question. One of the motives behind sending these responses as email is that the first few questions in the review may be similar across rubrics and the user may re-use the same responses when prompted with the new rubric.

Code Changes

Firstly, we need to check if there has been a change in the questionnaire, i.e if any question has been added or deleted. For this we use the tags in the params. The view has been coded such that it adds a tag called ":add_new_questions" whenever there is a post method to add a new question. We have used this tag to identify a major change and redirected to necessary helper methods. This is indicated in the image below:

identification of major change

Similarly, we have identified when a question is deleted and redirected again to helper methods.

The next step, is to look iterate through answers database and group the answers for the edited questionnaire per user/reviewer. The below UML diagram would assist in understanding the flow of information and the relation between the models.

UML diagram showing the relationship between necessary models

Please note that FK stands for foreign key in the above diagram.

Using the question ids returned from view, we obtained the response id from the answer database. We tracked this response id through the response, response_map and user models to arrive at the user id. This has been achieved using the code shown below:

grouping of answers per reviewer


Once we have identified the answers, user mail id and other associated information, this has to be mailed to the user and then the records deleted. This has been achieved using the code shown below:

Mailer function and deleting of associated records


Test Plan

The current rspec file describes various contexts for testing such as adding new questions if attributes weren't correctly entered etc. As stated in the earlier sections, the update method of the questionnaire controller would be edited to identify major changes and trigger emails and deletions of records of responses. A context corresponding to this in the spec file for questionnaire controller under the describe block for update would be added.

Currently, we have added two tests:

  1. To verify whether a new question has been added or not and check whether the corresponding answers in the questionnaire have been appropriately deleted.
  2. To verify whether a question has been deleted or not and check whether the corresponding answers in the questionnaire have been appropriately deleted.

Team members

1. Aishwarya Tirumala
2. Nilay Kapadia
3. Nitin Nataraj Kuncham
4. Suraj Siddharudh

References

  1. Expertiza on GitHub
  2. rpec tutorial
  3. Stackoverflow