Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-04T15:46:30Z

Bjain:

==Introduction==

===Problem Statement===

The project is created to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role for example: architect,facilitator and implementer.A much more meaningful review can be done if the review rubric was duty-specific. Currently, there is a generic teammate review rubric for all assignments. This means that some review questions are not applicable for all team members. For instance, if there is a question “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.Similarly, design document specific questions may not be applicable to other members.The instructor should be able to use a different team-mate review rubrics for evaluating the contribution of students depending on their duty.

==UML Diagram==

[[File:Uml 1818.png]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project. The value of the duty for that project team is stored in TeamUsers.
* AssignmentsDutyMapping stores the value for all duties applicable to a particular assignment, hence it is an aggregation of the duties for an assignment.
* AssignmentDutyQuestionnaireMapping adds the questionnaire_id for a particular AssignmentDutyMapping thus has a direct dependency to AssignmentDutyMapping and has an association with the Questionnaire table.
* StudentTeams uses the AssignmentDutyMapping to table to find available duties for a particular assignment to allow teammates to select. It then uses the Duty table to fetch the respective name of the found duty_id.

==Implementation==

The project introduces changes from the instructor view and the student view. The changes are as follow:

===Migration changes===
* Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Added a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field saves the status of the role based review check box.
* Added a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field saves the status of the check box for allowing multiple students with the same role.
* Added a column entry named "Duties" to the Users table of type string. This field saves the duty that a student would select if role based reviews are enabled.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab of edit assignment, a check box called "Allow role based review?" is created. This allows an instructor to enable a role based team-mate review for a particular assignment.
[[File:Instructor_1_1818.png]]
* When the check box is ticked, the hidden fields become visible. This includes the duties that have been already added, displayed in a drop-down. Also, a button "Add Duty" pops up. This takes us to the create method of Duties controller where an instructor can add new duties.
[[File:Instructor_2_1818.png]]

* In order to display the hidden fields, We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the checkbox variable for ''role_based_review'' and depending its value(true or false), the hidden attributes i.e. ''duties_dropdown'' are displayed or kept hidden.
[[File:Instructor_3_1818.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Instructor_4_1818.png]]
* An instructor can decide the number of duties for a particular assignment.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table and thus it is associated with that assignment.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Instructor_5_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table. This is later used while displaying team-mate review questionnaire to students.

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty."

[[File:student_1_1818.jpg]]

* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option in the Duty column, they are redirected to a new page where all the duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the existing view will be displayed which does not give any such option.

[[File:student_2_1818.jpg]]

* The logic for this is implemented in the 'student_teams' controller and view. This is enclosed in a conditional which only appears if role based reviewing is permitted.

[[File:student_3_1818.jpg]]

* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
* After the teammate review questionnaire is opened once, 'View' and 'Edit' links are shown which redirect the user to view/edit the appropriate last saved response.

==Files changes==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
'''In this file, a ''duties'' table is created with a name field
'''
* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
'''In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.'''

* db/migrate/add_duties_to_users.rb
'''In this file, a column named ''duties'' is added to the ''Users'' table'''

* db/migrate/add_multiple_duties_to_assignments.rb
'''In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table'''

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
'''In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''
'''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
'''In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.'''

[[File:review_strat_1818.png]]

'''A java script function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.'''

[[File:hidden2_1818.png]]

* app/views/assignments/edit/rubrics.html.erb
'''In this file , a conditional statement is added, which displays the dropdown for selecting duties for teammate review from the duties for an assignment if role based reviewing is permitted or else the standard view is displayed.'''

[[File:rubrics_1818.png]]

* app/controllers/student_teams/student_teams_controller.rb
'''In this file, a variable is set that extracts from Assignments table if the role based reviewing is enabled or not. This variable is then used as a condition to display the various duties available for selection and also to display the particular duty chosen by the student.'''

* app/views/student_teams/view.html.erb
''' In this file, a conditional statement is added which redirects to a new page and displays the radio buttons of all the available duties if role based reviewing is allowed. If not, the standard view is displayed.'''
[[File:Student_view_1_1818.png]]

* app/controllers/response_controller.rb
'''In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.'''

* app/questionnaire/new.html.erb
'''A new questionnaire will be created for each new duty created or the same questionnaire can be used.'''

* app/questionnaire/edit.html.erb
'''A newly created questionnaire for a particular duty can be edited.'''

* app/views/duties/_form.html.erb
'''In this file we are creating a new duty and saving the assignment id and instructor id to the Duty table'''
[[File:duties_1818_1.png]]

==Test Plan==

* Instructor tests
** While creating an assignment, in the Review Strategy tab, check the box for role based reviewing and expect the 'role_based_review' column of Assignments table to be true.
** Ability to add new duties from the Review Strategy tab. Click on 'Add Duty' and get redirected to a new page where there is the option of adding a name for duty in the text-box and click 'Create Duty'. This new added duty will now be displayed in the Review Strategy tab if the role-based-review option is selected.
** Select from already existing and newly added duties for a particular assignment. After saving, the changes should be reflected in the database 'AssignmentsDutyMapping' table.

* Student(team member) tests
** When a student visits 'Your Team' link, if the option of role based review is selected while creating the assignment, a link 'Select' should appear which enables the student to select the duty.
** In the 'Your Team' tab, after clicking the 'Select' link, the student should be able to select one duty (radio button). This selected duty should now be visible on the 'Your Team' page.

==References==
* [http://wiki.expertiza.ncsu.edu/index.php/Main_Page Main Page Expertiza]
* [https://github.com/expertiza/expertiza/pull/1181 Github Pull Request]
* [https://youtu.be/jMQCJUeqA1Q Youtube Screencast]

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-04T15:32:15Z

Bjain:

==Introduction==

===Problem Statement===

The project is created to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role for example: architect,facilitator and implementer.A much more meaningful review can be done if the review rubric was duty-specific. Currently, there is a generic teammate review rubric for all assignments. This means that some review questions are not applicable for all team members. For instance, if there is a question “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.Similarly, design document specific questions may not be applicable to other members.The instructor should be able to use a different team-mate review rubrics for evaluating the contribution of students depending on their duty.

==UML Diagram==

[[File:Uml 1818.png]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project. The value of the duty for that project team is stored in TeamUsers.
* AssignmentsDutyMapping stores the value for all duties applicable to a particular assignment, hence it is an aggregation of the duties for an assignment.
* AssignmentDutyQuestionnaireMapping adds the questionnaire_id for a particular AssignmentDutyMapping thus has a direct dependency to AssignmentDutyMapping and has an association with the Questionnaire table.
* StudentTeams uses the AssignmentDutyMapping to table to find available duties for a particular assignment to allow teammates to select. It then uses the Duty table to fetch the respective name of the found duty_id.

==Implementation==

The project introduces changes from the instructor view and the student view. The changes are as follow:

===Migration changes===
* Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Added a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field saves the status of the role based review check box.
* Added a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field saves the status of the check box for allowing multiple students with the same role.
* Added a column entry named "Duties" to the Users table of type string. This field saves the duty that a student would select if role based reviews are enabled.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab of edit assignment, a check box called "Allow role based review?" is created. This allows an instructor to enable a role based team-mate review for a particular assignment.
[[File:Instructor_1_1818.png]]
* When the check box is ticked, the hidden fields become visible. This includes the duties that have been already added, displayed in a drop-down. Also, a button "New duty" pops up. This takes us to the create method of Duties controller where an instructor can add new duties.
[[File:Instructor_2_1818.png]]

* In order to display the hidden fields, We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the checkbox variable for ''role_based_review'' and depending its value(true or false), the hidden attributes i.e. ''duties_dropdown'' are displayed or kept hidden.
[[File:Instructor_3_1818.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Instructor_4_1818.png]]
* An instructor can decide the number of duties for a particular assignment.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table and thus it is associated with that assignment.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Instructor_5_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Instructor_6_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table. This is later used while displaying team-mate review questionnaire to students.

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty."

[[File:student_1_1818.jpg]]

* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option in the Duty column, they are redirected to a new page where all the duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the existing view will be displayed which does not give any such option.

[[File:student_2_1818.jpg]]

* The logic for this is implemented in the 'student_teams' controller and view. This is enclosed in a conditional which only appears if role based reviewing is permitted.

[[File:student_3_1818.jpg]]

* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
* After the teammate review questionnaire is opened once, 'View' and 'Edit' links are shown which redirect the user to view/edit the appropriate last saved response.

==Files changes==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
'''In this file, a ''duties'' table is created with a name field
'''
* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
'''In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.'''

* db/migrate/add_duties_to_users.rb
'''In this file, a column named ''duties'' is added to the ''Users'' table'''

* db/migrate/add_multiple_duties_to_assignments.rb
'''In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table'''

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
'''In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''
'''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
'''In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.'''

[[File:review_strat_1818.png]]

'''A java script function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.'''

[[File:hidden2_1818.png]]

* app/views/assignments/edit/rubrics.html.erb
'''In this file , a conditional statement is added, which displays the dropdown for selecting duties for teammate review from the duties for an assignment if role based reviewing is permitted or else the standard view is displayed.'''

[[File:rubrics_1818.png]]

* app/controllers/student_teams/student_teams_controller.rb
'''In this file, a variable is set that extracts from Assignments table if the role based reviewing is enabled or not. This variable is then used as a condition to display the various duties available for selection and also to display the particular duty chosen by the student.'''

* app/views/student_teams/view.html.erb
''' In this file, a conditional statement is added which redirects to a new page and displays the radio buttons of all the available duties if role based reviewing is allowed. If not, the standard view is displayed.'''
[[File:Student_view_1_1818.png]]

* app/controllers/response_controller.rb
'''In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.'''

* app/questionnaire/new.html.erb
'''A new questionnaire will be created for each new duty created or the same questionnaire can be used.'''

* app/questionnaire/edit.html.erb
'''A newly created questionnaire for a particular duty can be edited.'''

* app/views/duties/_form.html.erb
'''In this file we are creating a new duty and saving the assignment id and instructor id to the Duty table'''
[[File:duties_1818_1.png]]

==Test Plan==

* Instructor tests
** While creating an assignment, in the Review Strategy tab, check the box for role based reviewing and expect the 'role_based_review' column of Assignments table to be true.
** Ability to add new duties from the Review Strategy tab. Click on 'Add Duty' and get redirected to a new page where there is the option of adding a name for duty in the text-box and click 'Create Duty'. This new added duty will now be displayed in the Review Strategy tab if the role-based-review option is selected.
** Select from already existing and newly added duties for a particular assignment. After saving, the changes should be reflected in the database 'AssignmentsDutyMapping' table.

* Student(team member) tests
** When a student visits 'Your Team' link, if the option of role based review is selected while creating the assignment, a link 'Select' should appear which enables the student to select the duty.
** In the 'Your Team' tab, after clicking the 'Select' link, the student should be able to select one duty (radio button). This selected duty should now be visible on the 'Your Team' page.

==References==
* [http://wiki.expertiza.ncsu.edu/index.php/Main_Page Main Page Expertiza]
* [https://github.com/expertiza/expertiza/pull/1181 Github Pull Request]
* [http://www.example.com Youtube Screencast]

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-04T15:31:50Z

Bjain:

==Introduction==

===Problem Statement===

The project is created to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role for example: architect,facilitator and implementer.A much more meaningful review can be done if the review rubric was duty-specific. Currently, there is a generic teammate review rubric for all assignments. This means that some review questions are not applicable for all team members. For instance, if there is a question “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.Similarly, design document specific questions may not be applicable to other members.The instructor should be able to use a different team-mate review rubrics for evaluating the contribution of students depending on their duty.

==UML Diagram==

[[File:Uml 1818.png]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project. The value of the duty for that project team is stored in TeamUsers.
* AssignmentsDutyMapping stores the value for all duties applicable to a particular assignment, hence it is an aggregation of the duties for an assignment.
* AssignmentDutyQuestionnaireMapping adds the questionnaire_id for a particular AssignmentDutyMapping thus has a direct dependency to AssignmentDutyMapping and has an association with the Questionnaire table.
* StudentTeams uses the AssignmentDutyMapping to table to find available duties for a particular assignment to allow teammates to select. It then uses the Duty table to fetch the respective name of the found duty_id.

==Implementation==

The project introduces changes from the instructor view and the student view. The changes are as follow:

===Migration changes===
* Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Added a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field saves the status of the role based review check box.
* Added a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field saves the status of the check box for allowing multiple students with the same role.
* Added a column entry named "Duties" to the Users table of type string. This field saves the duty that a student would select if role based reviews are enabled.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab of edit assignment, a check box called "Allow role based review?" is created. This allows an instructor to enable a role based team-mate review for a particular assignment.
[[File:Instructor_1_1818.png]]
* When the check box is ticked, the hidden fields become visible. This includes the duties that have been already added, displayed in a drop-down. Also, a button "New duty" pops up. This takes us to the create method of Duties controller where an instructor can add new duties.
[[File:Instructor_2_1818.png]]

* In order to display the hidden fields, We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the checkbox variable for ''role_based_review'' and depending its value(true or false), the hidden attributes i.e. ''duties_dropdown'' are displayed or kept hidden.
[[File:Instructor_3_1818.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Instructor_4_1818.png]]
* An instructor can decide the number of duties for a particular assignment.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table and thus it is associated with that assignment.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Instructor_5_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Instructor_6_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table. This is later used while displaying team-mate review questionnaire to students.

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty."

[[File:student_1_1818.jpg]]

* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option in the Duty column, they are redirected to a new page where all the duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the existing view will be displayed which does not give any such option.

[[File:student_2_1818.jpg]]

* The logic for this is implemented in the 'student_teams' controller and view. This is enclosed in a conditional which only appears if role based reviewing is permitted.

[[File:student_3_1818.jpg]]

* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
* After the teammate review questionnaire is opened once, 'View' and 'Edit' links are shown which redirect the user to view/edit the appropriate last saved response.

==Files changes==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
'''In this file, a ''duties'' table is created with a name field
'''
* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
'''In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.'''

* db/migrate/add_duties_to_users.rb
'''In this file, a column named ''duties'' is added to the ''Users'' table'''

* db/migrate/add_multiple_duties_to_assignments.rb
'''In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table'''

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
'''In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''
'''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
'''In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.'''

[[File:review_strat_1818.png]]

'''A java script function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.'''

[[File:hidden2_1818.png]]

* app/views/assignments/edit/rubrics.html.erb
'''In this file , a conditional statement is added, which displays the dropdown for selecting duties for teammate review from the duties for an assignment if role based reviewing is permitted or else the standard view is displayed.'''

[[File:rubrics_1818.png]]

* app/controllers/student_teams/student_teams_controller.rb
'''In this file, a variable is set that extracts from Assignments table if the role based reviewing is enabled or not. This variable is then used as a condition to display the various duties available for selection and also to display the particular duty chosen by the student.'''

* app/views/student_teams/view.html.erb
''' In this file, a conditional statement is added which redirects to a new page and displays the radio buttons of all the available duties if role based reviewing is allowed. If not, the standard view is displayed.'''
[[File:Student_view_1_1818.png]]

* app/controllers/response_controller.rb
'''In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.'''

* app/questionnaire/new.html.erb
'''A new questionnaire will be created for each new duty created or the same questionnaire can be used.'''

* app/questionnaire/edit.html.erb
'''A newly created questionnaire for a particular duty can be edited.'''

* app/views/duties/_form.html.erb
'''In this file we are creating a new duty and saving the assignment id and instructor id to the Duty table'''
[[File:duties_1818_1.png]]

==Test Plan==

* Instructor tests
** While creating an assignment, in the Review Strategy tab, check the box for role based reviewing and expect the 'role_based_review' column of Assignments table to be true.

** Ability to add new duties from the Review Strategy tab. Click on 'Add Duty' and get redirected to a new page where there is the option of adding a name for duty in the text-box and click 'Create Duty'. This new added duty will now be displayed in the Review Strategy tab if the role-based-review option is selected.

** Select from already existing and newly added duties for a particular assignment. After saving, the changes should be reflected in the database 'AssignmentsDutyMapping' table.

* Student(team member) tests
** When a student visits 'Your Team' link, if the option of role based review is selected while creating the assignment, a link 'Select' should appear which enables the student to select the duty.
** In the 'Your Team' tab, after clicking the 'Select' link, the student should be able to select one duty (radio button). This selected duty should now be visible on the 'Your Team' page.

==References==
* [http://wiki.expertiza.ncsu.edu/index.php/Main_Page Main Page Expertiza]
* [https://github.com/expertiza/expertiza/pull/1181 Github Pull Request]
* [http://www.example.com Youtube Screencast]

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-04T15:23:35Z

Bjain:

==Introduction==

===Problem Statement===

The project is created to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role for example: architect,facilitator and implementer.A much more meaningful review can be done if the review rubric was duty-specific. Currently, there is a generic teammate review rubric for all assignments. This means that some review questions are not applicable for all team members. For instance, if there is a question “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.Similarly, design document specific questions may not be applicable to other members.The instructor should be able to use a different team-mate review rubrics for evaluating the contribution of students depending on their duty.

==UML Diagram==

[[File:Uml 1818.png]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Implementation==

The project introduces changes from the instructor view and the student view. The changes are as follow:

===Migration changes===
* Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Added a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field saves the status of the role based review check box.
* Added a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field saves the status of the check box for allowing multiple students with the same role.
* Added a column entry named "Duties" to the Users table of type string. This field saves the duty that a student would select if role based reviews are enabled.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab of edit assignment, a check box called "Allow role based review?" is created. This allows an instructor to enable a role based team-mate review for a particular assignment.
[[File:Instructor_1_1818.png]]
* When the check box is ticked, the hidden fields become visible. This includes the duties that have been already added, displayed in a drop-down. Also, a button "New duty" pops up. This takes us to the create method of Duties controller where an instructor can add new duties.
[[File:Instructor_2_1818.png]]

* In order to display the hidden fields, We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the checkbox variable for ''role_based_review'' and depending its value(true or false), the hidden attributes i.e. ''duties_dropdown'' are displayed or kept hidden.
[[File:Instructor_3_1818.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Instructor_4_1818.png]]
* An instructor can decide the number of duties for a particular assignment.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table and thus it is associated with that assignment.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Instructor_5_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Instructor_6_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table. This is later used while displaying team-mate review questionnaire to students.

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty."

[[File:student_1_1818.jpg]]

* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option in the Duty column, they are redirected to a new page where all the duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the existing view will be displayed which does not give any such option.

[[File:student_2_1818.jpg]]

* The logic for this is implemented in the 'student_teams' controller and view. This is enclosed in a conditional which only appears if role based reviewing is permitted.

[[File:student_3_1818.jpg]]

* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
* After the teammate review questionnaire is opened once, 'View' and 'Edit' links are shown which redirect the user to view/edit the appropriate last saved response.

==Files changes==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
'''In this file, a ''duties'' table is created with a name field
'''
* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
'''In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.'''

* db/migrate/add_duties_to_users.rb
'''In this file, a column named ''duties'' is added to the ''Users'' table'''

* db/migrate/add_multiple_duties_to_assignments.rb
'''In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table'''

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
'''In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''
'''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
'''In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.'''

[[File:review_strat_1818.png]]

'''A java script function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.'''

[[File:hidden2_1818.png]]

* app/views/assignments/edit/rubrics.html.erb
'''In this file , a conditional statement is added, which displays the dropdown for selecting duties for teammate review from the duties for an assignment if role based reviewing is permitted or else the standard view is displayed.'''

[[File:rubrics_1818.png]]

* app/controllers/student_teams/student_teams_controller.rb
'''In this file, a variable is set that extracts from Assignments table if the role based reviewing is enabled or not. This variable is then used as a condition to display the various duties available for selection and also to display the particular duty chosen by the student.'''

* app/views/student_teams/view.html.erb
''' In this file, a conditional statement is added which redirects to a new page and displays the radio buttons of all the available duties if role based reviewing is allowed. If not, the standard view is displayed.'''
[[File:Student_view_1_1818.png]]

* app/controllers/response_controller.rb
'''In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.'''

* app/questionnaire/new.html.erb
'''A new questionnaire will be created for each new duty created or the same questionnaire can be used.'''

* app/questionnaire/edit.html.erb
'''A newly created questionnaire for a particular duty can be edited.'''

* app/views/duties/_form.html.erb
'''In this file we are creating a new duty and saving the assignment id and instructor id to the Duty table'''
[[File:duties_1818_1.png]]

==Test Plan==

* Instructor tests
** While creating an assignment, in the Review Strategy tab, check the box for role based reviewing and expect the 'role_based_review' column of Assignments table to be true.
[[File:Test1_1818.jpg]]
** Ability to add new duties from the Review Strategy tab. Click on 'Add Duty' and get redirected to a new page where there is the option of adding a name for duty in the text-box and click 'Create Duty'. This new added duty will now be displayed in the Review Strategy tab if the role-based-review option is selected.
[[File:Test2_1818.jpg]]
** Select from already existing and newly added duties for a particular assignment. After saving, the changes should be reflected in the database 'AssignmentsDutyMapping' table.
[[File:Test3_1818.jpg]]
* Student(team member) tests
** When a student visits 'Your Team' link, if the option of role based review is selected while creating the assignment, a link 'Select' should appear which enables the student to select the duty.
[[File:Test4_1818.jpg]]
** In the 'Your Team' tab, after clicking the 'Select' link, the student should be able to select one duty (radio button). This selected duty should now be visible on the 'Your Team' page.
[[File:Test5_1818.jpg]]

==References==
* [http://wiki.expertiza.ncsu.edu/index.php/Main_Page Main Page Expertiza]
* [https://github.com/expertiza/expertiza/pull/1181 Github Pull Request]
* [http://www.example.com Youtube Screencast]

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-04T15:22:49Z

Bjain:

==Introduction==

===Problem Statement===

The project is created to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role for example: architect,facilitator and implementer.A much more meaningful review can be done if the review rubric was duty-specific. Currently, there is a generic teammate review rubric for all assignments. This means that some review questions are not applicable for all team members. For instance, if there is a question “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.Similarly, design document specific questions may not be applicable to other members.The instructor should be able to use a different team-mate review rubrics for evaluating the contribution of students depending on their duty.

==UML Diagram==

[[File:Uml 1818.png]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Implementation==

The project introduces changes from the instructor view and the student view. The changes are as follow:

===Migration changes===
* Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Added a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field saves the status of the role based review check box.
* Added a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field saves the status of the check box for allowing multiple students with the same role.
* Added a column entry named "Duties" to the Users table of type string. This field saves the duty that a student would select if role based reviews are enabled.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab of edit assignment, a check box called "Allow role based review?" is created. This allows an instructor to enable a role based team-mate review for a particular assignment.
[[File:Instructor_1_1818.png]]
* When the check box is ticked, the hidden fields become visible. This includes the duties that have been already added, displayed in a drop-down. Also, a button "New duty" pops up. This takes us to the create method of Duties controller where an instructor can add new duties.
[[File:Instructor_2_1818.png]]

* In order to display the hidden fields, We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the checkbox variable for ''role_based_review'' and depending its value(true or false), the hidden attributes i.e. ''duties_dropdown'' are displayed or kept hidden.
[[File:Instructor_3_1818.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Instructor_4_1818.png]]
* An instructor can decide the number of duties for a particular assignment.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table and thus it is associated with that assignment.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Instructor_5_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Instructor_6_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table. This is later used while displaying team-mate review questionnaire to students.

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty."

[[File:student_1_1818.jpg]]

* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option in the Duty column, they are redirected to a new page where all the duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the existing view will be displayed which does not give any such option.

[[File:student_2_1818.jpg]]

* The logic for this is implemented in the 'student_teams' controller and view. This is enclosed in a conditional which only appears if role based reviewing is permitted.

[[File:student_3_1818.jpg]]

* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
* After the teammate review questionnaire is opened once, 'View' and 'Edit' links are shown which redirect the user to view/edit the appropriate last saved response.

==Files changes==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
'''In this file, a ''duties'' table is created with a name field
'''
* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
'''In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.'''

* db/migrate/add_duties_to_users.rb
'''In this file, a column named ''duties'' is added to the ''Users'' table'''

* db/migrate/add_multiple_duties_to_assignments.rb
'''In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table'''

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
'''In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''
'''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
'''In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.'''

[[File:review_strat_1818.png]]

'''A java script function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.'''

[[File:hidden2_1818.png]]

* app/views/assignments/edit/rubrics.html.erb
'''In this file , a conditional statement is added, which displays the dropdown for selecting duties for teammate review from the duties for an assignment if role based reviewing is permitted or else the standard view is displayed.'''

[[File:rubrics_1818.png]]

* app/controllers/student_teams/student_teams_controller.rb
'''In this file, a variable is set that extracts from Assignments table if the role based reviewing is enabled or not. This variable is then used as a condition to display the various duties available for selection and also to display the particular duty chosen by the student.'''

* app/views/student_teams/view.html.erb
''' In this file, a conditional statement is added which redirects to a new page and displays the radio buttons of all the available duties if role based reviewing is allowed. If not, the standard view is displayed.'''
[[File:Student_view_1_1818.png]]

* app/controllers/response_controller.rb
'''In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.'''

* app/questionnaire/new.html.erb
'''A new questionnaire will be created for each new duty created or the same questionnaire can be used.'''

* app/questionnaire/edit.html.erb
'''A newly created questionnaire for a particular duty can be edited.'''

* app/views/duties/_form.html.erb
'''In this file we are creating a new duty and saving the assignment id and instructor id to the Duty table'''
[[File:duties_1818_1.png]]

==Test Plan==

* Instructor tests
** While creating an assignment, in the Review Strategy tab, check the box for role based reviewing and expect the 'role_based_review' column of Assignments table to be true.
[[File:Test1_1818.jpg]]
** Ability to add new duties from the Review Strategy tab. Click on 'Add Duty' and get redirected to a new page where there is the option of adding a name for duty in the text-box and click 'Create Duty'. This new added duty will now be displayed in the Review Strategy tab if the role-based-review option is selected.
[[File:Test2_1818.jpg]]
** Select from already existing and newly added duties for a particular assignment. After saving, the changes should be reflected in the database 'AssignmentsDutyMapping' table.
[[File:Test3_1818.jpg]]
* Student(team member) tests
** When a student visits 'Your Team' link, if the option of role based review is selected while creating the assignment, a link 'Select' should appear which enables the student to select the duty.
[[File:Test4_1818.jpg]]
** In the 'Your Team' tab, after clicking the 'Select' link, the student should be able to select one duty (radio button). This selected duty should now be visible on the 'Your Team' page.
[[File:Test5_1818.jpg]]

==References==
* [http://wiki.expertiza.ncsu.edu/index.php/Main_Page Main Page Expertiza]
* [https://github.com/expertiza/expertiza/pull/1181 Github Pull Request]
* [http://www.example.com Youtube Screencast]

File:Test5 1818.jpg

2018-05-04T15:21:41Z

Bjain:

File:Test4 1818.jpg

2018-05-04T15:21:07Z

Bjain:

File:Test3 1818.jpg

2018-05-04T15:20:47Z

Bjain:

File:Test2 1818.jpg

2018-05-04T15:20:30Z

Bjain:

File:Test1 1818.jpg

2018-05-04T15:19:53Z

Bjain:

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-04T15:11:21Z

Bjain: /* Test Plan */

==Introduction==

===Problem Statement===

The project is created to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role for example: architect,facilitator and implementer.A much more meaningful review can be done if the review rubric was duty-specific. Currently, there is a generic teammate review rubric for all assignments. This means that some review questions are not applicable for all team members. For instance, if there is a question “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.Similarly, design document specific questions may not be applicable to other members.The instructor should be able to use a different team-mate review rubrics for evaluating the contribution of students depending on their duty.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Implementation==

The project introduces changes from the instructor view and the student view. The changes are as follow:

===Migration changes===
* Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Added a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field saves the status of the role based review check box.
* Added a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field saves the status of the check box for allowing multiple students with the same role.
* Added a column entry named "Duties" to the Users table of type string. This field saves the duty that a student would select if role based reviews are enabled.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab of edit assignment, a check box called "Allow role based review?" is created. This allows an instructor to enable a role based team-mate review for a particular assignment.
[[File:Instructor_1_1818.png]]
* When the check box is ticked, the hidden fields become visible. This includes the duties that have been already added, displayed in a drop-down. Also, a button "New duty" pops up. This takes us to the create method of Duties controller where an instructor can add new duties.
[[File:Instructor_2_1818.png]]

* In order to display the hidden fields, We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the checkbox variable for ''role_based_review'' and depending its value(true or false), the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:Instructor_3_1818.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Instructor_4_1818.png]]
* An instructor can decide the number of duties for a particular assignment. We have included a field for ''Allow multiple duties'' but not used it as we have the default case that one duty can be taken by multiple students. Work can be done in the future to allow the instructor to choose if students can take multiple duties.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table and thus it is associated with that assignment.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Instructor_5_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Instructor_6_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table. This is later used while displaying team-mate review questionnaire to students.

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty."

[[File:student_1_1818.jpg]]

* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option in the Duty column, they are redirected to a new page where all the duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the existing view will be displayed which does not give any such option.

[[File:student_2_1818.jpg]]

* The logic for this is implemented in the 'student_teams' controller and view. This is enclosed in a conditional which only appears if role based reviewing is permitted.

[[File:student_3_1818.jpg]]

* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
* After the teammate review questionnaire is opened once, 'View' and 'Edit' links are shown which redirect the user to view/edit the appropriate last saved response.

==Files changes==

===New files===
Some of the new migration files we have created are

* '''db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field'''

* '''db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.'''

* '''db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table'''

* ''' db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table'''

* '''db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''
'''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
'''In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.'''

[[File:review_strat_1818.png]]

'''A java script function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.'''

[[File:hidden2_1818.png]]

* app/views/assignments/edit/rubrics.html.erb
'''In this file , a conditional statement is added, which displays the dropdown for selecting duties for teammate review from the duties for an assignment if role based reviewing is permitted or else the standard view is displayed.'''

[[File:rubrics_1818.png]]

* app/controllers/student_teams/student_teams_controller.rb
'''In this file, a variable is set that extracts from Assignments table if the role based reviewing is enabled or not. This variable is then used as a condition to display the various duties available for selection and also to display the particular duty chosen by the student.'''

* app/views/student_teams/view.html.erb
''' In this file, a conditional statement is added which redirects to a new page and displays the radio buttons of all the available duties if role based reviewing is allowed. If not, the standard view is displayed.'''
[[File:Student_view_1_1818.png]]

* app/controllers/response_controller.rb
'''In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.'''

* app/questionnaire/new.html.erb
'''A new questionnaire will be created for each new duty created or the same questionnaire can be used.'''

* app/questionnaire/edit.html.erb
'''A newly created questionnaire for a particular duty can be edited.'''

* app/views/duties/_form.html.erb
'''In this file we are creating a new duty and saving the assignment id and instructor id to the Duty table'''
[[File:duties_1818_1.png]]

==Test Plan==

* Instructor tests
** While creating an assignment, in the Review Strategy tab, check the box for role based reviewing and expect the 'role_based_review' column of Assignments table to be true.
** Ability to add new duties from the Review Strategy tab. Click on 'Add Duty' and get redirected to a new page where there is the option of adding a name for duty in the text-box and click 'Create Duty'. This new added duty will now be displayed in the Review Strategy tab if the role-based-review option is selected.
** Select from already existing and newly added duties for a particular assignment. After saving, the changes should be reflected in the database 'AssignmentsDutyMapping' table.

* Student(team member) tests
** When a student visits 'Your Team' link, if the option of role based review is selected while creating the assignment, a link 'Select' should appear which enables the student to select the duty.
** In the 'Your Team' tab, after clicking the 'Select' link, the student should be able to select one duty (radio button). This selected duty should now be visible on the 'Your Team' page.

==References==
* [http://wiki.expertiza.ncsu.edu/index.php/Main_Page Main Page Expertiza]
* [https://github.com/expertiza/expertiza/pull/1181 Github Pull Request]
* [http://www.example.com Youtube Screencast]

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T07:26:29Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty.".
[[File:rsz_111.jpg]]
* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:E1818_1.jpg]]
[[File:E1818_3.jpg]]
* The logic for this is implemented in the 'student_teams' controller and view. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
[[File:E1818_4.jpg]]
[[File:E1818_5.jpg]]
* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
* After the teammate review questionnaire is opened once, 'View' and 'Edit' links are shown which redirect the user to the appropriate last saved response.
==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.
* app/controllers/student_teams/student_teams_controller.rb
In this file, a variable is set that extracts from Assignments table if the role based reviewing is enabled or not. This variable is then used as a condition to display the various duties available for selection and also to display the particular duty chosen by the student.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which redirects to a new page and displays the radio buttons of all the available duties if role based reviewing is allowed. If not, the standard view is displayed.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T07:19:12Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty.".
[[File:rsz_111.jpg]]
* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:E1818_1.jpg]]
[[File:E1818_3.jpg]]
* The logic for this is implemented in the 'student_teams' controller and view. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
[[File:E1818_4.jpg]]
[[File:E1818_5.jpg]]
* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T07:18:14Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty.".
[[File:rsz_111.jpg]]
* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:E1818_1.jpg]]
[[File:E1818_3.jpg]]
* The logic for this is implemented in the 'student_teams' controller and view. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* A team member cannot change their role after the assignment submission deadline.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , they will see a questionnaire corresponding to the duty of that student. This would enable reviews of the teammates to be accurate and specific to their role in a project.
[[File:E1818_4.jpg]]
[[File:E1818_5.jpg]]
==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

File:E1818 5.jpg

2018-05-03T07:18:10Z

Bjain:

File:E1818 4.jpg

2018-05-03T07:17:08Z

Bjain:

File:E1818 3.jpg

2018-05-03T07:14:19Z

Bjain:

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T07:13:49Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty.".
[[File:rsz_111.jpg]]
* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:E1818_1.jpg]]
* The logic for this is implemented in the 'student_teams' controller and view. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
[[File:Example_student_18.png]]
* A team member cannot change their role after the assignment submission deadline.
[[File:s2_18.png]]
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T07:08:51Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty.".
[[File:rsz_111.jpg]]
* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:E1818_1.jpg]]
* This is implemented by adding a drop down box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box. However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
[[File:Example_student_18.png]]
* This has been implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it is eliminated from the separate list maintained and that list is displayed to the student. There is a conditional in the student teams view file that displays the separate list in the drop down if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
[[File:s2_18.png]]
* This is implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement is included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T07:07:57Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. Students will either see "Review" link to start the teammate review or a message that says that "Teammate has not selected a duty.".
[[File:E1818_1.jpg]]
* The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:E1818_1.jpg]]
* This is implemented by adding a drop down box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box. However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
[[File:Example_student_18.png]]
* This has been implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it is eliminated from the separate list maintained and that list is displayed to the student. There is a conditional in the student teams view file that displays the separate list in the drop down if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
[[File:s2_18.png]]
* This is implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement is included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

File:E1818 1.jpg

2018-05-03T07:05:16Z

Bjain:

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T07:01:57Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:Rsz_111.jpg]]
[[File:Rsz_42.jpg]]
* This is implemented by adding a drop down box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box. However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
[[File:Example_student_18.png]]
* This has been implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it is eliminated from the separate list maintained and that list is displayed to the student. There is a conditional in the student teams view file that displays the separate list in the drop down if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
[[File:s2_18.png]]
* This is implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement is included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

File:Rsz 42.jpg

2018-05-03T07:01:20Z

Bjain:

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T06:52:57Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:Rsz_111.jpg]]
* This is implemented by adding a drop down box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box. However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
[[File:Example_student_18.png]]
* This has been implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it is eliminated from the separate list maintained and that list is displayed to the student. There is a conditional in the student teams view file that displays the separate list in the drop down if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
[[File:s2_18.png]]
* This is implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement is included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

File:Rsz 111.jpg

2018-05-03T06:52:23Z

Bjain:

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T06:48:19Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:YourTeam_view1.JPG]]
* This is implemented by adding a drop down box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box. However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
[[File:Example_student_18.png]]
* This has been implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it is eliminated from the separate list maintained and that list is displayed to the student. There is a conditional in the student teams view file that displays the separate list in the drop down if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
[[File:s2_18.png]]
* This is implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement is included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T06:46:59Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
[[File:YourTeam.jpg]]
* This is implemented by adding a drop down box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box. However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
[[File:Example_student_18.png]]
* This has been implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it is eliminated from the separate list maintained and that list is displayed to the student. There is a conditional in the student teams view file that displays the separate list in the drop down if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
[[File:s2_18.png]]
* This is implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement is included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

File:YourTeam view1.JPG

2018-05-03T06:46:03Z

Bjain:

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-05-03T06:45:24Z

Bjain:

==Introduction==

===Problem Statement===

The project is to enable role-based team-mate reviews. These roles can be better named as duties, corresponding to the duty of a team member in a particular project. The instructor should be able to use a different rubric for evaluating the contribution of team mates with different roles.
Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example,architect,facilitator and implementer. Although one member can contribute to other duties, a much more meaningful review can be done if the review rubric was role-specific. Currently, there is a single teammate review rubric for each assignment. This means that some review questions are not applicable for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests or documentation.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:

===Migration changes===
* . Create Duties table: This table stores all the duties created by any instructor.
* id - The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* assignment_id - An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* instructor_id - The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.

* Create assignments_duty_mappings table: If an instructor wants to add multiple duties for an assignment, storing it in the duty table will cause the duty to be overwritten. Thus we have created a table which maps an assignment and all its duties.
* id
* assignment_id
* duty_id

* Create assignment_duty_questionnaire_mappings table : This table is created to store the questionnaire for team-mate review rubrics and the corresponding duty id.
* id
* assignment_id
* duty_id
* questionnaire_id

* Add a column entry named "role_based_assignment" in the assignments table which would be of type boolean. This field would save the status of the role based review check box.
* Add a column entry named "allow_multiple_duties" in the assignments table which would be of type boolean. This field would save the status of the check box for allowing multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, in the 'Review Strategy' tab edit assignment,create a check box called "Is role based review allowed?" that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a check box tag in the review strategy sub page of the edit assignments page.
[[File:e18181_3.png]]
* When the check box is ticked, the duties that have been already added and a button to "New duty" pops up.
[[File:Example_e18181.png]]

* We call the java script function ''dutiesAssign()'' using the ''ischecked'' listener. The function queries the value of the checkbox for ''role_based_review'' and depending on if the value is true or false, the hidden attributes i.e. ''allow_multiple_duties'' and ''duties_dropdown'' are displayed or kept hidden.
[[File:e18181_2.png]]
* The instructor can select from the dropdown of duties. We have allowed multiple duties to be selected at once.The duties created by an instructor are unique for that instructor and are not displayed for any other instructor.
[[File:Picture1_e1818.png]]
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* When the assignment is saved, the duty_id is saved to the assignment_duty_mappings table.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
[[File:Example2_1818.png]]
* In order to do this, the instructor has to go to the Rubrics tab of edit assignment. There, if the assignment is role-based, a drop down menu displays the list of all the duties selected for an assignment.
[[File:Example23_1818.png]]
* When the assignment is saved, the questionnaire_id is stored in the assignment_duty_questionnaire_mappings table

===Student view changes===
* When a student goes to “Your team”, they can see the team members, their selected duties and the option to review if these are enabled. The student can select their duty from a particular set of duties created by the instructor for that particular assignment. Upon clicking "Select" option, view is redirected to a new page where all the available duties appear as radio-buttons and the student can select one of these. This occurs only if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
* This is implemented by adding a drop down box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box. However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
[[File:Example_student_18.png]]
* This has been implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it is eliminated from the separate list maintained and that list is displayed to the student. There is a conditional in the student teams view file that displays the separate list in the drop down if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
[[File:s2_18.png]]
* This is implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement is included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===
Some of the new migration files we have created are

* db/migrate/add_duties_table.rb
In this file, a ''duties'' table is created with a name field

* db/migrate/add_reference_of_instructor_and_assignment_to_duties.rb
In this file, we have adding foreign key reference of ''assignment id'' into ''duties table''.

* db/migrate/add_duties_to_users.rb
In this file, a column named ''duties'' is added to the ''Users'' table

* db/migrate/add_multiple_duties_to_assignments.rb
In this file, we have added a column ''allow_multiple_duties'' to ''assignments'' table

* db/migrate/create_assignment_duty_questionnaire_mapping.rb
In this file, we have created ''assignment_duty_questionnaire_mappings'' table and added columns for ''questionnaire_id'', ''assignment_id'' and ''duty_id''

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb
In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties.
A javascript function is added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb
In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view.html.erb
In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view.
* app/controllers/response_controller.rb
In this file, the new_feedback function will be edited to map the team-mate review questionnaires according to the duties created.
* app/questionnaire/new.html.erb
A new questionnaire will be created for each new duty created or the same questionnaire can be used.
* app/questionnaire/edit.html.erb
A newly created questionnaire for a particular duty can be edited.

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-04-14T02:16:16Z

Bjain: /* Test Plan */

==Introduction==

===Overview===

The project is a role-based reviewing project. These roles can be better named as duties, corresponding to the duty of a team member in a particular project/assignment. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example, one team member may work mainly on the documentation, another on writing tests and another member may write most of the code. Although there is no clear distinction in the duties as each team member still contributes to other duties, a much more meaningful review can be done if the review questionnaire was role specific rather than being assignment specific. Currently, there is a single teammate review rubric for each assignment. This means that some review rubrics are not applicable for all the projects and also for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests and it is definitely not applicable for the member who wrote the documentation. The project aims at creating different review rubrics for different duties, which an instructor can create for an assignment. Students can select a particular duty they want to perform in that project.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:
===Migration changes===
* . Create a migration for adding the duties table having the following fields:
* id
* assignment_id
* instructor_id
* course_id
* The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.
* Add a column entry named "is role based review enabled" in the assignments table which would be of type boolean. This field would save the status of the role based review checkbox.
* Add a column entry named "Can multiple students select the same role ?" in the assignments table which would be of type boolean. This field would save the status of the checkbox for multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, create a check box called "Is role based review allowed.? "that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a checkbox tag in the review strategy subpage of the edit assignments page.
* If the instructor selects the checkbox for role-based reviewing, then a button should appear for adding roles called “Add Duties” along with a dropdown to select from the previously added duties by the same instructor.
* . The duties appearing in the dropdown would consist of duties added by the instructor for any of his courses.
* This can be achieved by including a subform tag in the same table entry as the checkbox which should have a hidden attribute.
* . A javascript function would be created which is invoked when the status of the checkbox changes. This function should remove the hidden attribute of the subform tag if the checkbox is checked. This would enable the add duties field and the select duties dropdown to appear only on checking the box.
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* To implement this , another checkbox called "Can multiple students select the same role ? "is added in the review strategy subpage of the edit assignments page. This will be visible only if the role based reviewing checkbox is selected.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
* . The instructor would have to create questionnaires for the newly created duties in the standard way by going to manage questionnaires and creating a new public or private item.
* If the role based review checkbox is selected, the instructor would get a dropbox box to select the duty and another dropdown box to select the team-mate review questionnaire applicable for this duty. In this way , the instructor can select different questionnaires for different duties. If role based reviewing is not permitted on an assignment, the existing view with a single dropdown box for selecting the team-mate review would be displayed.
* This can be implemented by making changes in the rubrics subpage of the edit assignments page. A conditional statement would be included in the view which would show the modified view if role based review is permitted or else it would show the existing view.

===Student view changes===
* When a student goes to “Your team”, he should be able to select a duty from a drop down menu which would display all the duties added by an instructor for that particular assignment. This should only occur if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
* . This can be implemented by adding a dropdown box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box.However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
* . This can be implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it can be eliminated from the separate list maintained and that list can be displayed to the student. Thus , there will be a conditional in the student teams view file that displays the separate list in the dropdown if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
* . This can be implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement will be included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===

* db/migrate/add_duties_table.rb - In this file, a duties table is created with a name field and foreign key references.
* db/migrate/add_is_role_based_review_enabled_to_assignments.eb - In this file, a column named is_role_based_review_enabled is added to the Assignments table
* db/migrate/add_can_multiple_students_have_the _same_duty_to_assignments.rb - In this file, a column named is can_multiple_students_have_the_same_role is added to the Assignments table
* db/migrate/add_duties_to_users.rb . - In this file, a column named duties is added to the Users table

===Files that have to be modified===

* app/views/assignments/edit/review_strategy.html.erb . - In this file, a checkbox is added to permit role based review. A hidden checkbox is added to allow multiple students to have the same role and hidden fields for adding duties along with a dropdown box for selecting from existing duties. A javascript function should be added which removes the hidden attributes from for the above stated entries once the checkbox is selected.

* app/views/assignments/edit/rubrics.html.erb - In this file , a conditional statement is added, which displays the dropdown for selecting duties and a dropdown for selecting a teammate review for the selected duties if role based reviewing is permitted or else display the standard view.

* app/views/student_teams/view - In this file, a conditional statement is added which displays the select duties dropdown box is role based reviewing is allowed or else displays the standard view. Another conditional statement should be added which does not display the select duties option if the deadline has passed or else it displays it.
* app/tree_display/views/list
* app/questionnaire/new
* app/questionnaire/edit

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment.

* Student(team member) tests
** Before submitting the project, all team members should select a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, only the questions related to the role(duty) selected by the student should appear in the rubric.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-04-14T01:53:57Z

Bjain: /* Test Plan */

==Introduction==

===Overview===

The project is a role-based reviewing project. These roles can be better named as duties, corresponding to the duty of a team member in a particular project/assignment. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example, one team member may work mainly on the documentation, another on writing tests and another member may write most of the code. Although there is no clear distinction in the duties as each team member still contributes to other duties, a much more meaningful review can be done if the review questionnaire was role specific rather than being assignment specific. Currently, there is a single teammate review rubric for each assignment. This means that some review rubrics are not applicable for all the projects and also for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests and it is definitely not applicable for the member who wrote the documentation. The project aims at creating different review rubrics for different duties, which an instructor can create for an assignment. Students can select a particular duty they want to perform in that project.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:
===Migration changes===
* . Create a migration for adding the duties table having the following fields:
* id
* assignment_id
* instructor_id
* course_id
* The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.
* Add a column entry named "is role based review enabled" in the assignments table which would be of type boolean. This field would save the status of the role based review checkbox.
* Add a column entry named "Can multiple students select the same role ?" in the assignments table which would be of type boolean. This field would save the status of the checkbox for multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, create a check box called "Is role based review allowed.? "that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a checkbox tag in the review strategy subpage of the edit assignments page.
* If the instructor selects the checkbox for role-based reviewing, then a button should appear for adding roles called “Add Duties” along with a dropdown to select from the previously added duties by the same instructor.
* . The duties appearing in the dropdown would consist of duties added by the instructor for any of his courses.
* This can be achieved by including a subform tag in the same table entry as the checkbox which should have a hidden attribute.
* . A javascript function would be created which is invoked when the status of the checkbox changes. This function should remove the hidden attribute of the subform tag if the checkbox is checked. This would enable the add duties field and the select duties dropdown to appear only on checking the box.
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* To implement this , another checkbox called "Can multiple students select the same role ? "is added in the review strategy subpage of the edit assignments page. This will be visible only if the role based reviewing checkbox is selected.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
* . The instructor would have to create questionnaires for the newly created duties in the standard way by going to manage questionnaires and creating a new public or private item.
* If the role based review checkbox is selected, the instructor would get a dropbox box to select the duty and another dropdown box to select the team-mate review questionnaire applicable for this duty. In this way , the instructor can select different questionnaires for different duties. If role based reviewing is not permitted on an assignment, the existing view with a single dropdown box for selecting the team-mate review would be displayed.
* This can be implemented by making changes in the rubrics subpage of the edit assignments page. A conditional statement would be included in the view which would show the modified view if role based review is permitted or else it would show the existing view.

===Student view changes===
* When a student goes to “Your team”, he should be able to select a duty from a drop down menu which would display all the duties added by an instructor for that particular assignment. This should only occur if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
* . This can be implemented by adding a dropdown box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box.However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
* . This can be implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it can be eliminated from the separate list maintained and that list can be displayed to the student. Thus , there will be a conditional in the student teams view file that displays the separate list in the dropdown if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
* . This can be implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement will be included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===

* Duties Table
** Duty ID
** Name of duty
** Instructor user id

===Files that have to be modified===

* app/views/assignment/edit

* app/views/student_teams/view
* app/tree_display/views/list
* app/questionnaire/new
* app/questionnaire/edit

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) with option to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment./

* Student(team member) tests
** Before submitting the project, the team members should be able to add a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, students with different roles(duties) should have different questions because of the different rubrics.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-04-14T01:53:20Z

Bjain: /* Test Plan */

==Introduction==

===Overview===

The project is a role-based reviewing project. These roles can be better named as duties, corresponding to the duty of a team member in a particular project/assignment. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example, one team member may work mainly on the documentation, another on writing tests and another member may write most of the code. Although there is no clear distinction in the duties as each team member still contributes to other duties, a much more meaningful review can be done if the review questionnaire was role specific rather than being assignment specific. Currently, there is a single teammate review rubric for each assignment. This means that some review rubrics are not applicable for all the projects and also for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests and it is definitely not applicable for the member who wrote the documentation. The project aims at creating different review rubrics for different duties, which an instructor can create for an assignment. Students can select a particular duty they want to perform in that project.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:
===Migration changes===
* . Create a migration for adding the duties table having the following fields:
* id
* assignment_id
* instructor_id
* course_id
* The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.
* Add a column entry named "is role based review enabled" in the assignments table which would be of type boolean. This field would save the status of the role based review checkbox.
* Add a column entry named "Can multiple students select the same role ?" in the assignments table which would be of type boolean. This field would save the status of the checkbox for multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, create a check box called "Is role based review allowed.? "that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a checkbox tag in the review strategy subpage of the edit assignments page.
* If the instructor selects the checkbox for role-based reviewing, then a button should appear for adding roles called “Add Duties” along with a dropdown to select from the previously added duties by the same instructor.
* . The duties appearing in the dropdown would consist of duties added by the instructor for any of his courses.
* This can be achieved by including a subform tag in the same table entry as the checkbox which should have a hidden attribute.
* . A javascript function would be created which is invoked when the status of the checkbox changes. This function should remove the hidden attribute of the subform tag if the checkbox is checked. This would enable the add duties field and the select duties dropdown to appear only on checking the box.
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* To implement this , another checkbox called "Can multiple students select the same role ? "is added in the review strategy subpage of the edit assignments page. This will be visible only if the role based reviewing checkbox is selected.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
* . The instructor would have to create questionnaires for the newly created duties in the standard way by going to manage questionnaires and creating a new public or private item.
* If the role based review checkbox is selected, the instructor would get a dropbox box to select the duty and another dropdown box to select the team-mate review questionnaire applicable for this duty. In this way , the instructor can select different questionnaires for different duties. If role based reviewing is not permitted on an assignment, the existing view with a single dropdown box for selecting the team-mate review would be displayed.
* This can be implemented by making changes in the rubrics subpage of the edit assignments page. A conditional statement would be included in the view which would show the modified view if role based review is permitted or else it would show the existing view.

===Student view changes===
* When a student goes to “Your team”, he should be able to select a duty from a drop down menu which would display all the duties added by an instructor for that particular assignment. This should only occur if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
* . This can be implemented by adding a dropdown box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box.However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
* . This can be implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it can be eliminated from the separate list maintained and that list can be displayed to the student. Thus , there will be a conditional in the student teams view file that displays the separate list in the dropdown if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
* . This can be implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement will be included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===

* Duties Table
** Duty ID
** Name of duty
** Instructor user id

===Files that have to be modified===

* app/views/assignment/edit

* app/views/student_teams/view
* app/tree_display/views/list
* app/questionnaire/new
* app/questionnaire/edit

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Display and select from already existing roles(duties) and able to create new roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment./

* Student(team member) tests
** Before submitting the project, the team members should be able to add a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, students with different roles(duties) should have different questions because of the different rubrics.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-04-14T01:51:26Z

Bjain: /* Test Plan */

==Introduction==

===Overview===

The project is a role-based reviewing project. These roles can be better named as duties, corresponding to the duty of a team member in a particular project/assignment. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example, one team member may work mainly on the documentation, another on writing tests and another member may write most of the code. Although there is no clear distinction in the duties as each team member still contributes to other duties, a much more meaningful review can be done if the review questionnaire was role specific rather than being assignment specific. Currently, there is a single teammate review rubric for each assignment. This means that some review rubrics are not applicable for all the projects and also for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests and it is definitely not applicable for the member who wrote the documentation. The project aims at creating different review rubrics for different duties, which an instructor can create for an assignment. Students can select a particular duty they want to perform in that project.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:
===Migration changes===
* . Create a migration for adding the duties table having the following fields:
* id
* assignment_id
* instructor_id
* course_id
* The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.
* Add a column entry named "is role based review enabled" in the assignments table which would be of type boolean. This field would save the status of the role based review checkbox.
* Add a column entry named "Can multiple students select the same role ?" in the assignments table which would be of type boolean. This field would save the status of the checkbox for multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, create a check box called "Is role based review allowed.? "that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a checkbox tag in the review strategy subpage of the edit assignments page.
* If the instructor selects the checkbox for role-based reviewing, then a button should appear for adding roles called “Add Duties” along with a dropdown to select from the previously added duties by the same instructor.
* . The duties appearing in the dropdown would consist of duties added by the instructor for any of his courses.
* This can be achieved by including a subform tag in the same table entry as the checkbox which should have a hidden attribute.
* . A javascript function would be created which is invoked when the status of the checkbox changes. This function should remove the hidden attribute of the subform tag if the checkbox is checked. This would enable the add duties field and the select duties dropdown to appear only on checking the box.
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* To implement this , another checkbox called "Can multiple students select the same role ? "is added in the review strategy subpage of the edit assignments page. This will be visible only if the role based reviewing checkbox is selected.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
* . The instructor would have to create questionnaires for the newly created duties in the standard way by going to manage questionnaires and creating a new public or private item.
* If the role based review checkbox is selected, the instructor would get a dropbox box to select the duty and another dropdown box to select the team-mate review questionnaire applicable for this duty. In this way , the instructor can select different questionnaires for different duties. If role based reviewing is not permitted on an assignment, the existing view with a single dropdown box for selecting the team-mate review would be displayed.
* This can be implemented by making changes in the rubrics subpage of the edit assignments page. A conditional statement would be included in the view which would show the modified view if role based review is permitted or else it would show the existing view.

===Student view changes===
* When a student goes to “Your team”, he should be able to select a duty from a drop down menu which would display all the duties added by an instructor for that particular assignment. This should only occur if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
* . This can be implemented by adding a dropdown box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box.However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
* . This can be implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it can be eliminated from the separate list maintained and that list can be displayed to the student. Thus , there will be a conditional in the student teams view file that displays the separate list in the dropdown if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
* . This can be implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement will be included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===

* Duties Table
** Duty ID
** Name of duty
** Instructor user id

===Files that have to be modified===

* app/views/assignment/edit

* app/views/student_teams/view
* app/tree_display/views/list
* app/questionnaire/new
* app/questionnaire/edit

==Test Plan==

* Instructor tests
** Check the box for role based reviewing.
*** Able to create new roles(duties) and select from already existing roles(duties).
*** Should not be able to see roles(duties) from other instructors.
*** Select corresponding rubrics for a particular role(duty).
** If not, proceed with the default questions for the rubric for the assignment./

* Student(team member) tests
** Before submitting the project, the team members should be able to add a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, students with different roles(duties) should have different questions because of the different rubrics.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-04-14T01:50:07Z

Bjain: /* Test Plan */

==Introduction==

===Overview===

The project is a role-based reviewing project. These roles can be better named as duties, corresponding to the duty of a team member in a particular project/assignment. Borrowing from different Agile methodologies like SCRUM, each team member has a particular role. For example, one team member may work mainly on the documentation, another on writing tests and another member may write most of the code. Although there is no clear distinction in the duties as each team member still contributes to other duties, a much more meaningful review can be done if the review questionnaire was role specific rather than being assignment specific. Currently, there is a single teammate review rubric for each assignment. This means that some review rubrics are not applicable for all the projects and also for all team members. For instance, if there is a question which says “What percentage of the code was written by this member?” This may not be applicable for the team member who wrote tests and it is definitely not applicable for the member who wrote the documentation. The project aims at creating different review rubrics for different duties, which an instructor can create for an assignment. Students can select a particular duty they want to perform in that project.

==UML Diagram==

[[File:Uml2.PNG]]

In a UML Class diagram, The relationships depicted above are as follows:

* Between the User and Duty class, there is a bidirectional association. The user table is used for both the instructor and the student.
** Each instructor can have multiple roles that he can choose from for a particular assignment/questionnaire.
** Each student can have 0 or 1 role for a particular project.
* For each Questionnaire instance, there are one or more Questions that can be stored, hence there is an aggregation relationship from Question to Questionnaire. This is for the grading rubric based on the role.
* The Question table and the Questionnaire table each will be using the the duty ID to sort out questions for a particular assignment.

==Proposed Implementation==

The project introduces changes from the instructor view and the student view. The steps for implementation are as follow:
===Migration changes===
* . Create a migration for adding the duties table having the following fields:
* id
* assignment_id
* instructor_id
* course_id
* The duty ID will be used by other tables like the questionnaire table and hence will be the primary key.
* An assignment has particular duties. Thus, the assignment number will be the foreign key for the Duties table.
* The Duties created by one Instructor should be visible and reusable by that instructor only. Thus, the instructor id will also be a foreign key in the Duties table.
* Add a column entry named "is role based review enabled" in the assignments table which would be of type boolean. This field would save the status of the role based review checkbox.
* Add a column entry named "Can multiple students select the same role ?" in the assignments table which would be of type boolean. This field would save the status of the checkbox for multiple students with the same role.
* Add a column entry named "Duties" to the Users table which would be of type string. This field would save the duty that a student would select if role based reviews are permitted.

===Instructor view changes===
* For a particular assignment, create a check box called "Is role based review allowed.? "that allows an instructor to add a role based review for a particular assignment or not. This can be done by adding a checkbox tag in the review strategy subpage of the edit assignments page.
* If the instructor selects the checkbox for role-based reviewing, then a button should appear for adding roles called “Add Duties” along with a dropdown to select from the previously added duties by the same instructor.
* . The duties appearing in the dropdown would consist of duties added by the instructor for any of his courses.
* This can be achieved by including a subform tag in the same table entry as the checkbox which should have a hidden attribute.
* . A javascript function would be created which is invoked when the status of the checkbox changes. This function should remove the hidden attribute of the subform tag if the checkbox is checked. This would enable the add duties field and the select duties dropdown to appear only on checking the box.
* An instructor can decide the number of duties for a particular assignment, the number of team members who can undertake a particular duty and if any of the duties are optional.
* To implement this , another checkbox called "Can multiple students select the same role ? "is added in the review strategy subpage of the edit assignments page. This will be visible only if the role based reviewing checkbox is selected.
* The instructor can create Team-mate review Questionnaires for the different duties he created or can use any from the existing list of questionnaires.
* . The instructor would have to create questionnaires for the newly created duties in the standard way by going to manage questionnaires and creating a new public or private item.
* If the role based review checkbox is selected, the instructor would get a dropbox box to select the duty and another dropdown box to select the team-mate review questionnaire applicable for this duty. In this way , the instructor can select different questionnaires for different duties. If role based reviewing is not permitted on an assignment, the existing view with a single dropdown box for selecting the team-mate review would be displayed.
* This can be implemented by making changes in the rubrics subpage of the edit assignments page. A conditional statement would be included in the view which would show the modified view if role based review is permitted or else it would show the existing view.

===Student view changes===
* When a student goes to “Your team”, he should be able to select a duty from a drop down menu which would display all the duties added by an instructor for that particular assignment. This should only occur if role based reviewing is permitted for that particular assignment. If not, the standard existing view will be displayed which does not give any such option.
* . This can be implemented by adding a dropdown box in the student_teams view file. This would be enclosed in a conditional which would only appear if role based reviewing is permitted.
* A student can only select one duty.
* If the instructor has permitted multiple students to have the same role, each student will get all the duties as an option in the dropdown box.However, if the instructor has not provided permission for multiple students to have the same role, when a particular duty is selected by a student , any other student will not see that duty in the drop down box.
* . This can be implemented by making a separate copy of the list of all the duties available. If multiple roles are not permitted, once a duty is selected , it can be eliminated from the separate list maintained and that list can be displayed to the student. Thus , there will be a conditional in the student teams view file that displays the separate list in the dropdown if multiple students can have the same role or else display the original list of duties.
* A team member cannot change their role after the assignment submission deadline.
* . This can be implemented by taking the time and date information from the server and showing the select duties option only if the current time and date is prior to the deadline time and date. A conditional statement will be included in the student teams view file for this purpose.
* When a student selects a particular duty , it is stored in the database table of that user. Thus when a team-mate reviews that student , he will see a questionnaire corresponding to the duty of that student.This would enable reviews of the teammates to be accurate and specific to their role in a project.

==Files to be modified==

===New files===

* Duties Table
** Duty ID
** Name of duty
** Instructor user id

===Files that have to be modified===

* app/views/assignment/edit

* app/views/student_teams/view
* app/tree_display/views/list
* app/questionnaire/new
* app/questionnaire/edit

==Test Plan==

* Instructor tests
** Check the box for role based reviewing. If not, proceed with the default default questions for the rubric for the assignment.
** Able to create new roles(duties) and select from already existing roles(duties).
** Should not be able to see roles(duties) from other instructors.
** Select corresponding rubrics for a particular role(duty).

* Student(team member) tests
** Before submitting the project, the team members should be able to add a role(duty) for themselves from the roles(duties) set by the instructor.
** Multiple students may have the role(duty) but 1 student cannot have multiple roles(duties).

* Reviewer tests
** For the teammate review, students with different roles(duties) should have different questions because of the different rubrics.

CSC/ECE 517 Spring 2018- Project E1818: Role-based reviewing

2018-04-14T01:40:32Z

Bjain: /* Test Plan */

File:Uml1.png

2018-04-14T01:31:13Z

Bjain: uploaded a new version of "File:Uml1.png": Reverted to version as of 01:24, 14 April 2018

File:Uml1.png

2018-04-14T01:31:05Z

Bjain: uploaded a new version of "File:Uml1.png": Reverted to version as of 01:24, 14 April 2018

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-04-03T05:17:11Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb.

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

1. Where to start in the process

2. What to test and what not to test

3. How much to test in one go

4. What to call the tests

5. How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;

Make the tests fail;

Then implement the unit;

Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early: Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change: Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration: Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation: Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design: When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are:

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating stub entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name: This parameter gives the name to the menu item.

2. Label: This parameter gives the label to the menu item.

3. Parent id: It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.

4. Sequence id: It gives the sequence numbering for determining the way the attributes are ordered within a parent.

5. Controller action id: This parameter is associated with the direction in which the user is directed onto.

6. Content page id: This parameter is also associated with the direction in which the user is directed onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are:

1. find_or_create_by_name(params): Class Method
This method finds or creates a new entry with the given name obtained in params.

2. delete: Instance Method
This methods deletes the entry and all the child entries (entries having the same parent id) lined to it

3. above: Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below: Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id): Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id): Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission: Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Stub objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "Let" and "MenuItem.create" method, giving different values for each of the test inputs to cover the required testing conditions.

let!(:menuitem) {MenuItem.create id: 1, parent_id: nil, name: "navigate", label: "Navigate", seq: 1, controller_action_id: 1, content_page_id: 1}

The above is an example entry used for menu item. 5 more similar objects were created with entries giving combinations of parent_id, sequence numbers and controller_action_id. We also created objects for controller_action and content_page which were used to define conditions for coverage of items_for_permission.

=== Testing Conditions ===

A total of 13 unit tests were performed for testing all the functions in menu items model file and achieving complete code coverage.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:
In this test case we check whether the find_or_create_by_name function returns a valid menu item.

2. #delete:
For this test case, we delete a parent menu item and check whether the count of total item reduces considering parent and child items are also deleted.

3. #above: Test cases were written to check the below conditions:
3.1 If the given menu item has a valid parent_id, return the previous menu item in terms of sequence number that is a child of the same parent_id.
3.2 If the given menu item has a null parent_id, return the previous menu item in terms of sequence number that also has a null parent_id value.

4. #below: Test cases were written to check the below conditions:
4.1 If the given menu item has a valid parent_id, return the next menu item in terms of sequence number that is a child of the same parent_id.
4.2 If the given menu item has a null parent_id, return the next menu item in terms of sequence number that also has a null parent_id value.

5. .repack: Test cases were written to check the below conditions:
5.1 If the given menu item is updated and parent id is valid, repack is called with current menu item id as repack id and re calculate sequence number for all child items.
5.2 If the given menu item is updated and parent id is null, repack is called with parent id of current menu and sequence number is recalculated for all child items.

6. .next_seq: Test cases were written to check the below conditions:
6.1 If parent id is not null and next_seq is called, the function increments the maximum sequence number for that parent group and returns that value to be stored as the next sequence number for the new menu item.
6.2 If parent id is null, and next_seq is called, the function increments the maximum sequence number amongst all menu items having parent id as null and returns that value to be stored as the next sequence number for the new menu item.

7. .items_for_permissions: Test cases were written to check the below conditions:
7.1 If permission id is null, we check if the controller action id is greater than zero and add menu items to a list accordingly.
7.2 If permission id is not null, we check if controller action id is greater than zero. If not, we check the items for matching content page id and list menu items accordingly.

== Conclusion ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application. After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder. This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers, Models, Helpers in the app directory.

For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from 0 to 100.
Following are the screenshots of the completed code coverage taken from coverage/index.html:
[[File:Coverage1.PNG]]
[[File:Coverage2.PNG]]
[[File:Coverage3.PNG]]
==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/angad8292/expertiza/blob/master/spec/models/menu_item_spec.rb GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-04-03T05:16:28Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb.

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

1. Where to start in the process

2. What to test and what not to test

3. How much to test in one go

4. What to call the tests

5. How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;

Make the tests fail;

Then implement the unit;

Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early: Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change: Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration: Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation: Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design: When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are:

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating stub entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name: This parameter gives the name to the menu item.

2. Label: This parameter gives the label to the menu item.

3. Parent id: It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.

4. Sequence id: It gives the sequence numbering for determining the way the attributes are ordered within a parent.

5. Controller action id: This parameter is associated with the direction in which the user is directed onto.

6. Content page id: This parameter is also associated with the direction in which the user is directed onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are:

1. find_or_create_by_name(params): Class Method
This method finds or creates a new entry with the given name obtained in params.

2. delete: Instance Method
This methods deletes the entry and all the child entries (entries having the same parent id) lined to it

3. above: Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below: Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id): Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id): Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission: Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Stub objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "Let" and "MenuItem.create" method, giving different values for each of the test inputs to cover the required testing conditions.

let!(:menuitem) {MenuItem.create id: 1, parent_id: nil, name: "navigate", label: "Navigate", seq: 1, controller_action_id: 1, content_page_id: 1}

The above is an example entry used for menu item. 5 more similar objects were created with entries giving combinations of parent_id, sequence numbers and controller_action_id. We also created objects for controller_action and content_page which were used to define conditions for coverage of items_for_permission.

=== Testing Conditions ===

A total of 13 unit tests were performed for testing all the functions in menu items model file and achieving complete code coverage.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:
In this test case we check whether the find_or_create_by_name function returns a valid menu item.

2. #delete:
For this test case, we delete a parent menu item and check whether the count of total item reduces considering parent and child items are also deleted.

3. #above: Test cases were written to check the below conditions:
3.1 If the given menu item has a valid parent_id, return the previous menu item in terms of sequence number that is a child of the same parent_id.
3.2 If the given menu item has a null parent_id, return the previous menu item in terms of sequence number that also has a null parent_id value.

4. #below: Test cases were written to check the below conditions:
4.1 If the given menu item has a valid parent_id, return the next menu item in terms of sequence number that is a child of the same parent_id.
4.2 If the given menu item has a null parent_id, return the next menu item in terms of sequence number that also has a null parent_id value.

5. .repack: Test cases were written to check the below conditions:
5.1 If the given menu item is updated and parent id is valid, repack is called with current menu item id as repack id and re calculate sequence number for all child items.
5.2 If the given menu item is updated and parent id is null, repack is called with parent id of current menu and sequence number is recalculated for all child items.

6. .next_seq: Test cases were written to check the below conditions:
6.1 If parent id is not null and next_seq is called, the function increments the maximum sequence number for that parent group and returns that value to be stored as the next sequence number for the new menu item.
6.2 If parent id is null, and next_seq is called, the function increments the maximum sequence number amongst all menu items having parent id as null and returns that value to be stored as the next sequence number for the new menu item.

7. .items_for_permissions: Test cases were written to check the below conditions:
7.1 If permission id is null, we check if the controller action id is greater than zero and add menu items to a list accordingly.
7.2 If permission id is not null, we check if controller action id is greater than zero. If not, we check the items for matching content page id and list menu items accordingly.

== Conclusion ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application. After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder. This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers, Models, Helpers in the app directory.

For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from 0 to 100.
Following are the screenshots of the completed code coverage:
[[File:Coverage1.PNG]]
[[File:Coverage2.PNG]]
[[File:Coverage3.PNG]]
==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/angad8292/expertiza/blob/master/spec/models/menu_item_spec.rb GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

File:Coverage3.PNG

2018-04-03T05:15:38Z

Bjain: uploaded a new version of "File:Coverage3.PNG"

File:Coverage3.PNG

2018-04-03T05:12:10Z

Bjain:

File:Coverage2.PNG

2018-04-03T05:12:00Z

Bjain:

File:Coverage1.PNG

2018-04-03T05:09:16Z

Bjain:

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-03-27T03:55:56Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb.

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

1. Where to start in the process

2. What to test and what not to test

3. How much to test in one go

4. What to call the tests

5. How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;

Make the tests fail;

Then implement the unit;

Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early: Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change: Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration: Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation: Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design: When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are:

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating stub entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name: This parameter gives the name to the menu item.

2. Label: This parameter gives the label to the menu item.

3. Parent id: It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.

4. Sequence id: It gives the sequence numbering for determining the way the attributes are ordered within a parent.

5. Controller action id: This parameter is associated with the direction in which the user is directed onto.

6. Content page id: This parameter is also associated with the direction in which the user is directed onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are:

1. find_or_create_by_name(params): Class Method
This method finds or creates a new entry with the given name obtained in params.

2. delete: Instance Method
This methods deletes the entry and all the child entries (entries having the same parent id) lined to it

3. above: Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below: Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id): Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id): Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission: Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Stub objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "Let" and "MenuItem.create" method, giving different values for each of the test inputs to cover the required testing conditions.

let!(:menuitem) {MenuItem.create id: 1, parent_id: nil, name: "navigate", label: "Navigate", seq: 1, controller_action_id: 1, content_page_id: 1}

The above is an example entry used for menu item. 5 more similar objects were created with entries giving combinations of parent_id, sequence numbers and controller_action_id. We also created objects for controller_action and content_page which were used to define conditions for coverage of items_for_permission.

=== Testing Conditions ===

A total of 13 unit tests were performed for testing all the functions in menu items model file and achieving complete code coverage.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:
In this test case we check whether the find_or_create_by_name function returns a valid menu item.

2. #delete:
For this test case, we delete a parent menu item and check whether the count of total item reduces considering parent and child items are also deleted.

3. #above: Test cases were written to check the below conditions:
3.1 If the given menu item has a valid parent_id, return the previous menu item in terms of sequence number that is a child of the same parent_id.
3.2 If the given menu item has a null parent_id, return the previous menu item in terms of sequence number that also has a null parent_id value.

4. #below: Test cases were written to check the below conditions:
4.1 If the given menu item has a valid parent_id, return the next menu item in terms of sequence number that is a child of the same parent_id.
4.2 If the given menu item has a null parent_id, return the next menu item in terms of sequence number that also has a null parent_id value.

5. .repack: Test cases were written to check the below conditions:
5.1 If the given menu item is updated and parent id is valid, repack is called with current menu item id as repack id and re calculate sequence number for all child items.
5.2 If the given menu item is updated and parent id is null, repack is called with parent id of current menu and sequence number is recalculated for all child items.

6. .next_seq: Test cases were written to check the below conditions:
6.1 If parent id is not null and next_seq is called, the function increments the maximum sequence number for that parent group and returns that value to be stored as the next sequence number for the new menu item.
6.2 If parent id is null, and next_seq is called, the function increments the maximum sequence number amongst all menu items having parent id as null and returns that value to be stored as the next sequence number for the new menu item.

7. .items_for_permissions: Test cases were written to check the below conditions:
7.1 If permission id is null, we check if the controller action id is greater than zero and add menu items to a list accordingly.
7.2 If permission id is not null, we check if controller action id is greater than zero. If not, we check the items for matching content page id and list menu items accordingly.

== Conclusion ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application. After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder. This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers, Models, Helpers in the app directory.

For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from 0 to 100.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/angad8292/expertiza/blob/master/spec/models/menu_item_spec.rb GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-03-27T03:54:36Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb.

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

1. Where to start in the process

2. What to test and what not to test

3. How much to test in one go

4. What to call the tests

5. How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;

Make the tests fail;

Then implement the unit;

Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early: Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change: Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration: Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation: Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design: When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are:

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name: This parameter gives the name to the menu item.

2. Label: This parameter gives the label to the menu item.

3. Parent id: It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.

4. Sequence id: It gives the sequence numbering for determining the way the attributes are ordered within a parent.

5. Controller action id: This parameter is associated with the direction in which the user is directed onto.

6. Content page id: This parameter is also associated with the direction in which the user is directed onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are:

1. find_or_create_by_name(params): Class Method
This method finds or creates a new entry with the given name obtained in params.

2. delete: Instance Method
This methods deletes the entry and all the child entries (entries having the same parent id) lined to it

3. above: Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below: Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id): Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id): Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission: Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "Let" and "MenuItem.create" method, giving different values for each of the test inputs to cover the required testing conditions.

let!(:menuitem) {MenuItem.create id: 1, parent_id: nil, name: "navigate", label: "Navigate", seq: 1, controller_action_id: 1, content_page_id: 1}

The above is an example entry used for menu item. 5 more similar objects were created with entries giving combinations of parent_id, sequence numbers and controller_action_id. We also created objects for controller_action and content_page which were used to define conditions for coverage of items_for_permission.

=== Testing Conditions ===

A total of 13 unit tests were performed for testing all the functions in menu items model file and achieving complete code coverage.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:
In this test case we check whether the find_or_create_by_name function returns a valid menu item.

2. #delete:
For this test case, we delete a parent menu item and check whether the count of total item reduces considering parent and child items are also deleted.

3. #above: Test cases were written to check the below conditions:
3.1 If the given menu item has a valid parent_id, return the previous menu item in terms of sequence number that is a child of the same parent_id.
3.2 If the given menu item has a null parent_id, return the previous menu item in terms of sequence number that also has a null parent_id value.

4. #below: Test cases were written to check the below conditions:
4.1 If the given menu item has a valid parent_id, return the next menu item in terms of sequence number that is a child of the same parent_id.
4.2 If the given menu item has a null parent_id, return the next menu item in terms of sequence number that also has a null parent_id value.

5. .repack: Test cases were written to check the below conditions:
5.1 If the given menu item is updated and parent id is valid, repack is called with current menu item id as repack id and re calculate sequence number for all child items.
5.2 If the given menu item is updated and parent id is null, repack is called with parent id of current menu and sequence number is recalculated for all child items.

6. .next_seq: Test cases were written to check the below conditions:
6.1 If parent id is not null and next_seq is called, the function increments the maximum sequence number for that parent group and returns that value to be stored as the next sequence number for the new menu item.
6.2 If parent id is null, and next_seq is called, the function increments the maximum sequence number amongst all menu items having parent id as null and returns that value to be stored as the next sequence number for the new menu item.

7. .items_for_permissions: Test cases were written to check the below conditions:
7.1 If permission id is null, we check if the controller action id is greater than zero and add menu items to a list accordingly.
7.2 If permission id is not null, we check if controller action id is greater than zero. If not, we check the items for matching content page id and list menu items accordingly.

== Conclusion ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application. After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder. This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers, Models, Helpers in the app directory.

For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from 0 to 100.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/angad8292/expertiza/blob/master/spec/models/menu_item_spec.rb GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-03-27T03:52:09Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb.

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

1. Where to start in the process

2. What to test and what not to test

3. How much to test in one go

4. What to call the tests

5. How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;

Make the tests fail;

Then implement the unit;

Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early: Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change: Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration: Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation: Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design: When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are:

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name: This parameter gives the name to the menu item.

2. Label: This parameter gives the label to the menu item.

3. Parent id: It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.

4. Sequence id: It gives the sequence numbering for determining the way the attributes are ordered within a parent.

5. Controller action id: This parameter is associated with the direction in which the user is directed onto.

6. Content page id: This parameter is also associated with the direction in which the user is directed onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are:

1. find_or_create_by_name(params): Class Method
This method finds or creates a new entry with the given name obtained in params.

2. delete: Instance Method
This methods deletes the entry and all the child entries (entries having the same parent id) lined to it

3. above: Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below: Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id): Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id): Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission: Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "Let" and "MenuItem.create" method, giving different values for each of the test inputs to cover the required testing conditions.

let!(:menuitem) {MenuItem.create id: 1, parent_id: nil, name: "navigate", label: "Navigate", seq: 1, controller_action_id: 1, content_page_id: 1}

The above is an example entry used for menu item. 5 more similar objects were created with entries giving combinations of parent_id, sequence numbers and controller_action_id. We also created objects for controller_action and content_page which were used to define conditions for coverage of items_for_permission.

=== Testing Conditions ===
=== Testing Conditions ===
A total of 13 unit tests were performed for testing all the functions in menu items model file and achieving complete code coverage.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:
In this test case we check whether the find_or_create_by_name function returns a valid menu item.

2. #delete:
For this test case, we delete a parent menu item and check whether the count of total item reduces considering parent and child items are also deleted.

3. #above: Test cases were written to check the below conditions:
3.1 If the given menu item has a valid parent_id, return the previous menu item in terms of sequence number that is a child of the same parent_id.
3.2 If the given menu item has a null parent_id, return the previous menu item in terms of sequence number that also has a null parent_id value.

4. #below: Test cases were written to check the below conditions:
4.1 If the given menu item has a valid parent_id, return the next menu item in terms of sequence number that is a child of the same parent_id.
4.2 If the given menu item has a null parent_id, return the next menu item in terms of sequence number that also has a null parent_id value.

5. .repack: Test cases were written to check the below conditions:
5.1 If the given menu item is updated and parent id is valid, repack is called with current menu item id as repack id and re calculate sequence number for all child items.
5.2 If the given menu item is updated and parent id is null, repack is called with parent id of current menu and sequence number is recalculated for all child items.

6. .next_seq: Test cases were written to check the below conditions:
6.1 If parent id is not null and next_seq is called, the function increments the maximum sequence number for that parent group and returns that value to be stored as the next sequence number for the new menu item.
6.2 If parent id is null, and next_seq is called, the function increments the maximum sequence number amongst all menu items having parent id as null and returns that value to be stored as the next sequence number for the new menu item.

7. .items_for_permissions: Test cases were written to check the below conditions:
7.1 If permission id is null, we check if the controller action id is greater than zero and add menu items to a list accordingly.
7.2 If permission id is not null, we check if controller action id is greater than zero. If not, we check the items for matching content page id and list menu items accordingly.

== Conclusion ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application. After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder. This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers, Models, Helpers in the app directory.

For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from 0 to 100.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/angad8292/expertiza/blob/master/spec/models/menu_item_spec.rb GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-03-27T03:38:41Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

1. Where to start in the process

2. What to test and what not to test

3. How much to test in one go

4. What to call the tests

5. How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;

Make the tests fail;

Then implement the unit;

Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early: Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change: Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration: Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation: Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design: When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are:

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, clone and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name: This parameter gives the name to the menu item.

2. Label: This parameter gives the label to the menu item.

3. Parent id: It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.

4. Sequence id: It gives the sequence numbering for determining the way the attributes are ordered within a parent.

5. Controller action id: This parameter is associated with the direction in which the user is directed onto.

6. Content page id: This parameter is also associated with the direction in which the user is directed onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are:

1. find_or_create_by_name(params): Class Method
This method finds or creates a new entry with the given name obtained in params.

2. delete: Instance Method
This methods deletes the entry and all the child entries (entries having the same parent id) lined to it

3. above: Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below: Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id): Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id): Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission: Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "Let" and "MenuItem.create" method, giving different values for each of the test inputs to cover the required testing conditions.

let!(:menuitem) {MenuItem.create id: 1, parent_id: nil, name: "navigate", label: "Navigate", seq: 1, controller_action_id: 1, content_page_id: 1}

The above is an example entry used for menu item. 5 more similar objects were created with entries giving combinations of parent_id, sequence numbers and controller_action_id. We also created objects for controller_action and content_page which were used to define conditions for coverage of items_for_permission.

=== Testing Conditions ===
A total of 16 testing conditions were required to be performed for testing all the functions in menu items model file.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:

In this we had write unit test cases to test if the method returned a menu_item corresponding to a name.
Here we expect that if the method find_or_create_by_name() is passed the parameter "home", then it should return a value equal to "home"

2. #delete:

In this test cases were written to check if the method deletes current menu items and all child menu items.
In this case, if the parent menu item is deleted, all its child record should should be deleted.
For our specific case, the parent and its 3 child menu_items are expected to be deleted.

3. #above:

Test cases were written to check if the below conditions are satisfied:

3.1 "When current menu item has parent_id, the method returns the first parent menu item by querying the parent_id and current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test4, the method should return a value equal to the active record test3.

3.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test5, the method should return a value equal to the active record test1.

4. #below:

Test cases were written to check if the below conditions are satisfied:

4.1 "When current menu item has parent_id,the method returns the first parent menu item by querying the parent_id and current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test3, the method should return a value equal to the active record test4

4.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test1, the method should return a value equal to the active record test5.

5. .repack:

Test cases were written to check if the below conditions are satisfied:

5.1 "When current menu item has repack_id, the method finds all menus items with parent_id equal to repack_id and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value 1,
then, it will repack the sequence ids and returns the list of repacked seq_ids.
5.2 "When current menu item does not have repack_id, the method finds all menus items with parent_id null and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value Null,
it will match all the values with parent_id = Null and returns the list of repacked seq_ids.

6. .next_seq:

Test cases were written to check if the below conditions are satisfied:

6.1 "When parent_id is bigger than 0, the method selects corresponding menu items with inputted parent_id and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value 1, the method should return a value equal to 5.

6.2 "When parent_id is smaller than or equal to 0, the method selects corresponding menu items with parent_id null and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value nil, the method should return a value equal to 6.

7. .items_for_permissions:

Test cases were written to check if the below conditions are satisfied:

7.1 "When inputted variable (permission_ids) is nil and when the controller_action_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.2 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.3 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
the method should return an empty list.
7.4 "When inputted variable (permission_ids) is not nil and when the controller_action_id of current item is bigger than 0 and when perms exists,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records
which satisfy the condition.
7.5 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0, and when perms exists,
the method returns corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records which satisfy the condition.
7.6 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as a parameter,
the method should return an empty list.

== Conclusion ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application. After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder. This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers, Models, Helpers in the app directory.

For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from 0 to 100.

The learning outcomes after performing this project can be summarized in the following points:

1. We got an hands on experience about how to write tests following the Test Driven Development approach.

2. We learned about how to write units tests for models and controllers in RSpec.

3. We also learned how to understand the functionality of an already developed application.For our case, before writing the test cases for the menu_items.rb we had the understand how different models interacted with each other and how each action by different users would make changes in the database schema.

4. We also gained a better understanding about how different tables, columns of a large applications in structured in the database schema.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/angad8292/expertiza/blob/master/spec/models/menu_item_spec.rb GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-03-27T03:32:19Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

1. Where to start in the process

2. What to test and what not to test

3. How much to test in one go

4. What to call the tests

5. How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;

Make the tests fail;

Then implement the unit;

Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are:

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, clone and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name : This parameter gives the name to the menu item.

2. Label : This parameter gives the label to the menu item.

3. Parent id : It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.

4. Sequence id : It gives the sequence numbering for determining the way the attributes are ordered within a parent.

5. Controller action id : This parameter is associated with the direction in which the user is directed onto.

6. Content page id : This parameter is also associated with the direction in which the user is directed onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are:

1. find_or_create_by_name(params) : Class Method
This method finds or creates a new entry with the given name obtained in params.

2. delete : Instance Method
This methods deletes the entry and all the child entries (entries having the same parent id) lined to it

3. above : Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below : Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id) : Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id) : Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission : Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "Let" and "MenuItem.create" method, giving different values for each of the test inputs to cover the required testing conditions.

let!(:menuitem) {MenuItem.create id: 1, parent_id: nil, name: "navigate", label: "Navigate", seq: 1, controller_action_id: 1, content_page_id: 1}

The above is an example entry used for menu item. 5 more similar objects were created with entries giving combinations of parent_id, sequence numbers and controller_action_id. We also created objects for controller_action and content_page which were used to define conditions for coverage of items_for_permission.

=== Testing Conditions ===
A total of 16 testing conditions were required to be performed for testing all the functions in menu items model file.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:

In this we had write unit test cases to test if the method returned a menu_item corresponding to a name.
Here we expect that if the method find_or_create_by_name() is passed the parameter "home", then it should return a value equal to "home"

2. #delete:

In this test cases were written to check if the method deletes current menu items and all child menu items.
In this case, if the parent menu item is deleted, all its child record should should be deleted.
For our specific case, the parent and its 3 child menu_items are expected to be deleted.

3. #above:

Test cases were written to check if the below conditions are satisfied:

3.1 "When current menu item has parent_id, the method returns the first parent menu item by querying the parent_id and current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test4, the method should return a value equal to the active record test3.

3.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test5, the method should return a value equal to the active record test1.

4. #below:

Test cases were written to check if the below conditions are satisfied:

4.1 "When current menu item has parent_id,the method returns the first parent menu item by querying the parent_id and current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test3, the method should return a value equal to the active record test4

4.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test1, the method should return a value equal to the active record test5.

5. .repack:

Test cases were written to check if the below conditions are satisfied:

5.1 "When current menu item has repack_id, the method finds all menus items with parent_id equal to repack_id and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value 1,
then, it will repack the sequence ids and returns the list of repacked seq_ids.
5.2 "When current menu item does not have repack_id, the method finds all menus items with parent_id null and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value Null,
it will match all the values with parent_id = Null and returns the list of repacked seq_ids.

6. .next_seq:

Test cases were written to check if the below conditions are satisfied:

6.1 "When parent_id is bigger than 0, the method selects corresponding menu items with inputted parent_id and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value 1, the method should return a value equal to 5.

6.2 "When parent_id is smaller than or equal to 0, the method selects corresponding menu items with parent_id null and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value nil, the method should return a value equal to 6.

7. .items_for_permissions:

Test cases were written to check if the below conditions are satisfied:

7.1 "When inputted variable (permission_ids) is nil and when the controller_action_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.2 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.3 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
the method should return an empty list.
7.4 "When inputted variable (permission_ids) is not nil and when the controller_action_id of current item is bigger than 0 and when perms exists,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records
which satisfy the condition.
7.5 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0, and when perms exists,
the method returns corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records which satisfy the condition.
7.6 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as a parameter,
the method should return an empty list.

== Conclusion and Learning Outcomes ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application.
In our case we did not have to install SimpleCov explicitly since it was already installed earlier.
After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder.
This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers,Models,Helpers in the app directory.
For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from <> to <>.

The learning outcomes after performing this project can be summarized in the following points:

1. We got an hands on experience about how to write tests following the Test Driven Development approach.

2. We learned about how to write units tests for models and controllers in RSpec.

3. We also learned how to understand the functionality of an already developed application.For our case, before writing the test cases for the menu_items.rb we had the understand how different models interacted with each other and how each action by different users would make changes in the database schema.

4. We also gained a better understanding about how different tables, columns of a large applications in structured in the database schema.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/sandeep993/expertiza/tree/menu_item_branch GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-03-27T03:21:15Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

1. Where to start in the process

2. What to test and what not to test

3. How much to test in one go

4. What to call the tests

5. How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;

Make the tests fail;

Then implement the unit;

Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are :

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, clone and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name : This parameter gives the name to the menu item.

2. Label : This parameter gives the label to the menu item.

3. Parent id : It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.

4. Sequence id : It gives the sequence numbering for determining the way the attributes are ordered within a parent.

5. Controller action id : This parameter is associated with the direction in which the user is directed onto.

6. Content page id : This parameter is also associated with the direction in which the user is directed onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are : -

1. find_or_create_by_name(params) : Class Method
This method finds or creates a new entry with the given name obtained in params.

2. delete : Instance Method
This methods deletes the entry and all the child entries (entries having the same parent id) lined to it

3. above : Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below : Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id) : Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id) : Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission : Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "MenuItem.new()" method, giving different values for each of the test inputs to cover the required testing conditions.

before(:each) do
@test1 = MenuItem.new(name: "home1", parent_id: nil, seq: 1, controller_action_id: nil, content_page_id: nil, label: "newlabel")
@test1.save
end

The above is an example entry used for creating objects. 6 such test objects were created with entries giving combinations of parent_id and sequence numbers.

Before each test, all the objects are created, which is done using "before(:each)" key word.
Also several objects of 'ControllerAction' and 'ContentPage' had to be created for testing one of the methods which acted based on those values.

=== Testing Conditions ===
A total of 16 testing conditions were required to be performed for testing all the functions in menu items model file.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:

In this we had write unit test cases to test if the method returned a menu_item corresponding to a name.
Here we expect that if the method find_or_create_by_name() is passed the parameter "home", then it should return a value equal to "home"

2. #delete:

In this test cases were written to check if the method deletes current menu items and all child menu items.
In this case, if the parent menu item is deleted, all its child record should should be deleted.
For our specific case, the parent and its 3 child menu_items are expected to be deleted.

3. #above:

Test cases were written to check if the below conditions are satisfied:

3.1 "When current menu item has parent_id, the method returns the first parent menu item by querying the parent_id and current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test4, the method should return a value equal to the active record test3.

3.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test5, the method should return a value equal to the active record test1.

4. #below:

Test cases were written to check if the below conditions are satisfied:

4.1 "When current menu item has parent_id,the method returns the first parent menu item by querying the parent_id and current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test3, the method should return a value equal to the active record test4

4.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test1, the method should return a value equal to the active record test5.

5. .repack:

Test cases were written to check if the below conditions are satisfied:

5.1 "When current menu item has repack_id, the method finds all menus items with parent_id equal to repack_id and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value 1,
then, it will repack the sequence ids and returns the list of repacked seq_ids.
5.2 "When current menu item does not have repack_id, the method finds all menus items with parent_id null and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value Null,
it will match all the values with parent_id = Null and returns the list of repacked seq_ids.

6. .next_seq:

Test cases were written to check if the below conditions are satisfied:

6.1 "When parent_id is bigger than 0, the method selects corresponding menu items with inputted parent_id and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value 1, the method should return a value equal to 5.

6.2 "When parent_id is smaller than or equal to 0, the method selects corresponding menu items with parent_id null and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value nil, the method should return a value equal to 6.

7. .items_for_permissions:

Test cases were written to check if the below conditions are satisfied:

7.1 "When inputted variable (permission_ids) is nil and when the controller_action_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.2 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.3 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
the method should return an empty list.
7.4 "When inputted variable (permission_ids) is not nil and when the controller_action_id of current item is bigger than 0 and when perms exists,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records
which satisfy the condition.
7.5 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0, and when perms exists,
the method returns corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records which satisfy the condition.
7.6 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as a parameter,
the method should return an empty list.

== Conclusion and Learning Outcomes ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application.
In our case we did not have to install SimpleCov explicitly since it was already installed earlier.
After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder.
This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers,Models,Helpers in the app directory.
For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from <> to <>.

The learning outcomes after performing this project can be summarized in the following points:

1. We got an hands on experience about how to write tests following the Test Driven Development approach.

2. We learned about how to write units tests for models and controllers in RSpec.

3. We also learned how to understand the functionality of an already developed application.For our case, before writing the test cases for the menu_items.rb we had the understand how different models interacted with each other and how each action by different users would make changes in the database schema.

4. We also gained a better understanding about how different tables, columns of a large applications in structured in the database schema.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/sandeep993/expertiza/tree/menu_item_branch GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1813 Menu item tests

2018-03-27T03:16:27Z

Bjain:

This wiki page corresponds to the OSS Project for CSE/ECE 517 (Spring 2018) E1813 Write unit tests for menu_item.rb

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
===Behavior Driven-Development===
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD focuses on:

Where to start in the process
What to test and what not to test
How much to test in one go
What to call the tests
How to understand why a test fails

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

Define a test set for the unit first;
Make the tests fail;
Then implement the unit;
Finally, verify that the implementation of the unit makes the tests succeed.
This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

===Unit Testing===
In computer programming, [https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation.

Some of the advantages of unit testing are:

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.

== Problem Statement ==

This project is to write unit tests using rspec for menu_items.rb model. The unit tests are to be written to make the path coverage of menu_item.rb more than 90% and achieve the highest possible branch coverage.

=== Files Involved ===

The files to be understood and created are:

1. app/models/menu_items.rb

2. spec/models/menu_items_spec.rb

=== Team Members ===
Students who collaborated to work on this problem statement are :

1. Angad Singh Wadhwa (awadhwa3@ncsu.edu)

2. Bhavuk Jain (bjain@ncsu.edu)

== Plan Of Work ==

The task in hand was to write test cases for testing the menu_items model file. No Rspec file for the corresponding model exists so there was a need to create a new file and build tests from scratch.
For this purposes different sub tasks involved

1. Setting up the Expertiza environment

2. Understand the functionality of model file in menu_items.rb

3. Understand the linked data attributes being used, like controller_actions, content_page, permissions_id

4. Creating dummy entries for testing different functionalities.

5. Writing testing conditions for different functions and cross checking with the expected outputs.

== Implementation Steps==

=== Expertiza Environment Setup ===
We used the Ubuntu-Expertiza image to setup the environment.
We forked the master from Expertiza, clone and then run through the command terminal.

cd/expetiza/app/models

The menu_item.rb model file is present in this directory

=== Functionality of Menu Items model ===
Menu Items is a model which gives the functionality to the top menu bar in the Expertiza website. It controls the display of drop down menus and its sub menus. It directs how these drop downs are displayed with regards to different users which have different permission attributes.
A super admin has the permission to edit the menu bar, by adding or deleting menu item blocks from it. Upon adding each item, he gets to position it either in the main menu bar or into different sub categories.

====Parameters ====
Following are the parameters associated with the menu_item model:

1. Name : This parameter gives the name to the menu item.
2. Label : This parameter gives the label to the menu item
3. Parent id : It gives the id of the parent and establishes the hierarchy of the various objects of the menu item model. It can also be 'null' which means that it will be the base category.
4. Sequence id : It gives the sequence numbering for determining the way the attributes are ordered within a parent.
5. Controller action id :
6. Content page id :- These attributes tell, to which direction/ page, this selection directs the user onto.

====Methods====

Different instance methods and class methods exist in this models . Brief description of each of them are : -

1. find_or_create_by_name(params) :- Class Method
This method finds or creates a new entry with the given name obtained in params

2. delete :- Instance Method
This methods deletes the entry and all the child entries ( entries having the same parent id ) lined to it

3. above :- Instance Method
It returns the entry that is above a present sequence number for a given parent id

4. below :- Instance Method
It returns the entry that is below a present sequence number for a given parent id

5. repack(repack_id) :- Class Method
It modifies the sequence numbers, making them in order, removing the skip entries present in it. It is performed after certain sequences have been deleted. repack_id tells the parent id under which these changes are to be made

6. next_seq(parent id) :- Class Method
It returns the next possible sequence id corresponding to a given parent id entries. This function would be helpful if we wish to add a new entry and find out which sequence id is to be given to it.

7. items_for_permission :- Class Method
It returns the set of items that are possible to be displayed for a given permission id and also based on controller action id and page id being present for it.

=== Test Entries Creation ===
Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

Several methods exist for creating such a objects, whose parameters need to be designed to satisfy the conditions under test. Using 'factories' is one such method where few of the attributes are filled in with predefined values when an created. Here, for this specific case, we haven't used, factories method as, the number of attributes were limited in menu_items model and could be filled in completely with the required values each time.

For testing menu_items, we created required entries into the database using "MenuItem.new()" method, giving different values for each of the test inputs to cover the required testing conditions.

before(:each) do
@test1 = MenuItem.new(name: "home1", parent_id: nil, seq: 1, controller_action_id: nil, content_page_id: nil, label: "newlabel")
@test1.save
end

The above is an example entry used for creating objects. 6 such test objects were created with entries giving combinations of parent_id and sequence numbers.

Before each test, all the objects are created, which is done using "before(:each)" key word.
Also several objects of 'ControllerAction' and 'ContentPage' had to be created for testing one of the methods which acted based on those values.

=== Testing Conditions ===
A total of 16 testing conditions were required to be performed for testing all the functions in menu items model file.

The conditions that needed to be tested are as below:

1. .find_or_create_by_name:

In this we had write unit test cases to test if the method returned a menu_item corresponding to a name.
Here we expect that if the method find_or_create_by_name() is passed the parameter "home", then it should return a value equal to "home"

2. #delete:

In this test cases were written to check if the method deletes current menu items and all child menu items.
In this case, if the parent menu item is deleted, all its child record should should be deleted.
For our specific case, the parent and its 3 child menu_items are expected to be deleted.

3. #above:

Test cases were written to check if the below conditions are satisfied:

3.1 "When current menu item has parent_id, the method returns the first parent menu item by querying the parent_id and current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test4, the method should return a value equal to the active record test3.

3.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number minus one".
Here we expect that if we invoke the method above() on the active record test5, the method should return a value equal to the active record test1.

4. #below:

Test cases were written to check if the below conditions are satisfied:

4.1 "When current menu item has parent_id,the method returns the first parent menu item by querying the parent_id and current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test3, the method should return a value equal to the active record test4

4.2 "When current menu item does not have parent_id, the method returns the first parent menu item by querying the current sequence number plus one".
Here we expect that if we invoke the method below() on the active record test1, the method should return a value equal to the active record test5.

5. .repack:

Test cases were written to check if the below conditions are satisfied:

5.1 "When current menu item has repack_id, the method finds all menus items with parent_id equal to repack_id and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value 1,
then, it will repack the sequence ids and returns the list of repacked seq_ids.
5.2 "When current menu item does not have repack_id, the method finds all menus items with parent_id null and repacks the sequence number".
Here we expect that if the method repack() is invoked on the MenuItem and passed the value Null,
it will match all the values with parent_id = Null and returns the list of repacked seq_ids.

6. .next_seq:

Test cases were written to check if the below conditions are satisfied:

6.1 "When parent_id is bigger than 0, the method selects corresponding menu items with inputted parent_id and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value 1, the method should return a value equal to 5.

6.2 "When parent_id is smaller than or equal to 0, the method selects corresponding menu items with parent_id null and returns the next sequence number".
Here we expect that if we invoke the method next_seq() on the MenuItem and pass the value nil, the method should return a value equal to 6.

7. .items_for_permissions:

Test cases were written to check if the below conditions are satisfied:

7.1 "When inputted variable (permission_ids) is nil and when the controller_action_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.2 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0 and when perms does not exist,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
then the method should return a list of active_records which satisfy the condition.
7.3 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems,
the method should return an empty list.
7.4 "When inputted variable (permission_ids) is not nil and when the controller_action_id of current item is bigger than 0 and when perms exists,
the method returns the corresponding items".
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records
which satisfy the condition.
7.5 "When the controller_action_id of current item is smaller than or equal to 0 and the content_page_id of current item is bigger than 0, and when perms exists,
the method returns corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as parameter,
then the method should return a list of active_records which satisfy the condition.
7.6 "When the controller_action_id and content_page_id of current item is smaller than or equal to 0,
the method returns the corresponding items."
Here we expect that if the method items_for_permissions() is invoked on the MenuItems and passed the value 1 as a parameter,
the method should return an empty list.

== Conclusion and Learning Outcomes ==

After writing the test cases we used SimpleCov to measure the C0 coverage of our rails application.
In our case we did not have to install SimpleCov explicitly since it was already installed earlier.
After running rake spec to run the test cases, SimpleCov creates a directory called coverage in our rails application folder.
This folder called coverage contains an index.html file which when opened in a browser renders an html page which gives the C0 coverage of each of the files in the Controllers,Models,Helpers in the app directory.
For our case, the C0 coverage of the menu_items.rb file in the Models folder increased from <> to <>.

The learning outcomes after performing this project can be summarized in the following points:

1. We got an hands on experience about how to write tests following the Test Driven Development approach.

2. We learned about how to write units tests for models and controllers in RSpec.

3. We also learned how to understand the functionality of an already developed application.For our case, before writing the test cases for the menu_items.rb we had the understand how different models interacted with each other and how each action by different users would make changes in the database schema.

4. We also gained a better understanding about how different tables, columns of a large applications in structured in the database schema.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/sandeep993/expertiza/tree/menu_item_branch GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]