Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-22T21:19:34Z

Nmpedema: /* Modified version of Stable Matching Algorithm */

'''E1475. Intelligent assignment of teams'''

This page discusses the requirements and design specifications of final project E1475. Intelligent Assignment of teams. It starts out by giving an introduction and discussing previous implementations and related work. It then details out the workflow of the proposed implementation and shows the use case diagrams and sequence diagrams associated with it. Finally the page mentions discusses the class design and database design that would go with the implementation of the project.

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b>Requirements</b>=

#The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)
#The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.
#The teams should be able place bids on different topics limited to the number set by the instructor for these assignments
#The teams should be able to prioritize their bids.
#The instructor should be able to kick off [what does that mean?] the intelligent assignment of teams.

=<b> Design Workflow </b>=
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. [Describe the rationale for this. Is p just the number of slots?]
#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. [I can guess how this might be implemented, but an example would help to clarify. Also, I am interested in the rationale.]

== 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. [It would be better to keep bids, insofar as possible. Losing one's topic is a "gotcha" of joining a team, and I wouldn't want to see that continue under this system.]
#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.
<pre>
The algorithm assigns the topic to each teams based on the following factors:
1. 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.
2. 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. [I don't think that this defines an algorithm. An algorithm needs to be a set of steps in order. This just describes the result.]
</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 [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
|width="100px" | '''Use Case'''
|width="700px" |'''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
|width="100px" |'''Use Case'''
|width="700px" |'''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
|width="100px" | '''Use Case'''
| width="700px" |'''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
|width="100px" | '''Use Case'''
|width="700px" | '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priority of the topic. <br/>The system updates the bid for the topic with corresponding priority.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
| width="100px" |'''Use Case'''
|width="700px" | '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run intelligent assignment option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>Modified version of Stable Matching Algorithm</b>=

This flow chart illustrates the algorithm used to assign topics to teams based on the strength of the teams(bidder) and the priority in which they bid for the topic.

[[File: Chart.png|Modified version of Stable Matching|frame|center]]

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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 scenario, 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]]

=<b>Design Patterns</b>=

The following patterns are used:
#<b>DRY</b>: Separating out the redundant data from SignUpTopic
#<b>MVC</b>
#<b>Separation of concerns</b>: The IntelligentAssignmentTopicController is separated from AssignmentTopicController as the former's functionality is specific and hence should not be part of the general AssignmentTopic Controller.

=<b>References</b>=
<references/>

File:Chart.png

2014-11-22T21:19:07Z

Nmpedema:

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-22T21:17:02Z

Nmpedema: /* Modified version of Stable Matching Algorithm */

'''E1475. Intelligent assignment of teams'''

This page discusses the requirements and design specifications of final project E1475. Intelligent Assignment of teams. It starts out by giving an introduction and discussing previous implementations and related work. It then details out the workflow of the proposed implementation and shows the use case diagrams and sequence diagrams associated with it. Finally the page mentions discusses the class design and database design that would go with the implementation of the project.

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b>Requirements</b>=

#The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)
#The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.
#The teams should be able place bids on different topics limited to the number set by the instructor for these assignments
#The teams should be able to prioritize their bids.
#The instructor should be able to kick off [what does that mean?] the intelligent assignment of teams.

=<b> Design Workflow </b>=
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. [Describe the rationale for this. Is p just the number of slots?]
#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. [I can guess how this might be implemented, but an example would help to clarify. Also, I am interested in the rationale.]

== 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. [It would be better to keep bids, insofar as possible. Losing one's topic is a "gotcha" of joining a team, and I wouldn't want to see that continue under this system.]
#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.
<pre>
The algorithm assigns the topic to each teams based on the following factors:
1. 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.
2. 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. [I don't think that this defines an algorithm. An algorithm needs to be a set of steps in order. This just describes the result.]
</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 [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
|width="100px" | '''Use Case'''
|width="700px" |'''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
|width="100px" |'''Use Case'''
|width="700px" |'''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
|width="100px" | '''Use Case'''
| width="700px" |'''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
|width="100px" | '''Use Case'''
|width="700px" | '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priority of the topic. <br/>The system updates the bid for the topic with corresponding priority.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 800px; height: 200px" border="1"
|-
| width="100px" |'''Use Case'''
|width="700px" | '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run intelligent assignment option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>Modified version of Stable Matching Algorithm</b>=

This flow chart illustrates the algorithm used to assign topics to teams based on the strength of the teams(bidder) and the priority in which they bid for the topic.

[[File: Intel.png|Modified version of Stable Matching|frame|center]]

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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 scenario, 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]]

=<b>Design Patterns</b>=

The following patterns are used:
#<b>DRY</b>: Separating out the redundant data from SignUpTopic
#<b>MVC</b>
#<b>Separation of concerns</b>: The IntelligentAssignmentTopicController is separated from AssignmentTopicController as the former's functionality is specific and hence should not be part of the general AssignmentTopic Controller.

=<b>References</b>=
<references/>

File:Intel.png

2014-11-22T21:15:11Z

Nmpedema:

File:IA.png

2014-11-22T21:04:08Z

Nmpedema: uploaded a new version of "File:IA.png"

File:IA.png

2014-11-22T21:03:44Z

Nmpedema:

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T03:40:33Z

Nmpedema: /* Use Cases */

'''E1475. Intelligent assignment of teams'''

This page discusses the requirements and design specifications of final project E1475. Intelligent Assignment of teams. It starts out by giving an introduction and discussing previous implementations and related work. It then details out the workflow of the proposed implementation and shows the use case diagrams and sequence diagrams associated with it. Finally the page mentions discusses the class design and database design that would go with the implementation of the project.

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b>Requirements</b>=

#The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)
#The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.
#The teams should be able place bids on different topics limited to the number set by the instructor for these assignments
#The teams should be able to prioritize their bids.
#The instructor should be able to kick off the intelligent assignment of teams.

=<b> Design Workflow </b>=
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.
<pre>
The algorithm assigns the topic to each teams based on the following factors:
1. 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.
2. 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.
</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 [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="100pt" | '''Use Case'''
|width="100pt" |'''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="100pt" |'''Use Case'''
|width="100pt" |'''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="100pt" | '''Use Case'''
| width="100pt" |'''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="100pt" | '''Use Case'''
|width="100pt" | '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priority of the topic. <br/>The system updates the bid for the topic with corresponding priority.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| width="100pt" |'''Use Case'''
|width="100pt" | '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run intelligent assignment option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T03:39:53Z

Nmpedema: /* Use Cases */

'''E1475. Intelligent assignment of teams'''

This page discusses the requirements and design specifications of final project E1475. Intelligent Assignment of teams. It starts out by giving an introduction and discussing previous implementations and related work. It then details out the workflow of the proposed implementation and shows the use case diagrams and sequence diagrams associated with it. Finally the page mentions discusses the class design and database design that would go with the implementation of the project.

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b>Requirements</b>=

#The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)
#The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.
#The teams should be able place bids on different topics limited to the number set by the instructor for these assignments
#The teams should be able to prioritize their bids.
#The instructor should be able to kick off the intelligent assignment of teams.

=<b> Design Workflow </b>=
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.
<pre>
The algorithm assigns the topic to each teams based on the following factors:
1. 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.
2. 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.
</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 [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="50pt" | '''Use Case'''
|width="100pt" |'''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="100pt" |'''Use Case'''
|width="100pt" |'''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="50pt" | '''Use Case'''
| width="100pt" |'''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="50pt" | '''Use Case'''
|width="100pt" | '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priority of the topic. <br/>The system updates the bid for the topic with corresponding priority.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| width="50pt" |'''Use Case'''
|width="100pt" | '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run intelligent assignment option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T03:36:09Z

Nmpedema: /* Use Cases */

'''E1475. Intelligent assignment of teams'''

This page discusses the requirements and design specifications of final project E1475. Intelligent Assignment of teams. It starts out by giving an introduction and discussing previous implementations and related work. It then details out the workflow of the proposed implementation and shows the use case diagrams and sequence diagrams associated with it. Finally the page mentions discusses the class design and database design that would go with the implementation of the project.

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b>Requirements</b>=

#The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)
#The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.
#The teams should be able place bids on different topics limited to the number set by the instructor for these assignments
#The teams should be able to prioritize their bids.
#The instructor should be able to kick off the intelligent assignment of teams.

=<b> Design Workflow </b>=
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.
<pre>
The algorithm assigns the topic to each teams based on the following factors:
1. 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.
2. 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.
</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 [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| width="50pt" | '''Use Case'''
| width="100pt" |'''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| width="50pt" |'''Use Case'''
| width="100pt" |'''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="50pt" | '''Use Case'''
| width="100pt" |'''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
|width="50pt" | '''Use Case'''
|width="100pt" | '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priority of the topic. <br/>The system updates the bid for the topic with corresponding priority.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| width="50pt" |'''Use Case'''
|width="100pt" | '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run intelligent assignment option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T03:33:40Z

Nmpedema: /* Use Cases */

'''E1475. Intelligent assignment of teams'''

This page discusses the requirements and design specifications of final project E1475. Intelligent Assignment of teams. It starts out by giving an introduction and discussing previous implementations and related work. It then details out the workflow of the proposed implementation and shows the use case diagrams and sequence diagrams associated with it. Finally the page mentions discusses the class design and database design that would go with the implementation of the project.

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b>Requirements</b>=

#The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)
#The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.
#The teams should be able place bids on different topics limited to the number set by the instructor for these assignments
#The teams should be able to prioritize their bids.
#The instructor should be able to kick off the intelligent assignment of teams.

=<b> Design Workflow </b>=
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.
<pre>
The algorithm assigns the topic to each teams based on the following factors:
1. 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.
2. 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.
</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 [http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| width="50pt" | '''Use Case'''
| width="100pt" |'''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| '''Use Case''' || '''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| '''Use Case''' || '''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| '''Use Case''' || '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priority of the topic. <br/>The system updates the bid for the topic with corresponding priority.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 100; height: 200px" border="1"
|-
| width="50pt" |'''Use Case'''
|width="100pt" | '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run intelligent assignment option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T02:41:16Z

Nmpedema: /* Use Cases */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priority of the topic. <br/>The system updates the bid for the topic with corresponding priority.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run intelligent assignment option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T02:19:58Z

Nmpedema: /* Use Cases */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priority of the topic.
<br/>The system updates the bid for the topic with corresponding priority.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run intelligent assignment option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T02:13:08Z

Nmpedema: /* Use Cases */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Delete bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student clicks “Delete bid”.<br/>The system removes the bid for the topic.<br/>The system presents the updated view reflecting the changes.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Reorder Priorities'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>Student has already selected few topics for bidding.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic for which the bid existed.<br/>The student changes the priorities of the topics.
<br/>The system updates the bid for the topics with corresponding priorities.<br/>The system presents the updated view with reordered topics.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Run Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and enabled the intelligent assignment option.<br/>The due date for the topic selection has passed.
|-
| Postconditions || The topics are intelligently assigned to the teams
|-
| Basic Flow || The instructor selects the assignment for which topic selection process has completed. <br/>The instructor selects the run lottery option.<br/>The system performs intelligent assignment of topics and allots topics to teams.
|}
<br/>

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T02:05:10Z

Nmpedema: /* Use Cases */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}
<br/>
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Add bids'''
|-
| Primary Actor || Student (Team Leader)
|-
| Preconditions || Student is logged into expertiza system . <br/>SignUp sheet with the list of topics is available for the assignment.
|-
| Trigger || Student selects the assignment in the topic selection phase
|-
| Basic Flow || The student selects the topic of interest from the list of topics in the SignUp sheet. <br/>The student chooses the priority of the topic.<br/>The system saves the bid for the topic and the corresponding priority.<br/>The system presents the updated view with the chosen topic.
|-
| Alternate Flow || The student has already exceeded the maximum bid limit but still selects a topic.<br/>The system throws an error saying “Bid limit exceeded”
|}

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T02:00:24Z

Nmpedema: /* Use Cases */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. <br/>Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment. <br/>Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started. <br/>The instructor checks the “Enable Intelligent Assignment” option and presses Save.<br/>The system saves the instructors choice for the assignment.
|}

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:57:34Z

Nmpedema: /* Use Cases */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system.
Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment.
Students can place their bids for the assignment topics on commencement of the selection process
|-
| Basic Flow || The instructor selects the assignment for which the topic selection process has not yet started.
The instructor checks the “Enable Intelligent Assignment” option and presses Save.
The system saves the instructors choice for the assignment.
|}

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:53:23Z

Nmpedema: /* Use Cases */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]
{| style="width: 60%; height: 200px" border="1"
|-
| '''Use Case''' || '''Enable Intelligent Assignment'''
|-
| Primary Actor || Instructor
|-
| Preconditions || Instructor is logged into the Expertiza system. Instructor has created an Assignment and allotted the Assignment Topics
|-
| Postconditions || Intelligent Assignment option is enabled for the assignment.
|}

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:35:50Z

Nmpedema: /* Use Cases */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=
[[File:UseCase.png|frame|center|Fig. Use Case Diagram]]

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

File:UseCase.png

2014-11-12T01:34:12Z

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

CSC/ECE 517 Fall 2014/final E1475 nrnn

2014-11-12T01:31:22Z

Nmpedema: /* Sequence Diagram */

=<b> E1475. Intelligent assignment of teams</b> =

=<b> Problem Statement</b> =

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.

=<b> Introduction </b>=

==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]<ref>[https://github.com/expertiza/expertiza github]</ref>. 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 [http://en.wikipedia.org/wiki/First-come,_first-served FCFS]<ref>[http://en.wikipedia.org/wiki/First-come,_first-served FCFS]</ref> 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.

=<b> Design Workflow </b>=
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]<ref>[http://en.wikipedia.org/wiki/Stable_marriage_problem/ Stable marriage problem]</ref> 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.

=<b>Requirements</b>=

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.

=<b>Sequence Diagram</b>=
[[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.

=<b>Use Cases</b>=

=<b>UML Design</b>=

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]]

=<b>Database Design</b>=

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]]

=<b>References</b>=
<references/>

CSC/ECE 517 Fall 2014/oss E1462 nms

2014-11-06T06:48:51Z

Nmpedema: /* Using Routing Helpers */

=Expertiza - Refactoring SurveyResponsesController=

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is an open source web portal for the use of both students and professors. Expertiza allows us to create reusable learning objects through peer review. It allows project submission, team creation and the submission of almost any document type, including URLs and wiki pages. Students can access their pending and finished assignments, they can do peer reviews on several topics and projects. It is developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code has been forked and cloned for making modifications to the to survey responses controller.

This wiki provides an insight into our contributions to the OSS Expertiza application, focusing on Refactoring the SurveyResponses Controller.

<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.142/:3000
| rowspan="2" | '''username= "user2"<br />password= "password"'''
|-
| '''Original Instance'''
| http://152.46.19.10:3000/
|-
| '''Repository link'''
| colspan="3" | https://github.com/nmpedema/expertiza <ref>[https://github.com/nmpedema/expertiza Forked repository]</ref>
|-
| '''Pull request'''
| colspan="3" | https://github.com/expertiza/expertiza/pull/448 <ref>[https://github.com/expertiza/expertiza/pull/448 Pull request]</ref>
|}
</div>
__TOC__

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*<b>Fat Classes</b>: No class should be fat. Ever. There is no need for your controllers, models or views to be fat; this shows laziness, as there's been no thought given to the application's design outside of deciding to use a particular framework.

*<b>Bad Class names</b>: A good class name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of functionality handled.

*<b>Lengthy Definitions</b>: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*<b>Duplicated Code</b>: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Class''': Controllers as per Ruby conventions should be plural.
*'''Using Helper classes''': No class should be containing lot of code, a better practice is to have all active record queries with in the model and in order to keep as much as Ruby code out of the views, helpers are used. Helpers are the only methods you can access, other than instance methods for an instance you have access to.
*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.

==Project Description==

This class creates surveys and records the responses which can be viewed. On submitting the responses, the scores and comments are posted.

<b>Classes :</b> SurveyResponsesController.rb<br>
<b>What it does : </b>Creates surveys, submitting surveys, views responses, posts scores and comments.<br>
<b>What has to be changed : </b>
* Pluralize the class SurveyResponseController to SurveyResponsesController
* Changing declarations of Arrays and Hashes,removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Move active record queries to the model or another class
* Reducing the number of instance variables per action to one

==Modification to Existing Code==

===Pluralize Controller Class===
* A new survey_responses_controller.rb file is added : As per Ruby on Rails convention, controller names get pluralized while model names are singular. So, the controller name becomes survey_responses_controller instead of survey_response_controller for SurveyResponse modelclass.

===Ruby 1.9 standards for Array and Hashes===

*Modified declarations of Arrays and Hashes
Before Refactoring :
survey_responses_controller.rb
<pre>
#view_responses
@responses = Array.new

#view_responses
this_response_survey = Hash.new
</pre>

After Refactoring :
<pre>
#view_responses
@responses = []

#view_responses
this_response_survey = {}
</pre>

===Active Record Queries in Model Class===

Controllers are best at parsing the inputs, they call the appropriate models, and then format the outputs. It is desirable to have a skinny controller responsible for parsing inputs and models doing actual validation. A bunch of Active Record queries that existed in survey_responses_controller have been moved to SurveyResponse model.

Before Refactoring:
survey_responses_controller.rb
<pre>
#view_responses
if !params[:course_eval]
surveylist = SurveyResponse.where( ["assignment_id = ? and survey_id = ?", params[:id], survey.id])
else
surveylist = SurveyResponse.where( ["survey_deployment_id = ? and survey_id = ?", params[:id], survey.id])
</pre>

After Refactoring:
survey_responses_controller.rb
SurveyResponse.get_survey_list and SurveyResponse.get_survey_list_with_deploy_id methods have been created in SurveyResponse model for active record operations.
<pre>
#view_responses
if !params[:course_eval]
survey_list = SurveyResponse.get_survey_list(params[:id], survey.id)
else
survey_list = SurveyResponse.get_survey_list_with_deploy_id( params[:id], survey.id)
</pre>

===Reduce Instance Variables===
It desirable not to have more than one instance variables in a controller action as it indicates increased coupling. Our goal should be reducing coupling as much as possible and view should have direct access to as few instance variables as possible.

Before Refactoring:
survey_responses_controller.rb
<pre>
for question in @questions
@new = SurveyResponse.new
@new.survey_id = @survey_id
@new.question_id = question.id
@new.assignment_id = @assignment_id
@new.survey_deployment_id=params[:survey_deployment_id]
@new.email = params[:email]
@new.score = @scores[question.id.to_s]
@new.comments = @comments[question.id.to_s]
@new.save
end

if !params[:survey_deployment_id]
@surveys = SurveyHelper::get_assigned_surveys(@assignment_id)
end
</pre>

After Refactoring:
survey_responses_controller.rb
<pre>
for question in @questions
SurveyResponseHelper::persist_survey(@survey_id, question.id, @assignment_id, params[:survey_deployment_id], params[:email])
end
if !params[:survey_deployment_id]
surveys = SurveyHelper::get_assigned_surveys(@assignment_id)
end
</pre>

===Using Routing Helpers===
Creation of a resourceful route will also expose a number of helpers to the controllers in the application. We modified the routes.rb file to include all the actions in the controller.

resources :survey_response do
collection do
get :view_responses
get :begin_survey
get :comments
end
end

The resourceful routes generated the helpers given below:

view_responses_survey_response_index_path returns /survey_response/view_responses

begin_survey_survey_response_index_path returns /survey_response/begin_survey

comments_survey_response_index_path returns /survey_response/comments

===Code Clean up===
Comments and extra spaces have been removed and conventions have been followed to enhance readability of the code.

==Testing==
Testing was performed by running 2 different VCL instances one with the original code and the other with the re-factored code. While performing the manual testing we noticed that when new course evaluations are created, the survey participants are random users and participants selection is not based on the courses. However, while displaying the pending course evaluations in the course evaluation list view, the courses are taken into consideration. Because of this difference we were not able to submit survey responses and view them.
In below images we have shown that the output after refactoring and output without re-factoring for all actions in the SurveyResponsesController.

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

|-
| [[File:Begin_survey_refactored.png|500px|frame|left| ]]
| [[File:Begin_survey_original.png|500px|frame|left| ]]
Begin Survey action was broken in the original source code, we made fixes to make the functionality work.
<br />
|-
! View of Re-factored Course Evaluation Survey
! View of Original Course Evaluation Survey
|-
| [[File:course_evaluation.png|500px|frame|left| ]]
| [[File:course_evaluation.png|500px|frame|left| ]]
The Course Evaluation action works as expected after refactoring
<br />
|-
! View of Re-factored View Responses
! View of Original View Responses
|-
| [[File:view_responses_refactored.png|500px|frame|left| ]]
| [[File:view_responses.png|500px|frame|left| ]]
The View Response action was broken and fix is made to display the functionality properly.
<br />
|-
! View of Re-factored Pending Course Evaluations
! View of Original Pending Course Evaluations
|-
| [[File:pending_course_evaluation_refactored.png|500px|frame|left| ]]
| [[File:pending_course_evaluation_refactored.png|500px|frame|left| ]]
Pending course evaluation works as expected after code re-factoring
<br />
|-
! View of Response Comments Re-factored
! View of Original Response Comments Re-factored
|-
| [[File:Response_comments_refactored.png|500px|frame|left| ]]
| [[File:Response_comments_original.png|500px|frame|left| ]]
The action for View Response comments was not routed properly, necessary changes have been made to call the appropriate action
<br />
|}

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/><br>

CSC/ECE 517 Fall 2014/oss E1462 nms

2014-11-06T06:42:14Z

Nmpedema: /* Testing */

=Expertiza - Refactoring SurveyResponsesController=

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is an open source web portal for the use of both students and professors. Expertiza allows us to create reusable learning objects through peer review. It allows project submission, team creation and the submission of almost any document type, including URLs and wiki pages. Students can access their pending and finished assignments, they can do peer reviews on several topics and projects. It is developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code has been forked and cloned for making modifications to the to survey responses controller.

This wiki provides an insight into our contributions to the OSS Expertiza application, focusing on Refactoring the SurveyResponses Controller.

<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.142/:3000
| rowspan="2" | '''username= "user2"<br />password= "password"'''
|-
| '''Original Instance'''
| http://152.46.19.10:3000/
|-
| '''Repository link'''
| colspan="3" | https://github.com/nmpedema/expertiza <ref>[https://github.com/nmpedema/expertiza Forked repository]</ref>
|-
| '''Pull request'''
| colspan="3" | https://github.com/expertiza/expertiza/pull/448 <ref>[https://github.com/expertiza/expertiza/pull/448 Pull request]</ref>
|}
</div>
__TOC__

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*<b>Fat Classes</b>: No class should be fat. Ever. There is no need for your controllers, models or views to be fat; this shows laziness, as there's been no thought given to the application's design outside of deciding to use a particular framework.

*<b>Bad Class names</b>: A good class name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of functionality handled.

*<b>Lengthy Definitions</b>: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*<b>Duplicated Code</b>: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Class''': Controllers as per Ruby conventions should be plural.
*'''Using Helper classes''': No class should be containing lot of code, a better practice is to have all active record queries with in the model and in order to keep as much as Ruby code out of the views, helpers are used. Helpers are the only methods you can access, other than instance methods for an instance you have access to.
*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.

==Project Description==

This class creates surveys and records the responses which can be viewed. On submitting the responses, the scores and comments are posted.

<b>Classes :</b> SurveyResponsesController.rb<br>
<b>What it does : </b>Creates surveys, submitting surveys, views responses, posts scores and comments.<br>
<b>What has to be changed : </b>
* Pluralize the class SurveyResponseController to SurveyResponsesController
* Changing declarations of Arrays and Hashes,removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Move active record queries to the model or another class
* Reducing the number of instance variables per action to one

==Modification to Existing Code==

===Pluralize Controller Class===
* A new survey_responses_controller.rb file is added : As per Ruby on Rails convention, controller names get pluralized while model names are singular. So, the controller name becomes survey_responses_controller instead of survey_response_controller for SurveyResponse modelclass.

===Ruby 1.9 standards for Array and Hashes===

*Modified declarations of Arrays and Hashes
Before Refactoring :
survey_responses_controller.rb
<pre>
#view_responses
@responses = Array.new

#view_responses
this_response_survey = Hash.new
</pre>

After Refactoring :
<pre>
#view_responses
@responses = []

#view_responses
this_response_survey = {}
</pre>

===Active Record Queries in Model Class===

Controllers are best at parsing the inputs, they call the appropriate models, and then format the outputs. It is desirable to have a skinny controller responsible for parsing inputs and models doing actual validation. A bunch of Active Record queries that existed in survey_responses_controller have been moved to SurveyResponse model.

Before Refactoring:
survey_responses_controller.rb
<pre>
#view_responses
if !params[:course_eval]
surveylist = SurveyResponse.where( ["assignment_id = ? and survey_id = ?", params[:id], survey.id])
else
surveylist = SurveyResponse.where( ["survey_deployment_id = ? and survey_id = ?", params[:id], survey.id])
</pre>

After Refactoring:
survey_responses_controller.rb
SurveyResponse.get_survey_list and SurveyResponse.get_survey_list_with_deploy_id methods have been created in SurveyResponse model for active record operations.
<pre>
#view_responses
if !params[:course_eval]
survey_list = SurveyResponse.get_survey_list(params[:id], survey.id)
else
survey_list = SurveyResponse.get_survey_list_with_deploy_id( params[:id], survey.id)
</pre>

===Reduce Instance Variables===
It desirable not to have more than one instance variables in a controller action as it indicates increased coupling. Our goal should be reducing coupling as much as possible and view should have direct access to as few instance variables as possible.

Before Refactoring:
survey_responses_controller.rb
<pre>
for question in @questions
@new = SurveyResponse.new
@new.survey_id = @survey_id
@new.question_id = question.id
@new.assignment_id = @assignment_id
@new.survey_deployment_id=params[:survey_deployment_id]
@new.email = params[:email]
@new.score = @scores[question.id.to_s]
@new.comments = @comments[question.id.to_s]
@new.save
end

if !params[:survey_deployment_id]
@surveys = SurveyHelper::get_assigned_surveys(@assignment_id)
end
</pre>

After Refactoring:
survey_responses_controller.rb
<pre>
for question in @questions
SurveyResponseHelper::persist_survey(@survey_id, question.id, @assignment_id, params[:survey_deployment_id], params[:email])
end
if !params[:survey_deployment_id]
surveys = SurveyHelper::get_assigned_surveys(@assignment_id)
end
</pre>

===Using Routing Helpers===
Creation of a resourceful route will also expose a number of helpers to the controllers in the application. We modified the routes.rb file to include all the actions in the controller.

resources :survey_response do
collection do
get :view_responses
get :begin_survey
get :comments
end
end

The resourceful routes generated the helpers given below:

view_responses_survey_response_index_path returns /survey_response/view_responses
begin_survey_survey_response_index_path returns /survey_response/begin_survey
comments_survey_response_index_path returns /survey_response/comments

===Code Clean up===
Comments and extra spaces have been removed and conventions have been followed to enhance readability of the code.

==Testing==
Testing was performed by running 2 different VCL instances one with the original code and the other with the re-factored code. While performing the manual testing we noticed that when new course evaluations are created, the survey participants are random users and participants selection is not based on the courses. However, while displaying the pending course evaluations in the course evaluation list view, the courses are taken into consideration. Because of this difference we were not able to submit survey responses and view them.
In below images we have shown that the output after refactoring and output without re-factoring for all actions in the SurveyResponsesController.

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

|-
| [[File:Begin_survey_refactored.png|500px|frame|left| ]]
| [[File:Begin_survey_original.png|500px|frame|left| ]]
Begin Survey action was broken in the original source code, we made fixes to make the functionality work.
<br />
|-
! View of Re-factored Course Evaluation Survey
! View of Original Course Evaluation Survey
|-
| [[File:course_evaluation.png|500px|frame|left| ]]
| [[File:course_evaluation.png|500px|frame|left| ]]
The Course Evaluation action works as expected after refactoring
<br />
|-
! View of Re-factored View Responses
! View of Original View Responses
|-
| [[File:view_responses_refactored.png|500px|frame|left| ]]
| [[File:view_responses.png|500px|frame|left| ]]
The View Response action was broken and fix is made to display the functionality properly.
<br />
|-
! View of Re-factored Pending Course Evaluations
! View of Original Pending Course Evaluations
|-
| [[File:pending_course_evaluation_refactored.png|500px|frame|left| ]]
| [[File:pending_course_evaluation_refactored.png|500px|frame|left| ]]
Pending course evaluation works as expected after code re-factoring
<br />
|-
! View of Response Comments Re-factored
! View of Original Response Comments Re-factored
|-
| [[File:Response_comments_refactored.png|500px|frame|left| ]]
| [[File:Response_comments_original.png|500px|frame|left| ]]
The action for View Response comments was not routed properly, necessary changes have been made to call the appropriate action
<br />
|}

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/><br>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T02:28:44Z

Nmpedema: /* Features of Lift Web Framework */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is an open source software licensed under an Apache 2.0 license. Lift 2.5 is the latest stable version released and the Lift community has already started development for Lift 3.0. The source code can be found of the GitHub repository.<ref name=github>[https://github.com/lift/framework Lift Source Code]</ref>
Lift borrows from the best of existing frameworks, providing:
*Seaside’s highly granular sessions and security.
*Rails’s fast flash-to-bang.
*Django’s “more than just CRUD is included”.
*Wicket’s designer-friendly templating style.<ref name=wiki>[https://www.assembla.com/spaces/liftweb/wiki/Home Lift Developers' wiki]</ref>

Lift is built on top of the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules<ref name=liftweb>[http://liftweb.net/ Lift Official HomePage]</ref>

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T02:15:44Z

Nmpedema: /* Background */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is an open source software licensed under an Apache 2.0 license. Lift 2.5 is the latest stable version released and the Lift community has already started development for Lift 3.0. The source code can be found of the GitHub repository.<ref name=github>[https://github.com/lift/framework Lift Source Code]</ref>
Lift borrows from the best of existing frameworks, providing:
*Seaside’s highly granular sessions and security.
*Rails’s fast flash-to-bang.
*Django’s “more than just CRUD is included”.
*Wicket’s designer-friendly templating style.<ref name=wiki>[https://www.assembla.com/spaces/liftweb/wiki/Home Lift Developers' wiki]</ref>

Lift is built on top of the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T02:13:49Z

Nmpedema: /* Background */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is an open source software licensed under an Apache 2.0 license. Lift 2.5 is the latest stable version released and the Lift community has already started development for Lift 3.0. The source code can be found of the GitHub repository.<ref name=github>[https://github.com/lift/framework Lift Source Code]</ref>
Lift borrows from the best of existing frameworks, providing:
*Seaside’s highly granular sessions and security.
*Rails’s fast flash-to-bang.
*Django’s “more than just CRUD is included”.
*Wicket’s designer-friendly templating style.<ref name=github>[https://www.assembla.com/spaces/liftweb/wiki/Home Lift Developers' wiki]</ref>

Lift is built on top of the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T02:13:03Z

Nmpedema: /* Background */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is an open source software licensed under an Apache 2.0 license. Lift 2.5 is the latest stable version released and the Lift community has already started development for Lift 3.0. The source code can be found of the GitHub repository.<ref name=github>[https://github.com/lift/framework Lift Source Code]</ref>
Lift borrows from the best of existing frameworks, providing:
*Seaside’s highly granular sessions and security.
*Rails’s fast flash-to-bang.
*Django’s “more than just CRUD is included”.
*Wicket’s designer-friendly templating style.<ref name=github>[https://www.assembla.com/spaces/liftweb/wiki/Home Lift Developers' wiki]

Lift is built on top of the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T02:09:23Z

Nmpedema: /* Background */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is an open source software licensed under an Apache 2.0 license. Lift 2.5 is the latest stable version released and the Lift community has already started development for Lift 3.0. The source code can be found of the GitHub repository.
Lift borrows from the best of existing frameworks, providing:
*Seaside’s highly granular sessions and security
*Rails’s fast flash-to-bang
*Django’s “more than just CRUD is included”
*Wicket’s designer-friendly templating style
Lift is built on top of the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:52:26Z

Nmpedema: /* Lift Web Framework */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:52:10Z

Nmpedema: /* Features of Lift Web Framework */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:35:55Z

Nmpedema: /* Introduction */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=explore>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:27:14Z

Nmpedema: /* Introduction */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLodading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:24:09Z

Nmpedema: /* Introduction */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing."

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLodading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:22:18Z

Nmpedema: /* Introduction */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture.
Strong, expressive typing and higher-level features like the built-in Comet support allow you to
focus on innovating instead of the plumbing."

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLodading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:21:41Z

Nmpedema: /* Introduction */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level features like the built-in Comet support allow you to focus on innovating instead of the plumbing."

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLodading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:14:09Z

Nmpedema: /* Introduction */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLodading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T01:10:55Z

Nmpedema:

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a powerful web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of the novel ideas. The combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework

==Background==
Lift is designed to leverage the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

==Features of Lift Web Framework ==
* '''LazyLodading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T00:31:50Z

Nmpedema:

WEB DEVELOPMENT USING LIFT

==Features of Lift ==
* '''LazyLodading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-20T00:26:13Z

Nmpedema:

WEB DEVELOPMENT USING LIFT

==Features of Lift ==
# LazyLodading: Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

# Parallel Page rendering: Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

# Comet and Ajax support: Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

# Wiring: The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

# Security: Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, XSS, Direct Object references and URL access

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# ORM: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Built on Scala which is a powerful functional language.
# Multiple Component support : Divides the controls into snippets which can be used together on a single page thereby not coupling a page with a controller.
# CSS Binding : allows to navigate the HTML Dom tree.
# Native Javascript/Ajax Support
# Out-of-box Security.
# Lazy Loading & Parallel Page rendering : Lift shows automatic spinners on area still being loaded, components are able to load over multiple thread at the same time.<ref name=benefits>[http://blog.fliptop.com/blog/2013/03/10/why-lift-webframework-is-my-favorite/ Why Lift Webframework is my favorite.]</ref>

== Disadvantages ==
# Lots of state kept in session.
# Learning Curve as no more MVC.
<ref name=quora>[http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-application-in-Scala-using-Lift Comparison on Quora]</ref>

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-16T17:00:39Z

Nmpedema: Created page with "WEB DEVELOPMENT USING LIFT"

WEB DEVELOPMENT USING LIFT

CSC/ECE 517 Fall 2014

2014-09-16T16:59:14Z

Nmpedema:

*[[CSC/ECE_517_Fall_2014/sample_page]]
*[[CSC/ECE_517_Fall_2014/ch1a 22 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 19 mx]]
*[[CSC/ECE 517 Fall 2014/ch1a 3 zq]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 lf]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 wl]]
*[[CSC/ECE 517 Fall 2014/ch1a a7 ch]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 jf]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 os]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 15 gs]]
*[[CSC/ECE 517 Fall 2014/ch1a 10 hu]]
*[[CSC/ECE 517 Fall 2014/ch1a 10 kv]]
*[[CSC/ECE 517 Fall 2014/ch1a 21 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 21 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 26 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 6 rl]]
*[[CSC/ECE 517 Fall 2014/ch1a 2 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 16 av]]

CSC/ECE 517 Fall 2014

2014-09-16T16:58:26Z

Nmpedema:

*[[CSC/ECE_517_Fall_2014/sample_page]]
*[[CSC/ECE_517_Fall_2014/ch1a 22 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 19 mx]]
*[[CSC/ECE 517 Fall 2014/ch1a 3 zq]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 lf]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 lf]]
*[[CSC/ECE 517 Fall 2014/ch1a a7 ch]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 jf]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 os]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 15 gs]]
*[[CSC/ECE 517 Fall 2014/ch1a 10 hu]]
*[[CSC/ECE 517 Fall 2014/ch1a 10 kv]]
*[[CSC/ECE 517 Fall 2014/ch1a 21 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 21 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 26 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 6 rl]]
*[[CSC/ECE 517 Fall 2014/ch1a 2 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 16 av]]