Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T01:27:55Z

Vrajadh: /* Models */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

1. The below fields have been modified in the response_maps table:

{| class="wikitable"
|-
! Field
! Data type
|-
| reviewer_id
| int(11)
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

i. '''reviewer_id:''' Based on the reviewer_is_team flag in the assignments table , the assignment team or the participant id is added in this column.

ii. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

2. The below fields have been modified in the assignments table:

{| class="wikitable"
|-
! Field
! Data type
|-
| reviewer_is_team
| boolean
|}

1. '''reviewer_is_team:''' - This field is set based on the discretion of the instructor who decides if the assignment is a to be reviewed individually or as a team.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

* '''assignment.rb:'''

1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.

[[File: assignment_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:

1. Added the below drop down so that the instructor can select the review strategy for the assignment.

[[File: drop_down.jpg]]

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:50:34Z

Vrajadh: /* Database Design */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

1. The below fields have been modified in the response_maps table:

{| class="wikitable"
|-
! Field
! Data type
|-
| reviewer_id
| int(11)
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

i. '''reviewer_id:''' Based on the reviewer_is_team flag in the assignments table , the assignment team or the participant id is added in this column.

ii. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

2. The below fields have been modified in the assignments table:

{| class="wikitable"
|-
! Field
! Data type
|-
| reviewer_is_team
| boolean
|}

1. '''reviewer_is_team:''' - This field is set based on the discretion of the instructor who decides if the assignment is a to be reviewed individually or as a team.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

* '''assignment_team.rb:'''

1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.

[[File: assignment_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:

1. Added the below drop down so that the instructor can select the review strategy for the assignment.

[[File: drop_down.jpg]]

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:50:15Z

Vrajadh: /* Database Design */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

1. The below fields have been modified in the response_maps table:

{| class="wikitable"
|-
! Field
! Data type
|-
| reviewer_id
| int(11)
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

i. '''reviewer_id:''' Based on the reviewer_is_team flag in the assignments table , the assignment team or the participant id is added in this column.

ii. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

2. The below fields have been modified in the assignments table:

{| class="wikitable"
|-
! Field
! Data type
|-
| reviewer_is_team
| boolean
|}

1. reviewer_is_team - This field is set based on the discretion of the instructor who decides if the assignment is a to be reviewed individually or as a team.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

* '''assignment_team.rb:'''

1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.

[[File: assignment_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:

1. Added the below drop down so that the instructor can select the review strategy for the assignment.

[[File: drop_down.jpg]]

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:49:50Z

Vrajadh: /* Database Design */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

1. The below fields have been modified in the response_maps table:

{| class="wikitable"
|-
! Field
! Data type
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

i. '''reviewer_id:''' Based on the reviewer_is_team flag in the assignments table , the assignment team or the participant id is added in this column.

ii. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

2. The below fields have been modified in the assignments table:

{| class="wikitable"
|-
! Field
! Data type
| reviewer_is_team
| boolean
|}

1. reviewer_is_team - This field is set based on the discretion of the instructor who decides if the assignment is a to be reviewed individually or as a team.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

* '''assignment_team.rb:'''

1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.

[[File: assignment_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:

1. Added the below drop down so that the instructor can select the review strategy for the assignment.

[[File: drop_down.jpg]]

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:49:22Z

Vrajadh: /* Database Design */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

1. The below fields have been modified in the response_maps table:

{| class="wikitable"
|-
! Field
! Data type

| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

i. '''reviewer_id:''' Based on the reviewer_is_team flag in the assignments table , the assignment team or the participant id is added in this column.

ii. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

2. The below fields have been modified in the assignments table:

{| class="wikitable"
|-
! Field
! Data type

| reviewer_is_team
| boolean
|}

1. reviewer_is_team - This field is set based on the discretion of the instructor who decides if the assignment is a to be reviewed individually or as a team.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

* '''assignment_team.rb:'''

1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.

[[File: assignment_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:

1. Added the below drop down so that the instructor can select the review strategy for the assignment.

[[File: drop_down.jpg]]

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:Drop down.jpg

2016-04-28T00:39:47Z

Vrajadh:

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:35:28Z

Vrajadh: /* Handling Concurrency */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

* '''assignment_team.rb:'''

1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.

[[File: assignment_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:

1. Added the below drop down so that the instructor can select the review strategy for the assignment.

[[File: drop_down.jpg]]

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:35:18Z

Vrajadh: /* Views */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

* '''assignment_team.rb:'''

1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.

[[File: assignment_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:

1. Added the below drop down so that the instructor can select the review strategy for the assignment.

[[File: drop_down.jpg]]

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:Assignment model.jpg

2016-04-28T00:32:44Z

Vrajadh:

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:32:22Z

Vrajadh: /* Models */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

* '''assignment_team.rb:'''

1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.

[[File: assignment_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:Assignment team model.jpg

2016-04-28T00:28:16Z

Vrajadh:

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:28:03Z

Vrajadh: /* Models */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment_team.rb:'''

A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.

[[File: assignment_team_model.jpg]]

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:Student review controller1.jpg

2016-04-28T00:21:11Z

Vrajadh:

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:20:53Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

* '''student_review_controller:'''

1. Same logic as applied in the review mapping controller to obtain the reviewer.

[[File: student_review_controller1.jpg]]

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:18:40Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:18:26Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:Response controller2.jpg

2016-04-28T00:17:57Z

Vrajadh:

File:Response controller1.jpg

2016-04-28T00:16:43Z

Vrajadh:

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:16:22Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:'''

1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.

[[File: response_controller1.jpg]]

[[File: response_controller2.jpg]]

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:Review mapping controller2.jpg

2016-04-28T00:05:31Z

Vrajadh:

File:Review mapping controller1.jpg

2016-04-28T00:03:12Z

Vrajadh:

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-28T00:01:19Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File: review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-27T23:46:48Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File:review_mapping_controller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: review_mapping_controller2.jpg]]

* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:ReviewMappingcontroller2.png

2016-04-27T23:42:03Z

Vrajadh: uploaded a new version of "File:ReviewMappingcontroller2.png": Reverted to version as of 23:40, 27 April 2016

File:ReviewMappingcontroller2.png

2016-04-27T23:41:48Z

Vrajadh: uploaded a new version of "File:ReviewMappingcontroller2.png"

File:ReviewMappingcontroller2.png

2016-04-27T23:40:58Z

Vrajadh:

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-27T23:40:31Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File:reviewmappingcontroller1.png]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File: reviewmappingcontroller2.png]]

* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:Review mapping controller1.png

2016-04-27T23:36:57Z

Vrajadh: uploaded a new version of "File:Review mapping controller1.png"

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-27T23:36:06Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File:reviewmappingcontroller1.png]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File:reviewmappingcontroller2.png]]

* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

File:Review mapping controller1.png

2016-04-27T23:32:55Z

Vrajadh: uploaded a new version of "File:Review mapping controller1.png"

File:Review mapping controller1.png

2016-04-27T23:31:43Z

Vrajadh:

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-27T23:30:29Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[[File:reviewmappingcontroller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[[File:reviewmappingcontroller2.jpg]]

* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-27T23:30:13Z

Vrajadh: /* Implementation */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====

* '''review_mapping_controller.rb:'''

1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

[File:reviewmappingcontroller1.jpg]]

2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

[File:reviewmappingcontroller2.jpg]]

* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-27T23:29:00Z

Vrajadh: /* Implementation */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

==Implementation==

Below are the key files modified:
====Controllers====
* '''review_mapping_controller.rb:'''
We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table

Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review

* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Models====
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-27T23:11:17Z

Vrajadh: /* Task Description */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

===Implementation===

Below are the key files to be modified:
====Models====
* '''review_response_map.rb:''' Add a field reviewer_is_team , which determines if the reviewer is doing an individual review or on behalf of the team.
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Controllers====
* '''review_mapping_controller.rb:''' Method's like get_reviewer that consist of user_id will consist of calls to generic method which assigns a team_id or user_id based on the assignment being reviewed.
* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.

2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-12T03:17:58Z

Vrajadh: /* Controllers */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. We added a boolean field "reviewer_is_team" to identify if the review is performed by a team or an individual.
# If reviewer_is_team is true, the reviewer_id will be a reference to the Teams table.
# For an Instructor to specify whether the review is a Team/Individual based review, we will be providing a dropdown on the Review Strategy tab of assignment creation.
# Ensure that features such as "view my scores", or the "alternate view/heat map" should continue working.
# Concurrency control: Shouldn't allow multiple teammates to edit the team's review at the same time. The scope of the project doesn't include concurrent editing to allow multiple teammates to edit a review simultaneously.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

===Implementation===

Below are the key files to be modified:
====Models====
* '''review_response_map.rb:''' Add a field reviewer_is_team , which determines if the reviewer is doing an individual review or on behalf of the team.
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Controllers====
* '''review_mapping_controller.rb:''' Method's like get_reviewer that consist of user_id will consist of calls to generic method which assigns a team_id or user_id based on the assignment being reviewed.
* '''response_controller:''' Initial check if it's a team based or an individual review to assign the corresponding id.

====Handling Concurrency====

There can exist a concurrency problem with the team review system. If two members from the team start with the review at the same time, the member who started the review first will lose his/her changes as the second members changes will be overwritten.

To solve this problem, we plan to use a boolean field 'lock' for locking mechanism.
If any member from the team starts with the review, we will set the lock field to true. Once the response is locked, no other member is allowed to edit the response. This lock will be released after the response has been saved.

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

We intend to write unit tests using RSpec for all the methods which we modified/created.

===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.

===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-12T02:07:04Z

Vrajadh: /* Views */

== Purpose ==

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

== Task Description ==
This project comprises of the following steps :

# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. We added a boolean field "reviewer_is_team" to identify if the review is performed by a team or an individual.
# If reviewer_is_team is true, the reviewer_id will be a reference to the Teams table.
# For an Instructor to specify whether the review is a Team/Individual based review, we will be providing a dropdown on the Review Strategy tab of assignment creation.
# Ensure that features such as "view my scores", or the "alternate view/heat map" should continue working.
# Concurrency control: Shouldn't allow multiple teammates to edit the team's review at the same time. The scope of the project doesn't include concurrent editing to allow multiple teammates to edit a review simultaneously.

== Design ==

==== Design Pattern ====
'''Model View Controller'''

In an MVC model, a software application is divided into three major components: Model, View and Controller.

'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.

'''View''' - Displays the data received from the controller in the user interface.

'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.

==== Use Case Diagram ====

'''Name:''' Specify review type on Review Strategy tab.

'''Actor:''' Instructor.

'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.

'''Name:''' Perform Review.

'''Actor:''' Individual Student/Team.

'''Description:''' The individual/team will perform a review for the Assignment.

[[File:OODDUseCase.jpg]]

=== Database Design ===

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

{| class="wikitable"
|-
! Field
! Data type
|-
| id
| int(11)
|-
| reviewed_object_id
| int(11)
|-
| reviewer_id
| int(11)
|-
| reviewee_id
| int(11)
|-
| type
| varchar(255)
|-
| created_at
| datetime
|-
| updated_at
| datetime
|-
| caliberate_to
| boolean
|-
| reviewer_is_team
| boolean
|}

The description of the fields of the database for ResponseMap:

1. '''id:''' The unique record identifier.

2. '''reviewed_object_id:''' The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. '''reviewer_id:''' The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. '''reviewee_id:''' The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. '''type :''' Indicates the type of the ResponseMap.

6. '''created_at:''' The timestamp when the Response was created.

7. '''updated_at:''' The timestamp when the Response was updated.

8. '''calibrate_to:''' A field of boolean data type.

9. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

===Key files to be modified===

====Models====
* '''review_response_map.rb:''' Add a field reviewer_is_team , which determines if the reviewer is doing an individual review or on behalf of the team.
* '''assignment.rb:''' Add a field review_type , that indicates if the assignment is a team based or an individual assignment decided by the instructor.

====Views====
* '''assignments/edit/_review_report.html.erb:''' Add a dropdown for the instructors to select if the reviews are individual or team-based.

====Controllers====
* review_mapping_controller.rb
* participants_controller.rb

== Testing Details ==

=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL).

There were no existing tests for the hyperlinks related methods. We used RSpec to write test cases using TTD approach. The assignment_team_spec.rb in the spec folder will have these tests. All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".

===Factory Girl===
We have used Factory Girl for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.
===Running RSpec===
<code>
$ rspec spec/models/assignment_team_spec.rb
</code>

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-12T01:39:58Z

Vrajadh: /* Views */

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-12T01:39:36Z

Vrajadh: /* Models */

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-12T01:38:22Z

Vrajadh: /* Models */

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-12T01:18:46Z

Vrajadh: /* Task Description */

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-02T22:46:49Z

Vrajadh: /* Problem Statement */

== Purpose ==

*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-02T22:38:50Z

Vrajadh: /* Problem Statement */

== Problem Statement ==

Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams . There are occasions when it's advantageous to review projects as a team . It helps foster discussion and thereby improves the process of learning.

CSC/ECE 517 Spring 2016 E1631 Team-based reviewing

2016-04-02T22:37:02Z

Vrajadh: Created page with "== Problem Statement == Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams . There are ..."

== Problem Statement ==
Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams . There are occasions when it's advantageous to review projects as a team since it results in dis

CSC/ECE 517 Spring 2016

2016-04-02T22:23:28Z

Vrajadh: /* Final Project Design Document */

==Writing Assignment 1==
*[[CSC/ECE 517 Spring 2016/Active Job]]

==Calibration Assignment Submissions==
*[[Calibration Assignment Submission (OmniAuth)]]
*[[Calibration Assignment Submission (Patch_verb)]]

==Writing Assignment 2==
*[[CSC/ECE 517 Spring 2016/Mozilla Implement HTML5 form validation]]

*[[CSC/ECE 517 Spring 2016/Functional Tests for Questionnaire Controller]]

*[[CSC/ECE 517 Spring 2016 / Expertiza Self-Review Feature]]

*[[CSC/ECE 517 Spring 2016/Refactor different question types from quiz feature]]

*[[CSC/ECE 517 Spring 2016/Implement private browsing]]

*[[CSC/ECE 517 Spring 2016/Write automated tests for WebDriver]]

*[[CSC/ECE 517 Spring 2016/Refactor sign_up_sheet_controller.rb and sign_up_topic.rb]]

*[[CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API]]

*[[CSC/ECE 517 Spring 2016/Functional tests for assignment creation function]]

*[[CSC/ECE 517 Spring 2016/E1604. Functional tests for Calibration function]]

*[[CSC/ECE 517 Spring 2016/Refactor and write unit tests for question type.rb]]

*[[CSC/ECE 517 Spring 2016/Refactor response controller]]

*[[CSC/ECE_517_Spring_2016_OSS_M1606]]

*[[CSC/ECE_517_Spring_2016/OSS_E1601]]

==Final Project Design Document==
*[[CSC/ECE 517 Spring 2016 M1601 Implement HTML5 form validation]]
*[[CSC/ECE 517 Spring 2016 E1624 Compose functional tests for Suggest topics of student functionality ]]
*[[CSC/ECE 517 Spring 2016 E1631 Team-based reviewing]]

CSC/ECE 517 Spring 2016/Implement private browsing

2016-04-02T02:46:18Z

Vrajadh: /* Step 2 */

'''Implement Private Browsing'''

Servo<ref>https://github.com/servo/servo</ref> is a prototype web browser engine written in the RUST language. Servo currently does not support the mode where the cookies, login, history and downloads are forgotten after the session ends. The goal of this project is to implement incognito/private browsing feature in Servo.

==Introduction==

Servo is an experimental web browser layout engine being developed by Mozilla Research. Servo is written in the Rust<ref> https://doc.rust-lang.org/ </ref> language, which is also being developed by Mozilla Research. The language is being refined through feedback from Servo development, and writing the Rust compiler itself. Rust is a systems programming language similar to C and C++ in syntax (but semantically very different). The emphasis is on speed, safety, concurrency and control of memory layout.

==Motivation==

When a user browses the web, Firefox remembers lots of information for the user - like the sites visited. There may be times, however, when the users don't want people with access to their computer to see this information, such as when shopping for a present. Private Browsing allows the users to browse the Internet without saving any information about which sites and pages they have visited. Private Browsing also includes Tracking Protection in Private Browsing, which prevents companies from tracking the browsing history across multiple sites.[https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history]

==Installing Servo==

===Prerequisites on Debian based linuxes===
<pre>
sudo apt-get install curl freeglut3-dev autoconf \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
gperf g++ build-essential cmake virtualenv python-pip \
libssl-dev libbz2-dev libosmesa6-dev libxmu6 libxmu-dev \
libglu1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev
</pre>

===Building Servo===
<pre>
git clone https://github.com/servo/servo
cd servo
./mach build --dev
</pre>

===Running Servo===

<pre>
./mach run [url] --devtools <port number>
</pre>

==Implementation==

The below mentioned steps were followed to implement private browsing. The detailed requirements are described in the document available here:[https://github.com/servo/servo/wiki/Private-browsing-student-project].

===Step 1===

As per the requirement, we have added the is_private member to the struct IFrameLoadInfo to check if it's a private iframe or not

[[File: Selection_001.png ]]

We have implemented the function to set this member based on the mozprivatebrowsing attribute.

[[File: MozprivateBrowsing.png]]

===Step 2===

We have created an enum 'ConstellationMsg' that holds an isPrivate message containing pipelineId and sender as attributes.

[[File: Enum_Struct.png]]

The below member has been added to the pipeline struct to check if it's private

[[File: Selection_004.png ]]

===Step 3===

The below function has been implemented to check whether the pipeline is private or not.

[[File:Pipeline_Function.png]]

===Design Pattern===
As per the design document, we have added few fields/members, defined an enum and added a method. The requirements did not require any design pattern to be implemented as such and thus, we have not used any design pattern for the code we have written.

===Testing===
For this particular project, an automated test is to be created to test the functionality which is part of the subsequent steps and is not included in the initial steps, and hence at this point of time the users/reviewers are not supposed perform any manual testing or testing from GUI. More details about writing the automated test for this project can be found [https://github.com/servo/servo/blob/master/tests/wpt/README.md#writing-new-tests here].

==References==
<references/>

File:Pipeline Function.png

2016-04-02T02:43:39Z

Vrajadh:

CSC/ECE 517 Spring 2016/Implement private browsing

2016-04-02T02:41:32Z

Vrajadh: /* Step 2 */

'''Implement Private Browsing'''

Servo<ref>https://github.com/servo/servo</ref> is a prototype web browser engine written in the RUST language. Servo currently does not support the mode where the cookies, login, history and downloads are forgotten after the session ends. The goal of this project is to implement incognito/private browsing feature in Servo.

==Introduction==

Servo is an experimental web browser layout engine being developed by Mozilla Research. Servo is written in the Rust<ref> https://doc.rust-lang.org/ </ref> language, which is also being developed by Mozilla Research. The language is being refined through feedback from Servo development, and writing the Rust compiler itself. Rust is a systems programming language similar to C and C++ in syntax (but semantically very different). The emphasis is on speed, safety, concurrency and control of memory layout.

==Motivation==

When a user browses the web, Firefox remembers lots of information for the user - like the sites visited. There may be times, however, when the users don't want people with access to their computer to see this information, such as when shopping for a present. Private Browsing allows the users to browse the Internet without saving any information about which sites and pages they have visited. Private Browsing also includes Tracking Protection in Private Browsing, which prevents companies from tracking the browsing history across multiple sites.[https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history]

==Installing Servo==

===Prerequisites on Debian based linuxes===
<pre>
sudo apt-get install curl freeglut3-dev autoconf \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
gperf g++ build-essential cmake virtualenv python-pip \
libssl-dev libbz2-dev libosmesa6-dev libxmu6 libxmu-dev \
libglu1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev
</pre>

===Building Servo===
<pre>
git clone https://github.com/servo/servo
cd servo
./mach build --dev
</pre>

===Running Servo===

<pre>
./mach run [url] --devtools <port number>
</pre>

==Implementation==

The below mentioned steps were followed to implement private browsing. The detailed requirements are described in the document available here:[https://github.com/servo/servo/wiki/Private-browsing-student-project].

===Step 1===

As per the requirement, we have added the is_private member to the struct IFrameLoadInfo to check if it's a private iframe or not

[[File: Selection_001.png ]]

We have implemented the function to set this member based on the mozprivatebrowsing attribute.

[[File: MozprivateBrowsing.png]]

===Step 2===

We have created an enum 'ConstellationMsg' that holds an isPrivate message containing pipelineId and sender as attributes.

[[File: Enum_Struct.png]]

The below member has been added to the pipeline struct to check if it's private

[[File: Selection_004.png ]]

===Step 2===

The below function is to check whether the pipeline is private or not.

[[File:Pipeline_Function.png]]

===Design Pattern===
As per the design document, we have added few fields/members, defined an enum and added a method. The requirements did not require any design pattern to be implemented as such and thus, we have not used any design pattern for the code we have written.

===Testing===
For this particular project, an automated test is to be created to test the functionality which is part of the subsequent steps and is not included in the initial steps, and hence at this point of time the users/reviewers are not supposed perform any manual testing or testing from GUI. More details about writing the automated test for this project can be found [https://github.com/servo/servo/blob/master/tests/wpt/README.md#writing-new-tests here].

==References==
<references/>

CSC/ECE 517 Spring 2016/Implement private browsing

2016-04-02T02:41:08Z

Vrajadh: /* Step 2 */

'''Implement Private Browsing'''

Servo<ref>https://github.com/servo/servo</ref> is a prototype web browser engine written in the RUST language. Servo currently does not support the mode where the cookies, login, history and downloads are forgotten after the session ends. The goal of this project is to implement incognito/private browsing feature in Servo.

==Introduction==

Servo is an experimental web browser layout engine being developed by Mozilla Research. Servo is written in the Rust<ref> https://doc.rust-lang.org/ </ref> language, which is also being developed by Mozilla Research. The language is being refined through feedback from Servo development, and writing the Rust compiler itself. Rust is a systems programming language similar to C and C++ in syntax (but semantically very different). The emphasis is on speed, safety, concurrency and control of memory layout.

==Motivation==

When a user browses the web, Firefox remembers lots of information for the user - like the sites visited. There may be times, however, when the users don't want people with access to their computer to see this information, such as when shopping for a present. Private Browsing allows the users to browse the Internet without saving any information about which sites and pages they have visited. Private Browsing also includes Tracking Protection in Private Browsing, which prevents companies from tracking the browsing history across multiple sites.[https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history]

==Installing Servo==

===Prerequisites on Debian based linuxes===
<pre>
sudo apt-get install curl freeglut3-dev autoconf \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
gperf g++ build-essential cmake virtualenv python-pip \
libssl-dev libbz2-dev libosmesa6-dev libxmu6 libxmu-dev \
libglu1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev
</pre>

===Building Servo===
<pre>
git clone https://github.com/servo/servo
cd servo
./mach build --dev
</pre>

===Running Servo===

<pre>
./mach run [url] --devtools <port number>
</pre>

==Implementation==

The below mentioned steps were followed to implement private browsing. The detailed requirements are described in the document available here:[https://github.com/servo/servo/wiki/Private-browsing-student-project].

===Step 1===

As per the requirement, we have added the is_private member to the struct IFrameLoadInfo to check if it's a private iframe or not

[[File: Selection_001.png ]]

We have implemented the function to set this member based on the mozprivatebrowsing attribute.

[[File: MozprivateBrowsing.png]]

===Step 2===

We have created an enum 'ConstellationMsg' that holds an isPrivate message containing pipelineId and sender as attributes.

[[File: Enum_Struct.png]]

The below member has been added to the pipeline struct to check if it's private

[[File: Selection_004.png ]]

===Step 2===

The below function is to check whether the pipeline is private or not.

[[File:Pipeline_Function.jpg]]

===Design Pattern===
As per the design document, we have added few fields/members, defined an enum and added a method. The requirements did not require any design pattern to be implemented as such and thus, we have not used any design pattern for the code we have written.

===Testing===
For this particular project, an automated test is to be created to test the functionality which is part of the subsequent steps and is not included in the initial steps, and hence at this point of time the users/reviewers are not supposed perform any manual testing or testing from GUI. More details about writing the automated test for this project can be found [https://github.com/servo/servo/blob/master/tests/wpt/README.md#writing-new-tests here].

==References==
<references/>

File:Enum Struct.png

2016-04-02T02:40:05Z

Vrajadh: