Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-11-14T09:35:17Z

Rroshan: /* Introduction */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.

<div id="projectLinks" style="float: right;">
[[File:expertiza_logo.jpg|center]]
{| class="wikitable"
| colspan="3" align="center" | '''Expertiza project links'''
|-
| '''Refactored Instance'''
| http://152.46.18.78:3000/
| rowspan="2" | '''username= "user480" password= "password"'''
|-
| '''Original Instance'''
| http://152.46.18.78:3001/
|-
| '''Repository link'''
| colspan="3" | https://github.com/sanjeevs/expertiza <ref>[https://github.com/sanjeevs/expertiza Forked repository]</ref>
|-
| '''Pull request'''
| colspan="3" | https://github.com/expertiza/expertiza/pull/444 <ref>[https://github.com/expertiza/expertiza/pull/444 Pull request]</ref>
|}
</div>

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

=Changes in Model =

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

Also, there was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Design Pattern=
Leaderboard is a separate implementation which includes reading existing scores for the sole purpose of creating the leaders in different categories. As the task is more related to calculate and manipulate data, it was not feasible to implement any design pattern. We reduced the complexity and redundancy of database calls by reducing database calls from 625 to 111 to do the same task.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup. Login by any user and navigate to ''Home > Leaderboard'' to test the functionality.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#projectLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Lleaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated by the database driver by filtering the messages from the rails server's log. In the original code there were '''625''' database select access generated for the leaderboard view. In the new refactored code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in ''leaderboard_helper.rb'' to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to ''assignment_questionnaires'' table. This contains mapping of ''assignment id'' and ''questionnaire id''.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ''ScoreCache'' table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target ''participantId'' and ''teamId'' as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

File:E1475.Sequence Diagram.png

2014-11-12T02:50:34Z

Rroshan: uploaded a new version of "File:E1475.Sequence Diagram.png"

File:UseCase.png

2014-11-12T02:45:32Z

Rroshan: uploaded a new version of "File:UseCase.png"

File:DatabaseDesign.png

2014-11-12T02:42:35Z

Rroshan: uploaded a new version of "File:DatabaseDesign.png"

File:UML Design.png

2014-11-12T02:37:51Z

Rroshan: uploaded a new version of "File:UML Design.png"

File:UML Design.png

2014-11-12T02:33:27Z

Rroshan: uploaded a new version of "File:UML Design.png"

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:06:42Z

Rroshan: /* Previous work */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on FCFS (first come first serve) basis, where a team which first signs up for a topic gets the topic while other teams are waitlisted on the same topic. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#The assignment of topics are FCFS, hence not completely fair.
#Non-uniform distribution of topics among the teams in a class.
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist.
#The assignment of topics is more focused on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

==Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza]<ref>[http://expertiza.ncsu.edu/ Expertiza]</ref> is a project developed using [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]<ref>[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails ]</ref> platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU [http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]<ref>[http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]</ref> program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

==Existing signup process==
The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of [https://docs.google.com/document/d/1tyWX8njxDLvYpN7wJf5hjA6lnWbzQRP9vUKGxxRjRzo/edit#heading=h.5cgh9aixuut7/ ‘lottery based topic assignment’]<ref>[https://docs.google.com/document/d/1tyWX8njxDLvYpN7wJf5hjA6lnWbzQRP9vUKGxxRjRzo/edit#heading=h.5cgh9aixuut7/ Lottery based topic assignment]</ref> algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:

== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1), a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem] algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]<ref>[http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]</ref>. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:03:56Z

Rroshan: /* Database Design */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on FCFS (first come first serve) basis, where a team which first signs up for a topic gets the topic while other teams are waitlisted on the same topic. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#The assignment of topics are FCFS, hence not completely fair.
#Non-uniform distribution of topics among the teams in a class.
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist.
#The assignment of topics is more focused on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

==Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza]<ref>[http://expertiza.ncsu.edu/ Expertiza]</ref> is a project developed using [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]<ref>[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails ]</ref> platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU [http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]<ref>[http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]</ref> program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

==Existing signup process==
The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:

== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1), a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem] algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]<ref>[http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]</ref>. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:02:27Z

Rroshan: /* Expertiza */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on FCFS (first come first serve) basis, where a team which first signs up for a topic gets the topic while other teams are waitlisted on the same topic. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#The assignment of topics are FCFS, hence not completely fair.
#Non-uniform distribution of topics among the teams in a class.
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist.
#The assignment of topics is more focused on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

==Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza]<ref>[http://expertiza.ncsu.edu/ Expertiza]</ref> is a project developed using [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]<ref>[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails ]</ref> platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU [http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]<ref>[http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]</ref> program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

==Existing signup process==
The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:

== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1), a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem] algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:01:44Z

Rroshan: /* Expertiza */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on FCFS (first come first serve) basis, where a team which first signs up for a topic gets the topic while other teams are waitlisted on the same topic. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#The assignment of topics are FCFS, hence not completely fair.
#Non-uniform distribution of topics among the teams in a class.
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist.
#The assignment of topics is more focused on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

==Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza]<ref>[Expertiza http://expertiza.ncsu.edu/]</ref> is a project developed using [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]<ref>[Ruby on Rails http://en.wikipedia.org/wiki/Ruby_on_Rails]</ref> platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU [http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]<ref>[http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]</ref> program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

==Existing signup process==
The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:

== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1), a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem] algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:00:10Z

Rroshan: /* Database Design */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on FCFS (first come first serve) basis, where a team which first signs up for a topic gets the topic while other teams are waitlisted on the same topic. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#The assignment of topics are FCFS, hence not completely fair.
#Non-uniform distribution of topics among the teams in a class.
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist.
#The assignment of topics is more focused on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

==Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a project developed using [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU [http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]<ref>[http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]</ref> program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

==Existing signup process==
The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:

== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1), a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem] algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T00:59:43Z

Rroshan: /* References */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on FCFS (first come first serve) basis, where a team which first signs up for a topic gets the topic while other teams are waitlisted on the same topic. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#The assignment of topics are FCFS, hence not completely fair.
#Non-uniform distribution of topics among the teams in a class.
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist.
#The assignment of topics is more focused on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

==Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a project developed using [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU [http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]<ref>[http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]</ref> program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

==Existing signup process==
The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:

== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1), a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem] algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

<references/>
[http://expertiza.ncsu.edu/ Expertiza] 
[https://docs.google.com/document/d/1tyWX8njxDLvYpN7wJf5hjA6lnWbzQRP9vUKGxxRjRzo/edit#heading=h.5cgh9aixuut7/ Lottery based topic assignment doc] 
[https://github.com/csuich2/expertiza/tree/lottery_topic_selection/ Lottery based topic assignment code] 
[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable Marriage Problem] 
[http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T00:55:55Z

Rroshan: /* Expertiza */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on FCFS (first come first serve) basis, where a team which first signs up for a topic gets the topic while other teams are waitlisted on the same topic. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#The assignment of topics are FCFS, hence not completely fair.
#Non-uniform distribution of topics among the teams in a class.
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist.
#The assignment of topics is more focused on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

==Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a project developed using [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU [http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]<ref>[http://litre.ncsu.edu/ Learning in a Technology-Rich Environment (LITRE)]</ref> program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

==Existing signup process==
The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:

== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1), a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem] algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation crow foot's notation]<ref>[http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]</ref>. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
[http://expertiza.ncsu.edu/ Expertiza] 
[https://docs.google.com/document/d/1tyWX8njxDLvYpN7wJf5hjA6lnWbzQRP9vUKGxxRjRzo/edit#heading=h.5cgh9aixuut7/ Lottery based topic assignment doc] 
[https://github.com/csuich2/expertiza/tree/lottery_topic_selection/ Lottery based topic assignment code] 
[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable Marriage Problem]

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T00:45:41Z

Rroshan: /* Problem Statement */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on FCFS (first come first serve) basis, where a team which first signs up for a topic gets the topic while other teams are waitlisted on the same topic. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#The assignment of topics are FCFS, hence not completely fair.
#Non-uniform distribution of topics among the teams in a class.
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist.
#The assignment of topics is more focused on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

==Expertiza<ref name="Expertiza">http://expertiza.ncsu.edu/</ref> ==

[http://expertiza.ncsu.edu/ Expertiza] is a project developed using [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

==Existing signup process==
The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work <ref name="Previous 2012 Work">https://docs.google.com/document/d/1tyWX8njxDLvYpN7wJf5hjA6lnWbzQRP9vUKGxxRjRzo/edit#heading=h.5cgh9aixuut7</ref>==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:
== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1), a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified ‘stable matching’ algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation crow foot's notation]<ref>[http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]</ref>. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T00:23:56Z

Rroshan: /* Database Design */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on first come first serve basis, where a team which first signs up for a topic gets the topic while the other teams which choose the same topic are waitlisted. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#Non-uniform distribution of topic between teams in a class
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist
#The assignment of topics is more focussed on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.
== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:
== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:
<pre>
a) The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on. 
b) For a team which satisfies condition(1) mentioned above, a topic would be assigned to the team based on the priority order of the bids that the team specified.
</pre>
== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified ‘stable matching’ algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation crow foot's notation]<ref>[http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation Crow Foot's Notation]</ref>. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T00:23:09Z

Rroshan: /* Database Design */

= E1475. Intelligent assignment of teams =

= Problem Statement =

According to the existing code workflow, the assignment of topics to teams are based on first come first serve basis, where a team which first signs up for a topic gets the topic while the other teams which choose the same topic are waitlisted. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

#Non-uniform distribution of topic between teams in a class
#The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist
#The assignment of topics is more focussed on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

= Introduction =

The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.
== Pitfalls with the current system ==
#One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
#If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
#If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
#Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

== Previous work ==
Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:
#It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
#The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

= Design Workflow =
To address the issues faced by both, the current system and lottery based system, we propose a solution based on ‘intelligent team assignment’ algorithm. The algorithm is based on two important factors:

#Team strength
#Priority order of the topics submitted by the team.

The algorithm works on bidding process which can be explained as follows:
== Before the bidding process ==
#Initially, every student is a team of 1 member. Before the bidding process takes place, students can merge their teams to form a larger team. The person to whom they have merged becomes the team owner/captain.
#Every team is given x bids(x is calculated based on the total class strength and total topics proposed), that they can place on each topic of their choice in a priority order where 1 being the highest priority.
#Every topic is allowed ‘p’ number of maximum bids after which the topic is waitlisted in the system.
#Teams can also place their bids on waitlisted topics. However, every topic has a threshold ‘q’ which signifies the maximum waitlisted bids allowed for each topic.
#Thus, if the combined threshold of ‘p+q’ bids for a topic is reached then the topic is no longer available for bidding unless the topic is dropped by a team which reduces the ‘p+q’ threshold value.

== During Bidding Process ==
#Every team can place their bids on the available topics. Since every team is given ‘x’ bids, each team can bid for ‘x’ topics and list their bids in a priority order.
#A team can also place their bids on waitlisted topics. The maximum allowed bids for waitlisted topics is ‘y’ where y is some portion of bids taken from total bids(x) allowed for each team.

== After the Bidding Process ==
#After the bidding process is complete, the teams can continue to merge to form larger teams.
#If team A merges with team B, the bids of team A would be lost.
#The merging of the teams is allowed till the topic assignment date when the teams would finally be assigned the topics by running an algorithm.
#The teams can also change their submitted topic priority order any number of times before running the ‘topic assignment’ algorithm.

The algorithm assigns the topic to each teams based on the following factors:

# The team which is close to or has maximum possible team strength has a higher probability of winning the topic they had placed their bid on.
# For a team which satisfies condition(1) mentioned above, a topic would be assigned to the team based on the priority order of the bids that the team specified.

== Features ==
#As each team can place their bids on the available topics based on their topic priority. Hence every team gets to choose more than one topic of their choice.

#As every topic has a maximum number of allowed bids, after which the topic is no longer available for bidding, this method addresses the issue where many teams choose only a handful topics among all topics.

#As the maximum allowed bids for waitlisting a topic is also limited for every team, hence the issue of unnecessary additions to waitlist is resolved by this method.

#The teams are assigned topics based on modified ‘stable matching’ algorithm which considers factors such as team size and priority ensuring that the topics are no longer assigned based on FCFS basis. Thus this method addresses the most important issue where a topic is not assigned to the team just because the team was late to sign up for the topic as compared to the other teams.

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=

The intelligent assignment controller is dependent on the ''AssignmentTopicController'' and other models like - ''Assignment'', ''AssignmentTopic'' and ''Team''. When the instructor starts the intelligent assignment of topics to teams, ''IntelligentAssignmentController'' triggers the assignment algorithm.

The students interact with ''AssignmentTopicView'' which lists down all the topics for the assignment and allows students to bid for topics with priority. ''AssignmentTopicController'' is responsible for recording all the bids and priorities correctly.

Following is the UML diagram of the O-O design focusing only on the component related to intelligent assignment of topics to teams.

[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in [http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation crow foot's notation]<ref>[http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow.27s_foot_notation]</ref>. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T00:12:48Z

Rroshan: /* UML Design */

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T00:04:11Z

Rroshan: /* Database Design */

=Requirements=

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

=Sequence Diagram=
[[File:E1475.Sequence Diagram.png|frame|center|Fig 1. Sequence Diagram]]
Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created.
Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

=UML Design=
[[File: UML_Design.png|UML Design|frame|center]]

=Database Design=

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in crow foot's notation. The ''user'' table mentioned is not new and is present only to explain the field - ''ownerId''.

Earlier, all the information in ''AssignmentTopic'' and ''AssignmentTopicMetadata'' tables were in a single table called ''signup_topics''. However, there was lot of data redundancy observed and we also required to add an extra field in the table ''signup_topics''. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table ''bid'' is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have ''(ownerId, topicId)'' pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field ''id'' as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

[[File: DatabaseDesign.png|Database Design|frame|center]]

=References=
<references/>

File:DatabaseDesign.png

2014-11-11T23:46:10Z

Rroshan:

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-11T22:25:53Z

Rroshan: /* UML Design */

File:UML Design.png

2014-11-11T19:24:33Z

Rroshan: uploaded a new version of "File:UML Design.png"

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-11T19:16:33Z

Rroshan: /* UML Design */

File:UML Design.png

2014-11-11T19:15:55Z

Rroshan:

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-11T17:56:19Z

Rroshan: /* References */

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-11-06T03:07:19Z

Rroshan: /* Testing */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.

<div id="projectLinks" style="float: right;">
[[File:expertiza_logo.jpg|center]]
{| class="wikitable"
| colspan="3" align="center" | '''Expertiza project links'''
|-
| '''Refactored Instance'''
| http://152.1.13.181:3000
| rowspan="2" | '''username= "user480" password= "password"'''
|-
| '''Original Instance'''
| http://152.1.13.181:3001
|-
| '''Repository link'''
| colspan="3" | https://github.com/sanjeevs/expertiza <ref>[https://github.com/sanjeevs/expertiza Forked repository]</ref>
|-
| '''Pull request'''
| colspan="3" | https://github.com/expertiza/expertiza/pull/444 <ref>[https://github.com/expertiza/expertiza/pull/444 Pull request]</ref>
|}
</div>

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

=Changes in Model =

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

Also, there was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Design Pattern=
Leaderboard is a separate implementation which includes reading existing scores for the sole purpose of creating the leaders in different categories. As the task is more related to calculate and manipulate data, it was not feasible to implement any design pattern. We reduced the complexity and redundancy of database calls by reducing database calls from 625 to 111 to do the same task.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup. Login by any user and navigate to ''Home > Leaderboard'' to test the functionality.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#projectLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Lleaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated by the database driver by filtering the messages from the rails server's log. In the original code there were '''625''' database select access generated for the leaderboard view. In the new refactored code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in ''leaderboard_helper.rb'' to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to ''assignment_questionnaires'' table. This contains mapping of ''assignment id'' and ''questionnaire id''.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ''ScoreCache'' table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target ''participantId'' and ''teamId'' as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T23:26:32Z

Rroshan: /* Introduction */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.

<div id="projectLinks" style="float: right;">
[[File:expertiza_logo.jpg|center]]
{| class="wikitable"
| colspan="3" align="center" | '''Expertiza project links'''
|-
| '''Refactored Instance'''
| http://152.1.13.181:3000
| rowspan="2" | '''username= "user480" password= "password"'''
|-
| '''Original Instance'''
| http://152.1.13.181:3001
|-
| '''Repository link'''
| colspan="3" | https://github.com/sanjeevs/expertiza <ref>[https://github.com/sanjeevs/expertiza Forked repository]</ref>
|-
| '''Pull request'''
| colspan="3" | https://github.com/expertiza/expertiza/pull/444 <ref>[https://github.com/expertiza/expertiza/pull/444 Pull request]</ref>
|}
</div>

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

=Changes in Model =

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

Also, there was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Lleaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated by the database driver by filtering the messages from the rails server's log. In the original code there were '''625''' database select access generated for the leaderboard view. In the new refactored code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in ''leaderboard_helper.rb'' to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to ''assignment_questionnaires'' table. This contains mapping of ''assignment id'' and ''questionnaire id''.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ''ScoreCache'' table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target ''participantId'' and ''teamId'' as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T23:24:21Z

Rroshan: /* Introduction */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.

<div id="projectLinks" style="float: right;">
[[File:expertiza_logo.jpg|center]]
{| class="wikitable"
| colspan="3" align="center" | '''Expertiza project links'''
|-
| '''Refactored Instance'''
| http://152.1.13.181:3000
| rowspan="2" | '''username= "user480" password= "password"'''
|-
| '''Original Instance'''
| http://152.1.13.181:3001
|-
| '''Project link'''
| colspan="3" | https://github.com/sanjeevs/expertiza
|-
| '''Pull request'''
| colspan="3" | https://github.com/expertiza/expertiza/pull/444
|}
</div>

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

=Changes in Model =

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

Also, there was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Lleaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated by the database driver by filtering the messages from the rails server's log. In the original code there were '''625''' database select access generated for the leaderboard view. In the new refactored code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in ''leaderboard_helper.rb'' to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to ''assignment_questionnaires'' table. This contains mapping of ''assignment id'' and ''questionnaire id''.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ''ScoreCache'' table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target ''participantId'' and ''teamId'' as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

File:Expertiza logo.jpg

2014-10-29T23:23:59Z

Rroshan:

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T23:15:37Z

Rroshan: /* Introduction */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | '''Expertiza project links'''
|-
| '''Refactored Instance'''
| http://152.1.13.181:3000
| rowspan="2" | '''username= "user480" password= "password"'''
|-
| '''Original Instance'''
| http://152.1.13.181:3001
|-
| '''Project link'''
| colspan="3" | https://github.com/sanjeevs/expertiza
|-
| '''Pull request'''
| colspan="3" | https://github.com/expertiza/expertiza/pull/444
|}


__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

=Changes in Model =

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

Also, there was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Lleaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated by the database driver by filtering the messages from the rails server's log. In the original code there were '''625''' database select access generated for the leaderboard view. In the new refactored code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in ''leaderboard_helper.rb'' to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to ''assignment_questionnaires'' table. This contains mapping of ''assignment id'' and ''questionnaire id''.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ''ScoreCache'' table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target ''participantId'' and ''teamId'' as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T23:05:34Z

Rroshan: /* Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

=Changes in Model =

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

Also, there was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Lleaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated by the database driver by filtering the messages from the rails server's log. In the original code there were '''625''' database select access generated for the leaderboard view. In the new refactored code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in ''leaderboard_helper.rb'' to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to ''assignment_questionnaires'' table. This contains mapping of ''assignment id'' and ''questionnaire id''.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ''ScoreCache'' table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target ''participantId'' and ''teamId'' as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:56:33Z

Rroshan: /* Changes in Model */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

=Changes in Model =

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

Also, there was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:55:44Z

Rroshan: /* Existing Functionality */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:54:58Z

Rroshan: /* Changes in Helper */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:54:40Z

Rroshan: /* Changes in Model */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|style="text-align:center;"|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|style="text-align:center;"|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|style="text-align:center;"|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|style="text-align:center;"|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:54:09Z

Rroshan: /* Existing Functionality */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|style="text-align:center;"|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|style="text-align:center;"|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|style="text-align:center;"|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:50:05Z

Rroshan: /* Introduction */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type (''ReviewQuestionnaire'', ''AuthorFeedbackQuestionnaire'', ''MetareviewQuestionnaire'' and ''TeammateReviewQuestionnaire''), in each course of the logged-in user. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:46:25Z

Rroshan: /* Performance Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost '''15%'''.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:46:01Z

Rroshan: /* Performance Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable" style="text-align: center;"
|-
! Iteration
! Original Version
! Refactored Version

|-
|'''1'''
| 2.08
| 1.76
|-
|'''2'''
| 2.02
| 1.66
|-
|'''3'''
| 2.01
| 1.76
|-
|'''4'''
| 1.97
| 1.76
|-
|'''5'''
| 1.93
| 1.72
|-
|'''6'''
| 1.97
| 1.75
|-
|'''7'''
| 2.12
| 1.74
|-
|'''8'''
| 1.99
| 1.71
|-
|'''9'''
| 2.12
| 1.80
|-
|'''10'''
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:43:56Z

Rroshan: /* Database Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code style="background:#F0F0FF"> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code style="background:#F0F0FF"> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code style="background:#F0F0FF"> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==

We computed the number of data base ''"SELECT"'' call generated the database driver by filtering the messages from the rails server. In the original code there were '''625''' database select access generated for the leaderboard view. In the new code the number of select calls dropped to '''111'''.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| '''roles'''
| style="text-align: center;"|52
| style="text-align: center;"|13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| '''users'''
| style="text-align: center;"|25
| style="text-align: center;"|25
| No Change
|-
| '''participants'''
| style="text-align: center;"|111
| style="text-align: center;"|3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| '''assignments'''
| style="text-align: center;"|16
| style="text-align: center;"|5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| '''assignment_questionnaires'''
| style="text-align: center;"|11
| style="text-align: center;"|0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| '''questionnaires'''
| style="text-align: center;"|311
| style="text-align: center;"|0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| '''score_caches'''
| style="text-align: center;"|22
| style="text-align: center;"|1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| '''teams'''
| style="text-align: center;"|11
| style="text-align: center;"|2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| '''teams_users'''
| style="text-align: center;"|52
| style="text-align: center;"|52
| No change
|-
| '''leaderboards'''
| style="text-align: center;"|9
| style="text-align: center;"|5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. (e.g. ''"ReviewQuestionnaire" - "Submitted Work"''). It was reduced to fetch all such mapping and cached.
|-
| '''courses'''
| style="text-align: center;"|5
| style="text-align: center;"|5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:05:03Z

Rroshan: /* Database Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:2%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:30:35Z

Rroshan: /* Database Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Database calls to Assignments table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ScoreCache, which has revieweeId and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of response object_type to the questionnaire_type and reduces the usage to 0.
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:22:42Z

Rroshan: /* Introduction */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Assignem
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:20:12Z

Rroshan: /* Testing */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza Links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=
On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Assignem
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:11:39Z

Rroshan: /* Database Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.
[[#TestingLinks|Testing Links]]
'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. '''e.g. Username/Password: user480/password'''

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Assignem
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:06:13Z

Rroshan: /* Testing */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.


{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| Original Instance
| http://152.1.13.181:3001
|}

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

'''Note for testing :''' It is recommended that in order to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there are other existing users who have participated in the same assignment. '''e.g. Username/Password: user480/password'''

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:03:27Z

Rroshan: /* Future Work */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:53:05Z

Rroshan: /* Code Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480", password= "password"
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:52:46Z

Rroshan: /* Code Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480", password= "password"
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|left|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:52:26Z

Rroshan: /* Code Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480", password= "password"
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:51:55Z

Rroshan: /* Code Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480", password= "password"
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center]]

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment.

= References =
<references/>