Expertiza_Wiki - User contributions [en]

User:Mrohatg2

2015-12-18T20:12:50Z

Mrohatg2: /* Implementation */

<h1>E1575 - Share the data in Expertiza to a remote server via PRML format</h1>

== Problem Statement ==
Educational peer-review systems like Expertiza contains a huge volume of data accumulated during the course of its use.
Each peer-review system has a different database design. The relational model is so diverse that, it is often difficult to share the data across different peer-review systems.

In order to migrate a student’s data from one peer-review system to another, one will have to do the following:
#Understand the database design/schema of the source peer-review system
#Understand the database design/schema of the destination peer-review system
#Find the equivalent tables and relations in the destination peer-review system for the source peer-review system
#Retrieve the data from the source peer-review system
#Modify it to match the schema of the destination peer-review system
#Insert the data to the destination peer-review system database.

This is a very tedious job. Moreover, with such a diverse schema it is quite difficult to leverage the power of this large structured data and run any sort of analytics on it.

== Solution ==
One solution to the above mentioned problem is to have a common schema which can capture the essence of all the reviews in a peer-review system to its entirety. Moreover, this schema should not capture any information specific to a particular peer-review system. Once such a schema standard is in place the different peer-review systems can export the data in their database to this new standard and the data can be easily shared across different peer-review systems.
=== PRML ===
Peer Review Markup Language is such a standard schema which can capture information about different reviews to its entirety.

== Scope of the Project ==
The scope of this project is to export the data from the Expertiza database to PRML format.

== Expertiza Design Document ==
[[File:Pg_development.png]]

== Expertiza Database Diagram ==
[[File:PRML.png]]

== Expertiza database schema to PRML database schema map ==
{| class="wikitable"
|-
! Table Name
! Courses
! Course
|-
!Attributes
| id
| CourseId
|-
|
|null
|CourseCIPCode
|-
|
|name
|CourseTitle
|-
|
|info
|CourseDescription
|-
|
|null
|CourseLevelID
|-
|
|created_at
|CourseCreated
|-
|
|null
|CourseStarted
|-
|
|null
|CourseEnded
|-
! Table Name
! Assignments
! Assignment
|-
!Attributes
| id
| AssignmentId
|-
|
|null
|AssignmentCIPCode
|-
|
|name
|AssignmentTitle
|-
|
|spec_location
|AssignmentDescription
|-
|
|course_id
|CourseID
|-

!TABLE NAME
!due_dates, deadline_types
!Task
|-
!ATTRIBUTES
|due_dates.id
|TaskID
|-
|
|due_dates.deadline_type_id
|TaskTypeID
|-
|
|deadline_types.name
|TaskTitle
|-
|
|due_dates.description_url
|TaskDescription
|-
|
|NULL
|TaskOpen
|-
|
|due_dates.due_at
|TaskDue
|-
!TABLE NAME
!questions, questionnaires
!criterion
|-
!ATTRIBUTES
|questions.id
|CriterionID
|-
|
|questions.txt
|CriterionTitle
|-
|
|NULL
|CriterionDescription
|
|-
|
|questions.type
|Type
|-
|
|questionnaires.max_question_score
|MaxLabel
|-
|
|questionnaires.min_question_score
|MinLabel
|-
!TABLE NAME
!question_advices
!Level
|-
!ATTRIBUTES
|id
|LevelID
|-
|
|score
|LevelLabel
|-
|
|advice
|LevelDescription
|-
!TABLE NAME
!questions
!Rubric
|-
!ATTRIBUTES
|
|TaskID
|-
|
|questions.id
|CriterionID
|-
!TABLE NAME
!teams
!Actor
|-
!ATTRIBUTES
|id
|ActorID
|-
|
|type
|
|-
|
|parent_id
|
|-
!TABLE NAME
!participants
!Actor
|-
|
|id
|ActorID
|-
|
|type
|-
|
|parent_id
|-
!
!
!ActorTask
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
!teams_users
!Participant
|-
|
|user_id
|ParticipantID
|-
|
|team_id
|
|-
|
|
|AppID
|-
!TABLE NAME
!participants
!Participant
|-
!ATTRIBUTES
|user_id
|ParticipantID
|-
|
|id
|
|-
|
|
|AppID
|-
!TABLE NAME
|
!ActorParticipant
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|ParticipantID
|-
|
|
|RoleID
|-
!TABLE NAME
|
!Enrollment
|-
!ATTRIBUTES
|
|ParticipantID
|-
|
|
|AppID
|-
|
|
|CourseID
|-
!TABLE NAME
!Teams
!Artifact
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
|name
|ArtifactContent
|-
|
|NULL
|ArtifactCharLength
|-
|
|NULL
|ArtifactOpen
|-
|
|NULL
|ArtifactEnd
|-
!TABLE NAME
|
!Item
|-
!ATTRIBUTES
|
|ItemContent
|-
|
|
|ArtifactId
|-
!TABLE NAME
|
!Review
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CritiqueArtifactID
|-
!TABLE NAME
|
!ReviewCriterionLevel
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CriterionID
|-
|
|
|CritiqueArtifactID
|-
|
|
|EvalMode
|-
|
|
|EvalLevelID
|-
|
|
|ValueOrdinal
|-
|
|
|ValueCardinal
|-
|
|
|Comment
|}

== Implementation ==
We have used an Extract, Transform and Load [https://en.wikipedia.org/wiki/Extract,_transform,_load ETL] tool, [http://community.pentaho.com/projects/data-integration/ Pentaho Kettle] to perform the data migration from Expertiza to PRML database.

[[File:diagram.png]]

The Pentaho Kettle tool extracts data from the expertise schema, performs transformation on it and load the data in the PRML format.
The tables are mapped as shown in the schema map above.
The operations performed by the ETL tool:

'''Extraction'''
The data is extracted from the expertise database and brought into the staging area by this operation of the ETL tool. It is the staging area in which all the transformation are done.

'''Transformation'''
Many operations are performed on the data in the staging area so that the expertise schema can be converted to the PRML schema. This is called transformation of the data. An example of transformation is while mapping of participants table in the expertiza database to actors table in the PRML database. Each value of the id field is incremented by 1000 while inserting in the participants table.

'''Loading:'''
The transformed data when moved from the staging area to the PRML database is called as loading. There are three types of loading implemented on the tables depending on the size of the table – initial load,partial loading and full loading.
Partial Loading: Only the new or updated entries in the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for table with very large number of entries. Eg: Reviews

Partial loading is implemented with the help of timestamps and checksums.

Timestamp: One way to perform partial loading is to have a 'modified' time stamp in the source table. The destination table should mirror this 'modified' time stamp. Then while loading the destination table we extract only those records from the source table which has a 'modified' time stamp value greater than the latest 'modified' time stamp value in the destination table. The advantage is that we need not fetch all records from the source table. Only those records which needs to be updated in the destination table will be retrieved. (refer load_prml_ModifiedTimeStampTable transformation)

Checksum: Another way to perform partial loading is using checksum. A checksum is computed for each record, on selected field values, of the source table and added to the destination table while initial loading. Loading which follow would again compute the checksum for source table records and if there is no matching checksum in the destination table an update or an insert would be performed. (refer load_prml_checksumtable transformation)

Full Loading: All the entries from the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for tables with less number of entries.
Eg: Courses

'''Expertiza tables which have been implemented'''

Assignments Table - Full Load

Course Table - Full Load

ModifiedTimeStamp Table - Partial Load

Task Table

Criteria Table

Due_Dates Table

Questionnaire Table

Teams Table

Jobs are being performed in a sequential order in the current project. If the tables do not depend on one another they can be performed in a parallel way to reduce time.
Initially the entries in the table are buffered so that only around 8000 rows are processed at a time.

== Testing ==
We have tested our conversion by using a set of sample expertiza data. We run the extract, transform and load methodology on it. Queries are run on the PRML database to check if it gives the same results as the expertiza database.
Though the testing is not through, this is the only way the project can be tested.

==Running the Project==
'''Required Software:'''
*Pentaho’s Data Integration (Kettle).
*MySQL
*JAVA

'''Setup:'''
*Download and Install MySQL and JAVA
*Import to MySQL expertiza database dump file.
*Import to MySQL PRML database dump file.
*Download Pentaho's Data Integration(Kettle) Community Edition (its a copy deployment hence no installation is required).
*Download MySql Connector jar file and copy to <pentaho_root_directory\data-integration\lib>
*Start Spoon.bat if you are using a windows machine or Spoon.sh if you using Linux (pentaho_root_directory\data-integration)
*Download the transformations and jobs attached
*You can open a kettle transformation (.ktr file) using Spoon and run it (Make sure proper MySql DB connections are configured)
*You may also open the kettle job (.kjb file) using spoon and run it (Make sure the path for transformations in the job are correct)

User:Mrohatg2

2015-12-18T20:11:15Z

Mrohatg2: /* Implementation */

<h1>E1575 - Share the data in Expertiza to a remote server via PRML format</h1>

== Problem Statement ==
Educational peer-review systems like Expertiza contains a huge volume of data accumulated during the course of its use.
Each peer-review system has a different database design. The relational model is so diverse that, it is often difficult to share the data across different peer-review systems.

In order to migrate a student’s data from one peer-review system to another, one will have to do the following:
#Understand the database design/schema of the source peer-review system
#Understand the database design/schema of the destination peer-review system
#Find the equivalent tables and relations in the destination peer-review system for the source peer-review system
#Retrieve the data from the source peer-review system
#Modify it to match the schema of the destination peer-review system
#Insert the data to the destination peer-review system database.

This is a very tedious job. Moreover, with such a diverse schema it is quite difficult to leverage the power of this large structured data and run any sort of analytics on it.

== Solution ==
One solution to the above mentioned problem is to have a common schema which can capture the essence of all the reviews in a peer-review system to its entirety. Moreover, this schema should not capture any information specific to a particular peer-review system. Once such a schema standard is in place the different peer-review systems can export the data in their database to this new standard and the data can be easily shared across different peer-review systems.
=== PRML ===
Peer Review Markup Language is such a standard schema which can capture information about different reviews to its entirety.

== Scope of the Project ==
The scope of this project is to export the data from the Expertiza database to PRML format.

== Expertiza Design Document ==
[[File:Pg_development.png]]

== Expertiza Database Diagram ==
[[File:PRML.png]]

== Expertiza database schema to PRML database schema map ==
{| class="wikitable"
|-
! Table Name
! Courses
! Course
|-
!Attributes
| id
| CourseId
|-
|
|null
|CourseCIPCode
|-
|
|name
|CourseTitle
|-
|
|info
|CourseDescription
|-
|
|null
|CourseLevelID
|-
|
|created_at
|CourseCreated
|-
|
|null
|CourseStarted
|-
|
|null
|CourseEnded
|-
! Table Name
! Assignments
! Assignment
|-
!Attributes
| id
| AssignmentId
|-
|
|null
|AssignmentCIPCode
|-
|
|name
|AssignmentTitle
|-
|
|spec_location
|AssignmentDescription
|-
|
|course_id
|CourseID
|-

!TABLE NAME
!due_dates, deadline_types
!Task
|-
!ATTRIBUTES
|due_dates.id
|TaskID
|-
|
|due_dates.deadline_type_id
|TaskTypeID
|-
|
|deadline_types.name
|TaskTitle
|-
|
|due_dates.description_url
|TaskDescription
|-
|
|NULL
|TaskOpen
|-
|
|due_dates.due_at
|TaskDue
|-
!TABLE NAME
!questions, questionnaires
!criterion
|-
!ATTRIBUTES
|questions.id
|CriterionID
|-
|
|questions.txt
|CriterionTitle
|-
|
|NULL
|CriterionDescription
|
|-
|
|questions.type
|Type
|-
|
|questionnaires.max_question_score
|MaxLabel
|-
|
|questionnaires.min_question_score
|MinLabel
|-
!TABLE NAME
!question_advices
!Level
|-
!ATTRIBUTES
|id
|LevelID
|-
|
|score
|LevelLabel
|-
|
|advice
|LevelDescription
|-
!TABLE NAME
!questions
!Rubric
|-
!ATTRIBUTES
|
|TaskID
|-
|
|questions.id
|CriterionID
|-
!TABLE NAME
!teams
!Actor
|-
!ATTRIBUTES
|id
|ActorID
|-
|
|type
|
|-
|
|parent_id
|
|-
!TABLE NAME
!participants
!Actor
|-
|
|id
|ActorID
|-
|
|type
|-
|
|parent_id
|-
!
!
!ActorTask
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
!teams_users
!Participant
|-
|
|user_id
|ParticipantID
|-
|
|team_id
|
|-
|
|
|AppID
|-
!TABLE NAME
!participants
!Participant
|-
!ATTRIBUTES
|user_id
|ParticipantID
|-
|
|id
|
|-
|
|
|AppID
|-
!TABLE NAME
|
!ActorParticipant
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|ParticipantID
|-
|
|
|RoleID
|-
!TABLE NAME
|
!Enrollment
|-
!ATTRIBUTES
|
|ParticipantID
|-
|
|
|AppID
|-
|
|
|CourseID
|-
!TABLE NAME
!Teams
!Artifact
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
|name
|ArtifactContent
|-
|
|NULL
|ArtifactCharLength
|-
|
|NULL
|ArtifactOpen
|-
|
|NULL
|ArtifactEnd
|-
!TABLE NAME
|
!Item
|-
!ATTRIBUTES
|
|ItemContent
|-
|
|
|ArtifactId
|-
!TABLE NAME
|
!Review
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CritiqueArtifactID
|-
!TABLE NAME
|
!ReviewCriterionLevel
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CriterionID
|-
|
|
|CritiqueArtifactID
|-
|
|
|EvalMode
|-
|
|
|EvalLevelID
|-
|
|
|ValueOrdinal
|-
|
|
|ValueCardinal
|-
|
|
|Comment
|}

== Implementation ==
We have used an Extract, Transform and Load [https://en.wikipedia.org/wiki/Extract,_transform,_load ETL] tool, [http://community.pentaho.com/projects/data-integration/ Pentaho Kettle] to perform the data migration from Expertiza to PRML database.

[[File:diagram.png]]

The Pentaho Kettle tool extracts data from the expertise schema, performs transformation on it and load the data in the PRML format.
The tables are mapped as shown in the schema map above.
The operations performed by the ETL tool:

'''Extraction'''
The data is extracted from the expertise database and brought into the staging area by this operation of the ETL tool. It is the staging area in which all the transformation are done.

'''Transformation'''
Many operations are performed on the data in the staging area so that the expertise schema can be converted to the PRML schema. This is called transformation of the data. An example of transformation is while mapping of participants table in the expertiza database to actors table in the PRML database. Each value of the id field is incremented by 1000 while inserting in the participants table.

'''Loading:'''
The transformed data when moved from the staging area to the PRML database is called as loading. There are three types of loading implemented on the tables depending on the size of the table – initial load,partial loading and full loading.
Partial Loading: Only the new or updated entries in the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for table with very large number of entries. Eg: Reviews

Partial loading is implemented with the help of timestamps and checksums.

Timestamp: One way to perform partial loading is to have a 'modified' time stamp in the source table. The destination table should mirror this 'modified' time stamp. Then while loading the destination table we extract only those records from the source table which has a 'modified' time stamp value greater than the latest 'modified' time stamp value in the destination table. The advantage is that we need not fetch all records from the source table. Only those records which needs to be updated in the destination table will be retrieved. (refer load_prml_ModifiedTimeStampTable transformation)

Checksum: Another way to perform partial loading is using checksum. A checksum is computed for each record, on selected field values, of the source table and added to the destination table while initial loading. Loading which follow would again compute the checksum for source table records and if there is no matching checksum in the destination table an update or an insert would be performed. (refer load_prml_checksumtable transformation)

Full Loading: All the entries from the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for tables with less number of entries.
Eg: Courses

'''Expertiza tables which have been implemented'''

Assignments Table - Full Load

Course Table - Full Load

ModifiedTimeStamp Table - Partial Load

Task Table

Criteria Table

Due_Dates Table

Questionare Table

Teams Table

Jobs are being performed in a sequential order in the current project. If the tables do not depend on one another they can be performed in a parallel way to reduce time.
Initially the entries in the table are buffered so that only around 8000 rows are processed at a time.

== Testing ==
We have tested our conversion by using a set of sample expertiza data. We run the extract, transform and load methodology on it. Queries are run on the PRML database to check if it gives the same results as the expertiza database.
Though the testing is not through, this is the only way the project can be tested.

==Running the Project==
'''Required Software:'''
*Pentaho’s Data Integration (Kettle).
*MySQL
*JAVA

'''Setup:'''
*Download and Install MySQL and JAVA
*Import to MySQL expertiza database dump file.
*Import to MySQL PRML database dump file.
*Download Pentaho's Data Integration(Kettle) Community Edition (its a copy deployment hence no installation is required).
*Download MySql Connector jar file and copy to <pentaho_root_directory\data-integration\lib>
*Start Spoon.bat if you are using a windows machine or Spoon.sh if you using Linux (pentaho_root_directory\data-integration)
*Download the transformations and jobs attached
*You can open a kettle transformation (.ktr file) using Spoon and run it (Make sure proper MySql DB connections are configured)
*You may also open the kettle job (.kjb file) using spoon and run it (Make sure the path for transformations in the job are correct)

User:Mrohatg2

2015-12-16T18:31:53Z

Mrohatg2: /* Implementation */

<h1>E1575 - Share the data in Expertiza to a remote server via PRML format</h1>

== Problem Statement ==
Educational peer-review systems like Expertiza contains a huge volume of data accumulated during the course of its use.
Each peer-review system has a different database design. The relational model is so diverse that, it is often difficult to share the data across different peer-review systems.

In order to migrate a student’s data from one peer-review system to another, one will have to do the following:
#Understand the database design/schema of the source peer-review system
#Understand the database design/schema of the destination peer-review system
#Find the equivalent tables and relations in the destination peer-review system for the source peer-review system
#Retrieve the data from the source peer-review system
#Modify it to match the schema of the destination peer-review system
#Insert the data to the destination peer-review system database.

This is a very tedious job. Moreover, with such a diverse schema it is quite difficult to leverage the power of this large structured data and run any sort of analytics on it.

== Solution ==
One solution to the above mentioned problem is to have a common schema which can capture the essence of all the reviews in a peer-review system to its entirety. Moreover, this schema should not capture any information specific to a particular peer-review system. Once such a schema standard is in place the different peer-review systems can export the data in their database to this new standard and the data can be easily shared across different peer-review systems.
=== PRML ===
Peer Review Markup Language is such a standard schema which can capture information about different reviews to its entirety.

== Scope of the Project ==
The scope of this project is to export the data from the Expertiza database to PRML format.

== Expertiza Design Document ==
[[File:Pg_development.png]]

== Expertiza Database Diagram ==
[[File:PRML.png]]

== Expertiza database schema to PRML database schema map ==
{| class="wikitable"
|-
! Table Name
! Courses
! Course
|-
!Attributes
| id
| CourseId
|-
|
|null
|CourseCIPCode
|-
|
|name
|CourseTitle
|-
|
|info
|CourseDescription
|-
|
|null
|CourseLevelID
|-
|
|created_at
|CourseCreated
|-
|
|null
|CourseStarted
|-
|
|null
|CourseEnded
|-
! Table Name
! Assignments
! Assignment
|-
!Attributes
| id
| AssignmentId
|-
|
|null
|AssignmentCIPCode
|-
|
|name
|AssignmentTitle
|-
|
|spec_location
|AssignmentDescription
|-
|
|course_id
|CourseID
|-

!TABLE NAME
!due_dates, deadline_types
!Task
|-
!ATTRIBUTES
|due_dates.id
|TaskID
|-
|
|due_dates.deadline_type_id
|TaskTypeID
|-
|
|deadline_types.name
|TaskTitle
|-
|
|due_dates.description_url
|TaskDescription
|-
|
|NULL
|TaskOpen
|-
|
|due_dates.due_at
|TaskDue
|-
!TABLE NAME
!questions, questionnaires
!criterion
|-
!ATTRIBUTES
|questions.id
|CriterionID
|-
|
|questions.txt
|CriterionTitle
|-
|
|NULL
|CriterionDescription
|
|-
|
|questions.type
|Type
|-
|
|questionnaires.max_question_score
|MaxLabel
|-
|
|questionnaires.min_question_score
|MinLabel
|-
!TABLE NAME
!question_advices
!Level
|-
!ATTRIBUTES
|id
|LevelID
|-
|
|score
|LevelLabel
|-
|
|advice
|LevelDescription
|-
!TABLE NAME
!questions
!Rubric
|-
!ATTRIBUTES
|
|TaskID
|-
|
|questions.id
|CriterionID
|-
!TABLE NAME
!teams
!Actor
|-
!ATTRIBUTES
|id
|ActorID
|-
|
|type
|
|-
|
|parent_id
|
|-
!TABLE NAME
!participants
!Actor
|-
|
|id
|ActorID
|-
|
|type
|-
|
|parent_id
|-
!
!
!ActorTask
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
!teams_users
!Participant
|-
|
|user_id
|ParticipantID
|-
|
|team_id
|
|-
|
|
|AppID
|-
!TABLE NAME
!participants
!Participant
|-
!ATTRIBUTES
|user_id
|ParticipantID
|-
|
|id
|
|-
|
|
|AppID
|-
!TABLE NAME
|
!ActorParticipant
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|ParticipantID
|-
|
|
|RoleID
|-
!TABLE NAME
|
!Enrollment
|-
!ATTRIBUTES
|
|ParticipantID
|-
|
|
|AppID
|-
|
|
|CourseID
|-
!TABLE NAME
!Teams
!Artifact
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
|name
|ArtifactContent
|-
|
|NULL
|ArtifactCharLength
|-
|
|NULL
|ArtifactOpen
|-
|
|NULL
|ArtifactEnd
|-
!TABLE NAME
|
!Item
|-
!ATTRIBUTES
|
|ItemContent
|-
|
|
|ArtifactId
|-
!TABLE NAME
|
!Review
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CritiqueArtifactID
|-
!TABLE NAME
|
!ReviewCriterionLevel
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CriterionID
|-
|
|
|CritiqueArtifactID
|-
|
|
|EvalMode
|-
|
|
|EvalLevelID
|-
|
|
|ValueOrdinal
|-
|
|
|ValueCardinal
|-
|
|
|Comment
|}

== Implementation ==
We have used an Extract, Transform and Load [https://en.wikipedia.org/wiki/Extract,_transform,_load ETL] tool, [http://community.pentaho.com/projects/data-integration/ Pentaho Kettle] to perform the data migration from Expertiza to PRML database.

[[File:diagram.png]]

The Pentaho Kettle tool extracts data from the expertise schema, performs transformation on it and load the data in the PRML format.
The tables are mapped as shown in the schema map above.
The operations performed by the ETL tool:

'''Extraction'''
The data is extracted from the expertise database and brought into the staging area by this operation of the ETL tool. It is the staging area in which all the transformation are done.

'''Transformation'''
Many operations are performed on the data in the staging area so that the expertise schema can be converted to the PRML schema. This is called transformation of the data. An example of transformation is while mapping of participants table in the expertiza database to actors table in the PRML database. Each value of the id field is incremented by 1000 while inserting in the participants table.

'''Loading:'''
The transformed data when moved from the staging area to the PRML database is called as loading. There are three types of loading implemented on the tables depending on the size of the table – initial load,partial loading and full loading.
Partial Loading: Only the new or updated entries in the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for table with very large number of entries. Eg: Reviews

Partial loading is implemented with the help of timestamps and checksums.

Timestamp: The expertiza database has a timestamp column which saves the timestamp that row was last modified at. There is a variable 'maxtimestamp' that saves the value of the time the rows from the experts database were last loaded in the PRML database. While doing the partial load, the query checks this variable and loads only the rows whose timestamp is greater than the 'maxtimestamp'. This way only the updated or the new entries are loaded in the PRML table.

Checksums: The checksum is also a way of implementing partial load, like the timestamp. In this case the checksum of the expertiza database is compared with the PRML database checksum. Only the rows whose checksum does not match, or does not exist is loaded.

Full Loading: All the entries from the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for tables will less number of entries.
Eg: Courses

'''Expertiza tables which have been implemented'''

Assignments Table - Full Load

Course Table - Full Load

ModifiedTimeStamp Table - Partial Load

Task Table

Criteria Table

Due_Dates Table

Questionare Table

Teams Table

Jobs are being performed in a sequential order in the current project. If the tables do not depend on one another they can be performed in a parallel way to reduce time.
Initially the entries in the table are buffered so that only around 8000 rows are processed at a time.

== Testing ==
We have tested our conversion by using a set of sample expertiza data. We run the extract, transform and load methodology on it. Queries are run on the PRML database to check if it gives the same results as the expertiza database.
Though the testing is not through, this is the only way the project can be tested.

==Running the Project==
'''Required Software:'''
*Pentaho’s Data Integration (Kettle).
*MySQL
*JAVA

'''Setup:'''
*Download and Install MySQL and JAVA
*Import to MySQL expertiza database dump file.
*Import to MySQL PRML database dump file.
*Download Pentaho's Data Integration(Kettle) Community Edition (its a copy deployment hence no installation is required).
*Download MySql Connector jar file and copy to <pentaho_root_directory\data-integration\lib>
*Start Spoon.bat if you are using a windows machine or Spoon.sh if you using Linux (pentaho_root_directory\data-integration)
*Download the transformations and jobs attached
*You can open a kettle transformation (.ktr file) using Spoon and run it (Make sure proper MySql DB connections are configured)
*You may also open the kettle job (.kjb file) using spoon and run it (Make sure the path for transformations in the job are correct)

User:Mrohatg2

2015-12-16T18:22:21Z

Mrohatg2: /* Implementation */

<h1>E1575 - Share the data in Expertiza to a remote server via PRML format</h1>

== Problem Statement ==
Educational peer-review systems like Expertiza contains a huge volume of data accumulated during the course of its use.
Each peer-review system has a different database design. The relational model is so diverse that, it is often difficult to share the data across different peer-review systems.

In order to migrate a student’s data from one peer-review system to another, one will have to do the following:
#Understand the database design/schema of the source peer-review system
#Understand the database design/schema of the destination peer-review system
#Find the equivalent tables and relations in the destination peer-review system for the source peer-review system
#Retrieve the data from the source peer-review system
#Modify it to match the schema of the destination peer-review system
#Insert the data to the destination peer-review system database.

This is a very tedious job. Moreover, with such a diverse schema it is quite difficult to leverage the power of this large structured data and run any sort of analytics on it.

== Solution ==
One solution to the above mentioned problem is to have a common schema which can capture the essence of all the reviews in a peer-review system to its entirety. Moreover, this schema should not capture any information specific to a particular peer-review system. Once such a schema standard is in place the different peer-review systems can export the data in their database to this new standard and the data can be easily shared across different peer-review systems.
=== PRML ===
Peer Review Markup Language is such a standard schema which can capture information about different reviews to its entirety.

== Scope of the Project ==
The scope of this project is to export the data from the Expertiza database to PRML format.

== Expertiza Design Document ==
[[File:Pg_development.png]]

== Expertiza Database Diagram ==
[[File:PRML.png]]

== Expertiza database schema to PRML database schema map ==
{| class="wikitable"
|-
! Table Name
! Courses
! Course
|-
!Attributes
| id
| CourseId
|-
|
|null
|CourseCIPCode
|-
|
|name
|CourseTitle
|-
|
|info
|CourseDescription
|-
|
|null
|CourseLevelID
|-
|
|created_at
|CourseCreated
|-
|
|null
|CourseStarted
|-
|
|null
|CourseEnded
|-
! Table Name
! Assignments
! Assignment
|-
!Attributes
| id
| AssignmentId
|-
|
|null
|AssignmentCIPCode
|-
|
|name
|AssignmentTitle
|-
|
|spec_location
|AssignmentDescription
|-
|
|course_id
|CourseID
|-

!TABLE NAME
!due_dates, deadline_types
!Task
|-
!ATTRIBUTES
|due_dates.id
|TaskID
|-
|
|due_dates.deadline_type_id
|TaskTypeID
|-
|
|deadline_types.name
|TaskTitle
|-
|
|due_dates.description_url
|TaskDescription
|-
|
|NULL
|TaskOpen
|-
|
|due_dates.due_at
|TaskDue
|-
!TABLE NAME
!questions, questionnaires
!criterion
|-
!ATTRIBUTES
|questions.id
|CriterionID
|-
|
|questions.txt
|CriterionTitle
|-
|
|NULL
|CriterionDescription
|
|-
|
|questions.type
|Type
|-
|
|questionnaires.max_question_score
|MaxLabel
|-
|
|questionnaires.min_question_score
|MinLabel
|-
!TABLE NAME
!question_advices
!Level
|-
!ATTRIBUTES
|id
|LevelID
|-
|
|score
|LevelLabel
|-
|
|advice
|LevelDescription
|-
!TABLE NAME
!questions
!Rubric
|-
!ATTRIBUTES
|
|TaskID
|-
|
|questions.id
|CriterionID
|-
!TABLE NAME
!teams
!Actor
|-
!ATTRIBUTES
|id
|ActorID
|-
|
|type
|
|-
|
|parent_id
|
|-
!TABLE NAME
!participants
!Actor
|-
|
|id
|ActorID
|-
|
|type
|-
|
|parent_id
|-
!
!
!ActorTask
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
!teams_users
!Participant
|-
|
|user_id
|ParticipantID
|-
|
|team_id
|
|-
|
|
|AppID
|-
!TABLE NAME
!participants
!Participant
|-
!ATTRIBUTES
|user_id
|ParticipantID
|-
|
|id
|
|-
|
|
|AppID
|-
!TABLE NAME
|
!ActorParticipant
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|ParticipantID
|-
|
|
|RoleID
|-
!TABLE NAME
|
!Enrollment
|-
!ATTRIBUTES
|
|ParticipantID
|-
|
|
|AppID
|-
|
|
|CourseID
|-
!TABLE NAME
!Teams
!Artifact
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
|name
|ArtifactContent
|-
|
|NULL
|ArtifactCharLength
|-
|
|NULL
|ArtifactOpen
|-
|
|NULL
|ArtifactEnd
|-
!TABLE NAME
|
!Item
|-
!ATTRIBUTES
|
|ItemContent
|-
|
|
|ArtifactId
|-
!TABLE NAME
|
!Review
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CritiqueArtifactID
|-
!TABLE NAME
|
!ReviewCriterionLevel
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CriterionID
|-
|
|
|CritiqueArtifactID
|-
|
|
|EvalMode
|-
|
|
|EvalLevelID
|-
|
|
|ValueOrdinal
|-
|
|
|ValueCardinal
|-
|
|
|Comment
|}

== Implementation ==
We have used an Extract, Transform and Load [https://en.wikipedia.org/wiki/Extract,_transform,_load ETL] tool, [http://community.pentaho.com/projects/data-integration/ Pentaho Kettle] to perform the data migration from Expertiza to PRML database.

[[File:diagram.png]]

The Pentaho Kettle tool extracts data from the expertise schema, performs transformation on it and load the data in the PRML format.
The tables are mapped as shown in the schema map above.
The operations performed by the ETL tool:

'''Extraction'''
The data is extracted from the expertise database and brought into the staging area by this operation of the ETL tool. It is the staging area in which all the transformation are done.

'''Transformation'''
Many operations are performed on the data in the staging area so that the expertise schema can be converted to the PRML schema. This is called transformation of the data. An example of transformation is while mapping of participants table in the expertiza database to actors table in the PRML database. Each value of the id field is incremented by 1000 while inserting in the participants table.

'''Loading:'''
The transformed data when moved from the staging area to the PRML database is called as loading. There are three types of loading implemented on the tables depending on the size of the table – initial load,partial loading and full loading.
Partial Loading: Only the new or updated entries in the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for table with very large number of entries. Eg: Reviews

Partial loading is implemented with the help of timestamps and checksums.

Timestamp: The expertiza database has a timestamp column which saves the timestamp that row was last modified at. There is a variable 'maxtimestamp' that saves the value of the time the rows from the experts database were last loaded in the PRML database. While doing the partial load, the query checks this variable and loads only the rows whose timestamp is greater than the 'maxtimestamp'. This way only the updated or the new entries are loaded in the PRML table.

Checksums: The checksum is also a way of implementing partial load, like the timestamp. In this case the checksum of the expertiza database is compared with the PRML database checksum. Only the rows whose checksum does not match, or does not exist is loaded.

Full Loading: All the entries from the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for tables will less number of entries.
Eg: Courses

'''Expertiza tables which have been implemented'''

Assignments Table - Full Load

Course Table - Full Load

ModifiedTimeStamp Table - Partial Load

Jobs are being performed in a sequential order in the current project. If the tables do not depend on one another they can be performed in a parallel way to reduce time.
Initially the entries in the table are buffered so that only around 8000 rows are processed at a time.

== Testing ==
We have tested our conversion by using a set of sample expertiza data. We run the extract, transform and load methodology on it. Queries are run on the PRML database to check if it gives the same results as the expertiza database.
Though the testing is not through, this is the only way the project can be tested.

==Running the Project==
'''Required Software:'''
*Pentaho’s Data Integration (Kettle).
*MySQL
*JAVA

'''Setup:'''
*Download and Install MySQL and JAVA
*Import to MySQL expertiza database dump file.
*Import to MySQL PRML database dump file.
*Download Pentaho's Data Integration(Kettle) Community Edition (its a copy deployment hence no installation is required).
*Download MySql Connector jar file and copy to <pentaho_root_directory\data-integration\lib>
*Start Spoon.bat if you are using a windows machine or Spoon.sh if you using Linux (pentaho_root_directory\data-integration)
*Download the transformations and jobs attached
*You can open a kettle transformation (.ktr file) using Spoon and run it (Make sure proper MySql DB connections are configured)
*You may also open the kettle job (.kjb file) using spoon and run it (Make sure the path for transformations in the job are correct)

User:Mrohatg2

2015-12-16T18:20:07Z

Mrohatg2: /* Implementation */

<h1>E1575 - Share the data in Expertiza to a remote server via PRML format</h1>

== Problem Statement ==
Educational peer-review systems like Expertiza contains a huge volume of data accumulated during the course of its use.
Each peer-review system has a different database design. The relational model is so diverse that, it is often difficult to share the data across different peer-review systems.

In order to migrate a student’s data from one peer-review system to another, one will have to do the following:
#Understand the database design/schema of the source peer-review system
#Understand the database design/schema of the destination peer-review system
#Find the equivalent tables and relations in the destination peer-review system for the source peer-review system
#Retrieve the data from the source peer-review system
#Modify it to match the schema of the destination peer-review system
#Insert the data to the destination peer-review system database.

This is a very tedious job. Moreover, with such a diverse schema it is quite difficult to leverage the power of this large structured data and run any sort of analytics on it.

== Solution ==
One solution to the above mentioned problem is to have a common schema which can capture the essence of all the reviews in a peer-review system to its entirety. Moreover, this schema should not capture any information specific to a particular peer-review system. Once such a schema standard is in place the different peer-review systems can export the data in their database to this new standard and the data can be easily shared across different peer-review systems.
=== PRML ===
Peer Review Markup Language is such a standard schema which can capture information about different reviews to its entirety.

== Scope of the Project ==
The scope of this project is to export the data from the Expertiza database to PRML format.

== Expertiza Design Document ==
[[File:Pg_development.png]]

== Expertiza Database Diagram ==
[[File:PRML.png]]

== Expertiza database schema to PRML database schema map ==
{| class="wikitable"
|-
! Table Name
! Courses
! Course
|-
!Attributes
| id
| CourseId
|-
|
|null
|CourseCIPCode
|-
|
|name
|CourseTitle
|-
|
|info
|CourseDescription
|-
|
|null
|CourseLevelID
|-
|
|created_at
|CourseCreated
|-
|
|null
|CourseStarted
|-
|
|null
|CourseEnded
|-
! Table Name
! Assignments
! Assignment
|-
!Attributes
| id
| AssignmentId
|-
|
|null
|AssignmentCIPCode
|-
|
|name
|AssignmentTitle
|-
|
|spec_location
|AssignmentDescription
|-
|
|course_id
|CourseID
|-

!TABLE NAME
!due_dates, deadline_types
!Task
|-
!ATTRIBUTES
|due_dates.id
|TaskID
|-
|
|due_dates.deadline_type_id
|TaskTypeID
|-
|
|deadline_types.name
|TaskTitle
|-
|
|due_dates.description_url
|TaskDescription
|-
|
|NULL
|TaskOpen
|-
|
|due_dates.due_at
|TaskDue
|-
!TABLE NAME
!questions, questionnaires
!criterion
|-
!ATTRIBUTES
|questions.id
|CriterionID
|-
|
|questions.txt
|CriterionTitle
|-
|
|NULL
|CriterionDescription
|
|-
|
|questions.type
|Type
|-
|
|questionnaires.max_question_score
|MaxLabel
|-
|
|questionnaires.min_question_score
|MinLabel
|-
!TABLE NAME
!question_advices
!Level
|-
!ATTRIBUTES
|id
|LevelID
|-
|
|score
|LevelLabel
|-
|
|advice
|LevelDescription
|-
!TABLE NAME
!questions
!Rubric
|-
!ATTRIBUTES
|
|TaskID
|-
|
|questions.id
|CriterionID
|-
!TABLE NAME
!teams
!Actor
|-
!ATTRIBUTES
|id
|ActorID
|-
|
|type
|
|-
|
|parent_id
|
|-
!TABLE NAME
!participants
!Actor
|-
|
|id
|ActorID
|-
|
|type
|-
|
|parent_id
|-
!
!
!ActorTask
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
!teams_users
!Participant
|-
|
|user_id
|ParticipantID
|-
|
|team_id
|
|-
|
|
|AppID
|-
!TABLE NAME
!participants
!Participant
|-
!ATTRIBUTES
|user_id
|ParticipantID
|-
|
|id
|
|-
|
|
|AppID
|-
!TABLE NAME
|
!ActorParticipant
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|ParticipantID
|-
|
|
|RoleID
|-
!TABLE NAME
|
!Enrollment
|-
!ATTRIBUTES
|
|ParticipantID
|-
|
|
|AppID
|-
|
|
|CourseID
|-
!TABLE NAME
!Teams
!Artifact
|-
!ATTRIBUTES
|
|ActorID
|-
|
|
|TaskID
|-
|
|name
|ArtifactContent
|-
|
|NULL
|ArtifactCharLength
|-
|
|NULL
|ArtifactOpen
|-
|
|NULL
|ArtifactEnd
|-
!TABLE NAME
|
!Item
|-
!ATTRIBUTES
|
|ItemContent
|-
|
|
|ArtifactId
|-
!TABLE NAME
|
!Review
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CritiqueArtifactID
|-
!TABLE NAME
|
!ReviewCriterionLevel
|-
!ATTRIBUTES
|
|AssessorActorID
|-
|
|
|TaskID
|-
|
|
|AssessedArtifactID
|-
|
|
|CriterionID
|-
|
|
|CritiqueArtifactID
|-
|
|
|EvalMode
|-
|
|
|EvalLevelID
|-
|
|
|ValueOrdinal
|-
|
|
|ValueCardinal
|-
|
|
|Comment
|}

== Implementation ==
We have used an Extract, Transform and Load [https://en.wikipedia.org/wiki/Extract,_transform,_load ETL] tool, [http://community.pentaho.com/projects/data-integration/ Pentaho Kettle] to perform the data migration from Expertiza to PRML database.

[[File:diagram.png]]

The Pentaho Kettle tool extracts data from the expertise schema, performs transformation on it and load the data in the PRML format.
The tables are mapped as shown in the schema map above.
The operations performed by the ETL tool:

'''Extraction'''
The data is extracted from the expertise database and brought into the staging area by this operation of the ETL tool. It is the staging area in which all the transformation are done.

'''Transformation'''
Many operations are performed on the data in the staging area so that the expertise schema can be converted to the PRML schema. This is called transformation of the data. An example of transformation is while mapping of participants table in the expertiza database to actors table in the PRML database. Each value of the id field is incremented by 1000 while inserting in the participants table.

'''Loading:'''
The transformed data when moved from the staging area to the PRML database is called as loading. There are three types of loading implemented on the tables depending on the size of the table – initial load,partial loading and full loading.
Partial Loading: Only the new or updated entries in the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for table with very large number of entries. Eg: Reviews

Partial loading is implemented with the help of timestamps and checksums.

Timestamp: The expertiza database has a timestamp column which saves the timestamp that row was last modified at. There is a variable 'maxtimestamp' that saves the value of the time the rows from the experts database were last loaded in the PRML database. While doing the partial load, the query checks this variable and loads only the rows whose timestamp is greater than the 'maxtimestamp'. This way only the updated or the new entries are loaded in the PRML table.

Checksums: The checksum is also a way of implementing partial load, like the timestamp. In this case the checksum of the expertiza database is compared with the PRML database checksum. Only the rows whose checksum does not match, or does not exist is loaded.

Full Loading: All the entries from the expertiza table are transformed and loaded in the corresponding PRML table. This is generally done for tables will less number of entries.
Eg: Courses

'''Expertiza tables which have been implemented'''

Assignments Table - Full Load

Course Table - Full Load

ModifiedTimeStamp Table - Partial Load

Jobs are being performed in a sequential order in the current project. If the tables do not depend on one another they can be performed in a parellal way to reduce time.
Initially the entries in the table are buffered so that only around 8000 rows are processed at a time.

== Testing ==
We have tested our conversion by using a set of sample expertiza data. We run the extract, transform and load methodology on it. Queries are run on the PRML database to check if it gives the same results as the expertiza database.
Though the testing is not through, this is the only way the project can be tested.

==Running the Project==
'''Required Software:'''
*Pentaho’s Data Integration (Kettle).
*MySQL
*JAVA

'''Setup:'''
*Download and Install MySQL and JAVA
*Import to MySQL expertiza database dump file.
*Import to MySQL PRML database dump file.
*Download Pentaho's Data Integration(Kettle) Community Edition (its a copy deployment hence no installation is required).
*Download MySql Connector jar file and copy to <pentaho_root_directory\data-integration\lib>
*Start Spoon.bat if you are using a windows machine or Spoon.sh if you using Linux (pentaho_root_directory\data-integration)
*Download the transformations and jobs attached
*You can open a kettle transformation (.ktr file) using Spoon and run it (Make sure proper MySql DB connections are configured)
*You may also open the kettle job (.kjb file) using spoon and run it (Make sure the path for transformations in the job are correct)

User:Mrohatg2

2015-11-13T21:55:23Z

Mrohatg2: /* Expertiza Database Diagram */

User:Mrohatg2

2015-11-13T21:54:50Z

Mrohatg2:

User:Mrohatg2

2015-11-13T21:48:52Z

Mrohatg2:

File:Pg development.png

2015-11-13T21:45:27Z

Mrohatg2: uploaded a new version of "File:Pg development.png"

File:Pg development.png

2015-11-13T21:40:14Z

Mrohatg2: uploaded a new version of "File:Pg development.png"

File:Pg development.png

2015-11-13T21:35:53Z

Mrohatg2: uploaded a new version of "File:Pg development.png"

File:Pg development.png

2015-11-13T21:34:59Z

Mrohatg2:

User:Mrohatg2

2015-11-13T21:28:24Z

Mrohatg2:

User:Mrohatg2

2015-11-13T21:26:12Z

Mrohatg2:

User:Mrohatg2

2015-11-13T21:25:46Z

Mrohatg2:

User:Mrohatg2

2015-11-13T21:24:31Z

Mrohatg2:

User:Mrohatg2

2015-11-13T21:23:45Z

Mrohatg2:

User:Mrohatg2

2015-11-13T21:16:48Z

Mrohatg2:

User:Mrohatg2

2015-11-13T20:57:57Z

Mrohatg2: Created page with "E1575 - Share the data in Expertiza to a remote server via PRML format"

E1575 - Share the data in Expertiza to a remote server via PRML format

CSC/ECE 517 Fall 2015/oss E1550 KMM

2015-11-06T23:40:08Z

Mrohatg2: /* Relocate/Refactor code for sending emails to app/mailers */

=== E1550: Refactoring response.rb and response_helper.rb ===

== response.rb ==
response.rb is the class that manages the response to all rubrics in Expertiza. if someone fills out a review form, the instance of the review form is a Response. If someone gives feedback (a “rejoinder”) to an author, that is a Response too. Or if someone evaluates a teammate contribution, fills out a survey, or takes a quiz, they are creating a Response.

Note: Method display_as_html writes the HTML for displaying a rubric. This would ordinarily be view code, but it is used by so many different views that it is done here. Questions are written out in the order of their sequence number (anyone who creates a rubric can specify sequence numbers for questions). After all questions are displayed, there is a blank for an additional comment.

==== Rubric type checking via message to ResponseMap ====

==== Ensure score calculations utilize the weight of questions ====

When the get_maximum_score() function is called it takes care of the weight of the question. It multiplies the weight to the score and adds it to the final score.

<pre>
def get_maximum_score()
# only count the scorable questions, only when the answer is not nil (we accept nil as answer for scorable questions, and they will not be counted towards the total score)
total_weight = 0
scores.each do |s|
question = Question.find(s.question_id)
if !s.answer.nil? && question.is_a?(ScoredQuestion)
total_weight+=question.weight
end
end
if scores.empty?
questionnaire = questionnaire_by_answer(nil)
else
questionnaire = questionnaire_by_answer(scores.first)
end
total_weight*questionnaire.max_question_score
end
</pre>

==== Relocate/Refactor code for sending emails to app/mailers ====

All the email code has been shifted to the mailers

==== Remove comments in lines 25-27 ====
Comments have been removed.

[[File:Comments.JPG‎ |frame|center|Auto selected Reviewing]]

== response_helper.rb ==
response_helper.rb contains helper methods that display the questionnaires and rearrange questions so that the most frequently answered questions are at the bottom while the less frequently answered questions are at the top.

==== Refactor construct_table method ====
Method is no longer being used in Expertiza and has been removed.

==== Refactor rearrange_questions method ====
Method is no longer being used in Expertiza and has been removed.

[[File:response_helper.png‎ |frame|center|Auto selected Reviewing]]

CSC/ECE 517 Fall 2015/oss E1550 KMM

2015-11-06T23:16:36Z

Mrohatg2: /* Remove comments in lines 25-27 */

=== E1550: Refactoring response.rb and response_helper.rb ===

== response.rb ==
response.rb is the class that manages the response to all rubrics in Expertiza. if someone fills out a review form, the instance of the review form is a Response. If someone gives feedback (a “rejoinder”) to an author, that is a Response too. Or if someone evaluates a teammate contribution, fills out a survey, or takes a quiz, they are creating a Response.

Note: Method display_as_html writes the HTML for displaying a rubric. This would ordinarily be view code, but it is used by so many different views that it is done here. Questions are written out in the order of their sequence number (anyone who creates a rubric can specify sequence numbers for questions). After all questions are displayed, there is a blank for an additional comment.

==== Rubric type checking via message to ResponseMap ====

==== Ensure score calculations utilize the weight of questions ====

When the get_maximum_score() function is called it takes care of the weight of the question. It multiplies the weight to the score and adds it to the final score.

<pre>
def get_maximum_score()
# only count the scorable questions, only when the answer is not nil (we accept nil as answer for scorable questions, and they will not be counted towards the total score)
total_weight = 0
scores.each do |s|
question = Question.find(s.question_id)
if !s.answer.nil? && question.is_a?(ScoredQuestion)
total_weight+=question.weight
end
end
if scores.empty?
questionnaire = questionnaire_by_answer(nil)
else
questionnaire = questionnaire_by_answer(scores.first)
end
total_weight*questionnaire.max_question_score
end
</pre>

==== Relocate/Refactor code for sending emails to app/mailers ====

==== Remove comments in lines 25-27 ====
Comments have been removed.

[[File:Comments.JPG‎ |frame|center|Auto selected Reviewing]]

== response_helper.rb ==
response_helper.rb contains helper methods that display the questionnaires and rearrange questions so that the most frequently answered questions are at the bottom while the less frequently answered questions are at the top.

==== Refactor construct_table method ====
Method is no longer being used in Expertiza and has been removed.

==== Refactor rearrange_questions method ====
Method is no longer being used in Expertiza and has been removed.

CSC/ECE 517 Fall 2015/oss E1550 KMM

2015-11-06T23:15:03Z

Mrohatg2: /* Remove comments in lines 25-27 */

=== E1550: Refactoring response.rb and response_helper.rb ===

== response.rb ==
response.rb is the class that manages the response to all rubrics in Expertiza. if someone fills out a review form, the instance of the review form is a Response. If someone gives feedback (a “rejoinder”) to an author, that is a Response too. Or if someone evaluates a teammate contribution, fills out a survey, or takes a quiz, they are creating a Response.

Note: Method display_as_html writes the HTML for displaying a rubric. This would ordinarily be view code, but it is used by so many different views that it is done here. Questions are written out in the order of their sequence number (anyone who creates a rubric can specify sequence numbers for questions). After all questions are displayed, there is a blank for an additional comment.

==== Rubric type checking via message to ResponseMap ====

==== Ensure score calculations utilize the weight of questions ====

When the get_maximum_score() function is called it takes care of the weight of the question. It multiplies the weight to the score and adds it to the final score.

<pre>
def get_maximum_score()
# only count the scorable questions, only when the answer is not nil (we accept nil as answer for scorable questions, and they will not be counted towards the total score)
total_weight = 0
scores.each do |s|
question = Question.find(s.question_id)
if !s.answer.nil? && question.is_a?(ScoredQuestion)
total_weight+=question.weight
end
end
if scores.empty?
questionnaire = questionnaire_by_answer(nil)
else
questionnaire = questionnaire_by_answer(scores.first)
end
total_weight*questionnaire.max_question_score
end
</pre>

==== Relocate/Refactor code for sending emails to app/mailers ====

==== Remove comments in lines 25-27 ====
Comments have been removed.

[[File:Comments.JPG‎ |frame|left|Auto selected Reviewing]]

== response_helper.rb ==
response_helper.rb contains helper methods that display the questionnaires and rearrange questions so that the most frequently answered questions are at the bottom while the less frequently answered questions are at the top.

==== Refactor construct_table method ====
Method is no longer being used in Expertiza and has been removed.

==== Refactor rearrange_questions method ====
Method is no longer being used in Expertiza and has been removed.

CSC/ECE 517 Fall 2015/oss E1550 KMM

2015-11-06T23:14:45Z

Mrohatg2: /* Remove comments in lines 25-27 */

=== E1550: Refactoring response.rb and response_helper.rb ===

== response.rb ==
response.rb is the class that manages the response to all rubrics in Expertiza. if someone fills out a review form, the instance of the review form is a Response. If someone gives feedback (a “rejoinder”) to an author, that is a Response too. Or if someone evaluates a teammate contribution, fills out a survey, or takes a quiz, they are creating a Response.

Note: Method display_as_html writes the HTML for displaying a rubric. This would ordinarily be view code, but it is used by so many different views that it is done here. Questions are written out in the order of their sequence number (anyone who creates a rubric can specify sequence numbers for questions). After all questions are displayed, there is a blank for an additional comment.

==== Rubric type checking via message to ResponseMap ====

==== Ensure score calculations utilize the weight of questions ====

When the get_maximum_score() function is called it takes care of the weight of the question. It multiplies the weight to the score and adds it to the final score.

<pre>
def get_maximum_score()
# only count the scorable questions, only when the answer is not nil (we accept nil as answer for scorable questions, and they will not be counted towards the total score)
total_weight = 0
scores.each do |s|
question = Question.find(s.question_id)
if !s.answer.nil? && question.is_a?(ScoredQuestion)
total_weight+=question.weight
end
end
if scores.empty?
questionnaire = questionnaire_by_answer(nil)
else
questionnaire = questionnaire_by_answer(scores.first)
end
total_weight*questionnaire.max_question_score
end
</pre>

==== Relocate/Refactor code for sending emails to app/mailers ====

==== Remove comments in lines 25-27 ====
Comments have been removed.

[[File:Comments.JPG‎ |frame|center|Auto selected Reviewing]]

== response_helper.rb ==
response_helper.rb contains helper methods that display the questionnaires and rearrange questions so that the most frequently answered questions are at the bottom while the less frequently answered questions are at the top.

==== Refactor construct_table method ====
Method is no longer being used in Expertiza and has been removed.

==== Refactor rearrange_questions method ====
Method is no longer being used in Expertiza and has been removed.

File:Comments.JPG

2015-11-06T23:12:55Z

Mrohatg2:

CSC/ECE 517 Fall 2015/oss E1550 KMM

2015-11-06T23:05:07Z

Mrohatg2: /* Ensure score calculations utilize the weight of questions */

=== E1550: Refactoring response.rb and response_helper.rb ===

== response.rb ==
response.rb is the class that manages the response to all rubrics in Expertiza. if someone fills out a review form, the instance of the review form is a Response. If someone gives feedback (a “rejoinder”) to an author, that is a Response too. Or if someone evaluates a teammate contribution, fills out a survey, or takes a quiz, they are creating a Response.

Note: Method display_as_html writes the HTML for displaying a rubric. This would ordinarily be view code, but it is used by so many different views that it is done here. Questions are written out in the order of their sequence number (anyone who creates a rubric can specify sequence numbers for questions). After all questions are displayed, there is a blank for an additional comment.

==== Rubric type checking via message to ResponseMap ====

==== Ensure score calculations utilize the weight of questions ====

When the get_maximum_score() function is called it takes care of the weight of the question. It multiplies the weight to the score and adds it to the final score.

<pre>
def get_maximum_score()
# only count the scorable questions, only when the answer is not nil (we accept nil as answer for scorable questions, and they will not be counted towards the total score)
total_weight = 0
scores.each do |s|
question = Question.find(s.question_id)
if !s.answer.nil? && question.is_a?(ScoredQuestion)
total_weight+=question.weight
end
end
if scores.empty?
questionnaire = questionnaire_by_answer(nil)
else
questionnaire = questionnaire_by_answer(scores.first)
end
total_weight*questionnaire.max_question_score
end
</pre>

==== Relocate/Refactor code for sending emails to app/mailers ====

==== Remove comments in lines 25-27 ====
Comments have been removed.

== response_helper.rb ==
response_helper.rb contains helper methods that display the questionnaires and rearrange questions so that the most frequently answered questions are at the bottom while the less frequently answered questions are at the top.

==== Refactor construct_table method ====
Method is no longer being used in Expertiza and has been removed.

==== Refactor rearrange_questions method ====
Method is no longer being used in Expertiza and has been removed.

CSC/ECE 517 Fall 2015/oss E1550 KMM

2015-11-06T23:02:26Z

Mrohatg2: /* Ensure score calculations utilize the weight of questions */

=== E1550: Refactoring response.rb and response_helper.rb ===

== response.rb ==
response.rb is the class that manages the response to all rubrics in Expertiza. if someone fills out a review form, the instance of the review form is a Response. If someone gives feedback (a “rejoinder”) to an author, that is a Response too. Or if someone evaluates a teammate contribution, fills out a survey, or takes a quiz, they are creating a Response.

Note: Method display_as_html writes the HTML for displaying a rubric. This would ordinarily be view code, but it is used by so many different views that it is done here. Questions are written out in the order of their sequence number (anyone who creates a rubric can specify sequence numbers for questions). After all questions are displayed, there is a blank for an additional comment.

==== Rubric type checking via message to ResponseMap ====

==== Ensure score calculations utilize the weight of questions ====

When the get_maximum_score() function is called it takes care of the weight of the question. It multiplies the weight to the score and adds it to the final score.

def get_maximum_score()
# only count the scorable questions, only when the answer is not nil (we accept nil as answer for scorable questions, and they will not be counted towards the total score)
total_weight = 0
scores.each do |s|
question = Question.find(s.question_id)
if !s.answer.nil? && question.is_a?(ScoredQuestion)
total_weight+=question.weight
end
end
if scores.empty?
questionnaire = questionnaire_by_answer(nil)
else
questionnaire = questionnaire_by_answer(scores.first)
end
total_weight*questionnaire.max_question_score
end

==== Relocate/Refactor code for sending emails to app/mailers ====

==== Remove comments in lines 25-27 ====
Comments have been removed.

== response_helper.rb ==
response_helper.rb contains helper methods that display the questionnaires and rearrange questions so that the most frequently answered questions are at the bottom while the less frequently answered questions are at the top.

==== Refactor construct_table method ====
Method is no longer being used in Expertiza and has been removed.

==== Refactor rearrange_questions method ====
Method is no longer being used in Expertiza and has been removed.

CSC/ECE 517 Fall 2015/oss E1550 KMM

2015-11-06T22:58:58Z

Mrohatg2: /* Ensure score calculations utilize the weight of questions */

=== E1550: Refactoring response.rb and response_helper.rb ===

== response.rb ==
response.rb is the class that manages the response to all rubrics in Expertiza. if someone fills out a review form, the instance of the review form is a Response. If someone gives feedback (a “rejoinder”) to an author, that is a Response too. Or if someone evaluates a teammate contribution, fills out a survey, or takes a quiz, they are creating a Response.

Note: Method display_as_html writes the HTML for displaying a rubric. This would ordinarily be view code, but it is used by so many different views that it is done here. Questions are written out in the order of their sequence number (anyone who creates a rubric can specify sequence numbers for questions). After all questions are displayed, there is a blank for an additional comment.

==== Rubric type checking via message to ResponseMap ====

==== Ensure score calculations utilize the weight of questions ====

Question weights are taken into account when score is calculated.

<syntaxhighlight lang="ruby">
def get_maximum_score()
# only count the scorable questions, only when the answer is not nil (we accept nil as answer for scorable questions, and they will not be counted towards the total score)
total_weight = 0
scores.each do |s|
question = Question.find(s.question_id)
if !s.answer.nil? && question.is_a?(ScoredQuestion)
total_weight+=question.weight
end
end
if scores.empty?
questionnaire = questionnaire_by_answer(nil)
else
questionnaire = questionnaire_by_answer(scores.first)
end
total_weight*questionnaire.max_question_score
end
</syntaxhighlight>

==== Relocate/Refactor code for sending emails to app/mailers ====

==== Remove comments in lines 25-27 ====
Comments have been removed.

== response_helper.rb ==
response_helper.rb contains helper methods that display the questionnaires and rearrange questions so that the most frequently answered questions are at the bottom while the less frequently answered questions are at the top.

==== Refactor construct_table method ====
Method is no longer being used in Expertiza and has been removed.

==== Refactor rearrange_questions method ====
Method is no longer being used in Expertiza and has been removed.