mv docs doc

13 files changed, 1051 insertions, 0 deletions

diff --git a/doc/.gitignore b/doc/.gitignore
new file mode 100644
index 0000000..ed193ea
--- /dev/null
+++ b/doc/.gitignore
@@ -0,0 +1,4 @@
+*.pdf
+*.html
+*.png
+!stickman.png
diff --git a/doc/DesignDocument-architecture-model2.pptx b/doc/DesignDocument-architecture-model2.pptx
new file mode 100644
index 0000000..1a1a08a
--- /dev/null
+++ b/doc/DesignDocument-architecture-model2.pptx
diff --git a/doc/DesignDocument-classes.dot b/doc/DesignDocument-classes.dot
new file mode 100644
index 0000000..cccc477
--- /dev/null
+++ b/doc/DesignDocument-classes.dot
@@ -0,0 +1,265 @@
+digraph systemModel {
+	rankdir="LR";
+	splines="line";
+
+	subgraph _clusterModels {
+		label="Models"
+		node[shape="record"];
+
+		//BaseModel[label="<main> ActiveRecord::Base (abstract)"]
+
+		Server[label="<main> Server"];
+		Tournament[label="<main> Tournament"];
+		Match[label="<main> Match"];
+		Team[label="<main> Team"];
+		User[label="<main> User | <attr_role> role | <attr_pw> password hash"];
+	}
+
+	subgraph _clusterViews {
+		label="views/";
+		node[shape="rectangle"]
+
+		/*
+		layouts_application[label="layouts/application (abstract)"]
+		subgraph clusterViewsCommon {
+			label="views/common/";
+			common_permission_denied[label="common/permission_denied"];
+			common_invalid[label="common/invalid"];
+		}
+		*/
+		subgraph clusterViewsMain {
+			label="views/main/";
+			main_homepage[label="main/homepage"];
+			main_edit[label="main/edit"];
+		}
+		search_results[label="search/results"];
+		subgraph clusterViewsMessages {
+			label="views/messages/";
+			messages_new_alert[label="messages/new_alert"];
+			messages_private[label="messages/private"];
+		}
+		subgraph clusterViewsTournament {
+			label="views/tournament/";
+			tournaments_index[label="tournaments/index"];
+			tournaments_show[label="tournaments/show"];
+			tournaments_new[label="tournaments/new"];
+			tournaments_edit[label="tournaments/edit"];
+		}
+		subgraph clusterViewsMatches {
+			label="views/matches/";
+			matches_show[label="matches/show"];
+			matches_edit[label="matches/edit"];
+		}
+		subgraph clusterViewsTeams {
+			label="views/teams/";
+			teams_index[label="teams/index"];
+			teams_show[label="teams/show"];
+			teams_new[label="teams/new"];
+			teams_edit[label="teams/edit"];
+		}
+		subgraph clusterViewsUsers {
+			label="views/users/";
+			users_index[label="users/index"];
+			users_new[label="users/new"];
+			users_show[label="users/show"];
+			users_edit[label="users/edit"];
+		}
+	}
+
+	subgraph _clusterControllers {
+		label="Controllers";
+		node[shape="record"];
+
+		//ApplicationController[label="<main> ApplicationController (abstract)"];
+
+		MainController[label="<main> MainController | <index> show_homepage() | <edit> edit_settings() | <update> update_settings()"];
+		LoginController[label="<main> LoginController | <login> login() | <logout> logout()"];
+		SearchController[label="<main> SearchController | <show_results> show_results()"];
+		MessagesController[label="<main> MessagesController | <new_alert> new_alert() | <post_alert> post_alert() | <show_private> show_private() | <post_private> post_private()"];
+		TournamentsController[label="<main> TournamentsController | <index> index() | <show> show() | <new> new() | <create> create() | <edit> edit() | <update> update() | <end> end()"];
+		MatchesController[label="<main> MatchesController | <index> index() | <show> show() | <edit> edit() | <update> update()"];
+		TeamsController[label="<main> TeamsController | <index> index() | <show> show() | <edit> edit() | <update> update()"]
+		UsersController[label="<main> UsersController | <index> index() | <show> show() | <new> new() | <create> create() | <edit> edit() | <update> update() | <delete> delete()"]
+	}
+
+	/*
+	subgraph inheritance {
+		# Kludge: Have a arrow going both ways, but one invisible, so
+		# that it doesn't try to force a position
+
+		# models
+
+		Server:main -> BaseModel[arrowhead=onormal];
+		BaseModel -> Server:main[style=invis];
+
+		Tournament:main -> BaseModel[arrowhead=onormal];
+		BaseModel -> Tournament:main[style=invis];
+
+		Match:main -> BaseModel[arrowhead=onormal];
+		BaseModel -> Match:main[style=invis];
+
+		Team:main -> BaseModel[arrowhead=onormal];
+		BaseModel -> Team:main[style=invis];
+
+		User:main -> BaseModel[arrowhead=onormal];
+		BaseModel -> User:main[style=invis];
+
+		# views
+
+		common_permission_denied -> layouts_application[arrowhead=onormal];
+		layouts_application -> common_permission_denied[style=invis];
+
+		common_invalid -> layouts_application[arrowhead=onormal];
+		layouts_application -> common_invalid[style=invis];
+
+		main_homepage -> layouts_application[arrowhead=onormal];
+		layouts_application -> main_homepage[style=invis];
+
+		main_edit -> layouts_application[arrowhead=onormal];
+		layouts_application -> main_edit[style=invis];
+
+		messages_new_alert -> layouts_application[arrowhead=onormal];
+		layouts_application -> messages_new_alert[style=invis];
+
+		messages_private -> layouts_application[arrowhead=onormal];
+		layouts_application -> messages_private[style=invis];
+
+		tournaments_index -> layouts_application[arrowhead=onormal];
+		layouts_application -> tournaments_index[style=invis];
+
+		tournaments_show -> layouts_application[arrowhead=onormal];
+		layouts_application -> tournaments_show[style=invis];
+
+		tournaments_new -> layouts_application[arrowhead=onormal];
+		layouts_application -> tournaments_new[style=invis];
+
+		tournaments_edit -> layouts_application[arrowhead=onormal];
+		layouts_application -> tournaments_edit[style=invis];
+
+		matches_show -> layouts_application[arrowhead=onormal];
+		layouts_application -> matches_show[style=invis];
+
+		matches_edit -> layouts_application[arrowhead=onormal];
+		layouts_application -> matches_edit[style=invis];
+
+		teams_index -> layouts_application[arrowhead=onormal];
+		layouts_application -> teams_index[style=invis];
+
+		teams_show -> layouts_application[arrowhead=onormal];
+		layouts_application -> teams_show[style=invis];
+
+		teams_new -> layouts_application[arrowhead=onormal];
+		layouts_application -> teams_new[style=invis];
+
+		teams_edit -> layouts_application[arrowhead=onormal];
+		layouts_application -> teams_edit[style=invis];
+
+		users_index -> layouts_application[arrowhead=onormal];
+		layouts_application -> users_index[style=invis];
+
+		users_new -> layouts_application[arrowhead=onormal];
+		layouts_application -> users_new[style=invis];
+
+		users_show -> layouts_application[arrowhead=onormal];
+		layouts_application -> users_show[style=invis];
+
+		users_edit -> layouts_application[arrowhead=onormal];
+		layouts_application -> users_edit[style=invis];
+
+		# controllers
+
+		MainController:main -> ApplicationController[arrowhead="onormal"];
+		ApplicationController -> MainController:main[style=invis];
+
+		TournamentsController:main -> ApplicationController[arrowhead="onormal"];
+		ApplicationController -> TournamentsController:main[style=invis];
+
+		MessagesController:main -> ApplicationController[arrowhead="onormal"];
+		ApplicationController -> MessagesController:main[style=invis];
+
+		LoginController:main -> ApplicationController[arrowhead="onormal"];
+		ApplicationController -> LoginController:main[style=invis];
+
+		SearchController:main -> ApplicationController[arrowhead="onormal"];
+		ApplicationController -> SearchController:main[style=invis];
+
+		UsersController:main -> ApplicationController[arrowhead="onormal"];
+		ApplicationController -> UsersController:main[style=invis];
+
+		MatchesController:main -> ApplicationController[arrowhead="onormal"];
+		ApplicationController -> MatchesController:main[style=invis];
+	}
+	*/
+
+	###################################################################
+	# controller/view relations
+	###################################################################
+	MainController:index -> main_homepage;
+	MainController:edit -> main_edit -> MainController:update -> main_edit;
+
+	#LoginController:login -> common_permission_denied;
+	#LoginController:logout -> common_invalid;
+
+	SearchController:show_results -> search_results;
+
+	MessagesController:new_alert -> messages_new_alert -> MessagesController:post_alert;
+	MessagesController:show_private -> messages_private -> MessagesController:post_private -> messages_private;
+
+	TournamentsController:index -> tournaments_index;
+	TournamentsController:show -> tournaments_show;
+	TournamentsController:new -> tournaments_new -> TournamentsController:create -> tournaments_edit -> TournamentsController:end;
+	TournamentsController:edit -> tournaments_edit -> TournamentsController:update -> tournaments_edit;
+
+	MatchesController:show -> matches_show;
+	MatchesController:edit -> matches_edit -> MatchesController:update -> matches_edit;
+
+	TeamsController:index -> teams_index;
+	TeamsController:show -> teams_show;
+	TeamsController:edit -> teams_edit -> TeamsController:update -> teams_edit;
+
+	UsersController:index -> users_index;
+	UsersController:show -> users_show;
+	UsersController:new -> users_new -> UsersController:create -> users_edit -> UsersController:delete;
+	UsersController:edit -> users_edit -> UsersController:update -> users_edit;
+
+	###################################################################
+	# controller/model relations
+	###################################################################
+	Server:main -> MainController:edit;
+	MainController:update -> Server:main;
+
+	User:main -> LoginController:login;
+
+	Tournament:main -> SearchController:show_results;
+	Match:main -> SearchController:show_results;
+	Team:main -> SearchController:show_results;
+	User:main -> SearchController:show_results;
+
+	Tournament:main -> TournamentsController:index;
+	Tournament:main -> TournamentsController:show;
+	Match:main -> TournamentsController:show;
+	Tournament:main -> TournamentsController:edit;
+	TournamentsController:create -> Tournament:main;
+	TournamentsController:update -> Tournament:main;
+	TournamentsController:end -> Tournament:main;
+
+	Match:main -> MatchesController:index;
+	Match:main -> MatchesController:show;
+	Team:main -> MatchesController:show;
+	User:main -> MatchesController:show;
+	Match:main -> MatchesController:edit;
+	MatchesController:update -> Match:main;
+
+	Team:main -> TeamsController:index;
+	Team:main -> TeamsController:show;
+	User:main -> TeamsController:show;
+	Team:main -> TeamsController:edit;
+	TeamsController:update -> Team:main;
+
+	User:main -> UsersController:index;
+	User:main -> UsersController:show;
+	User:main -> UsersController:edit;
+	UsersController:create -> User:main;
+	UsersController:update -> User:main;
+	UsersController:delete -> User:main;
+}
diff --git a/doc/DesignDocument-models.pptx b/doc/DesignDocument-models.pptx
new file mode 100644
index 0000000..e689a7c
--- /dev/null
+++ b/doc/DesignDocument-models.pptx
diff --git a/doc/DesignDocument.md b/doc/DesignDocument.md
new file mode 100644
index 0000000..45f6d5f
--- /dev/null
+++ b/doc/DesignDocument.md
@@ -0,0 +1,475 @@
+---
+title: "Project Leaguer: Design Document"
+author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumaker, Davis Webb ]
+---
+
+Version 1.0 – 2014.02.10
+
+# Purpose
+
+The purpose of this document is to outlay the design, intent, and structure of
+the Project Leaguer tournament organizing software.
+
+Released under an open license, Project Leaguer leverages powerful web
+technologies to provide everything needed to organize an online
+tournament.  While it is designed with “League of Legends” in mind, it
+should provide an online tournament interface that is easy to use for
+tournament organizers, participants, and spectators for all kinds of
+games, such as Chess, Poker, and more.  Even better, Project Leaguer
+offers scoring features and options, such as peer review and
+team-independent individual scoring, which would be very difficult to
+implement with traditional tournament organizing practices.
+
+The software itself operates as a stand-alone background server application
+accessible and configurable though its web interface which reveals to users a 
+sleek web application which manages tournaments.
+ 
+# Non-Functional Requirements
+
+Security
+  : Because Project Leaguer servers may store sensitive user
+    information like name, email, statistics, user-name, profile,
+    etc. it is an important non-functional requirement that such data
+    is well secured from both accidental exposure and intentional
+    tampering.  Even so, the System may not be responsible for the
+    theft of user information or even alterations made to the database
+    from a source different from that of Leaguer.
+
+Platform Compatibility
+  : A non-functional requirement for the system is to be able to run
+    on multiple platforms.  Primarily a web based application, Leaguer
+    may not be able to install into embedded gaming devices and
+    special operation systems that do not run the interface that
+    Leaguer was initially built on.
+
+Response Time
+  : Even though the "Model 2" architecture tends to scale well for
+    medium/large applications and data sets, it is still important to
+    keep the response time of the system in mind.  Using efficient data
+    structures, short time complexity algorithms, and minimizing
+    network overhead whenever possible will help to keep the response
+    time of the system reasonable even for large data sets or complex
+    statistics or scoring schemes.
+
+
+# Design Outlines
+
+## Design Decisions and Components
+
+Project Leaguer is written on the Ruby on Rails platform and will use
+the “Model 2” (often mis-identified as “MVC”) design
+pattern/architecture.  This architecture is comprised of three
+interacting components: Controllers, Views, and Models.
+
+![](DesignDocument-architecture-model2.pdf)\ 
+
+Controllers
+  : Requests received by the server are processed by a routing
+    subroutine and directed to a controller responsible for handling
+    them. Controllers accept these requests and manage any logic
+    necessary to obtain the correct content for display, retrieving
+    and updating information from the Model as needed.  It then
+    creates a new request, places the content from the model in the
+    request (if applicable), decides which view it will be passed to,
+    and passes on the request.
+
+Models
+  : In Ruby on Rails, models are usually implemented as an interface
+    to a table in the database and a Ruby file which queries this
+    table and interacts with the other components.  For example, a
+    "user" model would be connected to the "user" table and a file
+    "user.rb" in the app/models directory would provide an interface
+    to interact with the "user" controller.
+
+Views
+  : Views will primarily be dynamically generated HTML pages and will
+    display the users desired content inside of the web browser. These
+    may be implemented with inline Ruby scripts and tags within
+    traditional HTML.
+
+## Component Interaction
+
+Controllers will be used to run all of the background work of Leaguer.  They will fetch the necessary data and will tell the view what to do.  We will be implementing eight controllers into Leaguer.  Those will be:
+
+   i. PM & Alerts – This controller will be used for sending and receiving private messages to and from the host.  Players will be able to message the host in order to inform him/her of anything during the tournament.  This will also allow the host to post any notifications he or she desires that will be displayed for all to see.
+  ii. Settings & Homepage – Used to handle the homepage.  This will be the first web page seen by any user of the application.
+ iii. Login – This controller will be used when a user attempts to sign in to their profile on Leaguer.
+  iv. Search – This controller will be used to search the web-base for on going tournaments, players and past tournaments.
+   v. Tournament – Used for setting up a tournament.  This will be restricted to the host of the tournament.
+  vi. User – The controller that will take each user to their own profile.
+ vii. Match/Peer Review – used for gather game statistics and the separate player reviews.
+viii. Teams - This controller will be used to handle the separate teams.  It will contain: a list of the team's members and will be used to handle team roster modifications. 
+
+Each of these controllers will fetch the data specified by its separate section.  The view will then be used to display all of this information, so Login will take the user to a login page, search will take the user to a search page and so on.
+
+The Model will be the data section that will map all of the information to their proper locations in the data base.
+
+# Design Issues
+ 
+## Scoring Algorithm
+
+In an effort to keep our system broad, one of our requirements is that Leaguer is adaptable to many competitions, not just League of Legends. How do we assure that the different scoring systems of different sports are represented in Leaguer?
+
+Option 1
+  : One of our interfaces could be “Scoring System” which will be
+    implemented by many classes with common scoring systems. For
+    example there would be a implementing class in which the highest
+    score wins, and one in which the lowest score wins. This is likely
+    to be the winning option, as there are not too many obscure
+    scoring systems that we could not think of.
+
+Option 2
+  : We could design an API in which the host writes a method to update
+    the scoring. This is pretty complex, and while it would allow more
+    customization, it is hard to imagine completing this task without
+    first completing option 1.
+
+## Offline Data Management
+
+Leaguer manages players and games within tournaments, but it also stores statistics about the games and players themselves.  We need a system to store this information after the server-host shuts down the server.
+
+Option 1
+  : Perhaps the simplest and most intuitive option is to implement a
+    database dump system. The server would dump the information into
+    an SQL format.  All game and player data would be stored to the
+    host and could be restored to a new server. The host would be
+    responsible for preserving the data.  Additional security measures
+    could be implemented to help protect data.  This option leaves the
+    users with great control over the data.
+
+Option 2
+  : We could host Leaguer ourselves with our own server. All users
+    would connect to it instead of to a user-hosted server.  Game and
+    player information would be stored and maintained on Leaguer's
+    server and the users would not need to manage data themselves, but
+    instead we would have to host the service.
+
+## Fetching Data from Games
+
+Obtaining the statistics from the end of game or match is a vital step in Leaguer's function.  A quick and easy method for obtaining this information will ensure smooth usability.
+
+Option 1
+  : In the case of online multiplayer games, such as League of
+    Legends, it may be possible to obtain the information directly
+    from the game-hosted server or even websites that already do so.
+    In the case of League of Legends, `lolking.net` and `lolnexus.com`
+    already grab statistics from the server automatically.  There are
+    also some open source projects, such as data-hut on GitHub, that
+    could be used to help extract and categorize the data itself. This
+    option is complex, but also highly desirable for compatible games,
+    as it ensures a fast and simple environment for our users.
+
+Option 2
+  : Users manually enter the data themselves. Different games would
+    require different methods for the users to implement.  In the case
+    of online games, users could take screenshot of a match's score
+    screen (and then the statistics would be manually entered in), or
+    a select pool of users could be responsible for recording the
+    information and then entering it in.  This option is tedious and
+    undesirable.
+
+Option 3
+  : Use Optical Character Recognition to obtain statistics from score
+    screen screenshots. This option would require someone to take a
+    screenshot in each match and submit it to Leaguer.  This would
+    require more work than Option 1, but much less than Option 2.  An
+    OCR plugin would have to be implemented for each game and thus
+    support would be limited from game to game. Outside contributors
+    could help widen the number of games with OCR support.
+
+# Design Details
+## Class Descriptions and Interactions
+
+### MODELS
+
+![](DesignDocument-models.pdf)\ 
+
+ActiveRecord::Base (abstract)
+  : The abstract model that all other models inherit from.
+
+Server
+  : Server model providing access to system settings such as Language, Time_Zone, Server_name, Owner_name, and Version. This class is edited and read by the MainController.
+
+Tournament
+  : This model represents the structure of a tournament.  It will have several data sections to it including:  The match settings, the matches contained inside of the tournament, a unique id for the tournament, and the registered players that are participating in the tournament. This class interacts with a multitude of other model classes (see UML) and all four tournament controllers.
+
+Match
+  : A match will be a single set of data that contains all of the statistics of one game.  This includes: players personal scores, team members, scores for each team, game time, the tournament that match took place in, and the date. This model interacts with the match controller, and is both a part of and has a many to one relationship with a tournament object.
+
+Team
+  : This model will consist of a list of players for a tournament. The team creation process is chosen by the host of the tournament and team setup will either be pre-determined teams or randomly assigned teams. This model interacts with the tournament model class.
+
+User
+  : This model represents all types of users; hosts, players, and
+    spectators.  These roles are identified by a “role” attribute. The user is an object that is often referenced by other classes, including tournament, match, and team.
+
+### VIEWS
+
+Asynchronous JavaScript may be used to load one view inside of
+another.  From the core architecture, this does not matter, as the
+same HTTP requests are made, though the user interaction is a little
+cleaner.
+
+layouts/application.html (abstract)
+  : An abstract HTML file, that contains the basic page layout that
+    all other views inherit.  If a user is not logged in, it contains
+    a login form, and a registration button.  The form causes a POST
+    to `LoginController#login()`, and the button causes a GET to
+    `UserController#new()`.  If a user is logged in, it displays a
+    logout button that causes a POST to `LoginController#logout()`.
+    It may contain an alert box of recent alerts submitted by a
+    tournament host.  It contains a search form that is POSTed to
+    `SearchController#show_results`.  If the user is authorized to
+    publish alerts, it also contains a button that causes the browser
+    to GET `MessagesController#new_alert()`.
+
+common/permission_denied.html
+  : A generic page for when a user attempts to do something for which
+    they don't have authorization.
+
+common/invalid.html
+  : A generic page for handling invalid requests (such as logging out
+    when not logged in).
+
+main/homepage.html
+  : This page is visually simple.  In addition to the basic functions
+    of `layouts/application`, this page has a “Go to Tournament” text
+    area, in which you enter a tournament title, and will take you to
+    the relevant tournament page.
+
+main/edit.html
+  : This page is a form for editing the server-wide configuration,
+    such as the language or the graphical theme.  The form is
+    submitted to `MainController#update()`.
+
+search/results.html
+  : Shows the results of a search.  Each item is clickable and
+    triggers a GET request to the relevant controller method.
+
+messages/new_alert.html
+  : This is a form for a host to submit a new system-wide alert.  The
+    form is POSTed to `MessagesController#post_alert()`.
+
+messages/private.html
+  : This page is used to handle user private messaging.  It both
+    displays private messages, and contains a form for sending a new
+    private message.  New messages are POSTed to
+    `MessageController#post_private()`
+
+tournaments/index.html
+  : Shows a list of tournaments.  Clicking on any of them causes the
+    browser GET that tournament via `TournamentController#show()`.  If
+    the user is authorized, it also contains a button that causes the
+    browser to GET `TournamentsController#new()`.
+
+tournaments/show.html
+  : Shows the information for a single tournament.  If the user is
+    authorized, it also shows an “edit” button that triggers a the
+    browser to GET `TournamentsController#edit()`.  This is a
+    tree-like display of matches, where each match consists of a pair
+    of teams. All users can click on a match to go to that match’s
+    page.  Host can see a gear on top left corner that represents
+    tournament settings, it will GET `TournamentsController#edit()`.
+    There will be an “end” button that will redirect to back to the
+    homepage after POSTing to `TournamentsController#end()`.
+
+tournaments/new.html
+  : A form for creating a new tournament.  The form is POSTed to
+    `TournamentsController#create()`.
+
+tournaments/edit.html
+  : A form for editing an existing tournament.  The form is POSTed to
+    `TournamentsController#update()`.
+
+matches/index.html
+  : Shows a list of matches.  Clicking on any of them causes the
+    browser to GET that match via `MatchesController#show()`.
+
+matches/show.html
+  : Shows an individual match; a display of both teams. Each team's
+    players are clickable which causes a GET for the player's profile
+    HTML (`UsersController#show()`).  A link above both teams will GET
+    the tournament the match belongs to
+    (`TournamentsController#show()`).  If the user is authorized, it
+    also has a button to edit the match by GETting
+    `MatchesController#edit()`.
+
+matches/edit.html
+  : Shows a form to edit a match.  The form is POSTed to
+    `MatchesController#update()`.  After a match has been completed,
+    this included peer-review input by the players.
+
+teams/index.html
+  : Shows a list of teams.  Clicking any of them causers the browser
+    to GET that team via `TeamsController#show()`.
+
+teams/show.html
+  : Show an individual team, including statistics, and links to
+    individual members (GET `UsersController#show()`).  If the user is
+    authorized, it also has a button do edit the team by GETting
+    `TeamsController#edit()`.
+
+teams/edit.html
+  : A form to manually edit a team, and its members.  The form
+    contents are POSTed to `TeamsController#update()`.
+
+users/index.html
+  : Show a list of users.  Clicking any of them causers the browser
+    to GET that user via `UsersController#show()`.
+
+users/new.html
+  : Shows a form for creating a new user.  It includes fields for
+    username, email, password, and other information.  The form is
+    POSTed to `UsersController#create()`;
+
+users/show.html
+  : A page with the user's information. One can view the player's
+    reviews.  If the user is authorized, it also has a button do edit
+    the user by GETting `UsersController#edit()`.
+
+users/edit.html
+  : A form to edit a user; including meta-data and tournament
+    registration.  The form is POSTed to `UsersController#update()`.
+
+### CONTROLLERS
+
+Any time "assuming the user has permission" it is mentioned, if the
+user doesn't have permission, it renders the
+`common/permission_denied` view.  This also means that the method
+interacts with a `User` model to evaluate the permissions.
+
+ApplicationController (abstract)
+  : The base controller class that all other controllers inherit from.
+
+MainController
+  : This is the main controller. It has the following methods:
+
+    - `show_homepage()` Responds to GET requests by rendering the
+      `main/homepage` view.
+    - `edit_settings()` Responds to GET requests by (if the user is
+      authenticated and is a host) rendering the `main/edit` view that
+      presents the user with a form to edit the `Server` model's
+      settings; assuming the user has permission.
+    - `update_settings()` Responds to POST requests by updating the
+      `Server` model configuration with the POSTed settings.  It then
+      renders the `main/edit` view with the updated settings.  This
+      assumes the user has the permissions.
+
+LoginController
+  : This controller handles session management.  It contains two
+    methods:
+
+    - `login()` Responds to POST requests by setting a session token
+      identifying the user.  If the credentials are correct, it sends
+      a redirect that directs the browser to the page it would
+      otherwise be on.  If the credentials are not correct, it renders
+      the `common/permission_denied` view.  This queries the `User`
+      model to validate the username and password.
+    - `logout()` Responds to POST requests by clearing the session
+      token, logging the user out, then redirects to the home page
+      (`MainController#show_homepage()`).  If the user was not logged in,
+      it renders the `common/invalid` view.
+
+SearchController
+  : This controller handles user search terms. It has one method:
+
+    - `show_results()` Responds to POST by accessing whichever model(s)
+      contains the information requested and renders the `search/results` view.
+
+MessagesController
+  : This controller handles inter-user messages.  It has a couple
+    methods that respond to GET requests:
+
+    - `new_alert()` Renders the `messages/new_alert` template,
+      assuming the user has permission.
+    - `show_private()` Renders the `messages/private template,
+      assuming the user has permission.
+
+    It also has methods that respond to POST requests:
+
+    - `post_alert()` Publishes a new system-wide alert, assuming the
+      user has permission.  It then redirects the browser to whichever
+      page it would otherwise be on.
+    - `post_private()` Sends a new private message, assuming the user
+      has permission.
+
+TournamentsController
+  : The following methods respond to GET requests by rendering the
+    `tournaments/*` view with the same name:
+
+    - `index()`
+    - `show()`
+    - `new()` (assuming the user has permission)
+    - `edit()` (assuming the user has permission)
+
+    The following methods respond to POST requests, assuming the user
+    has permission:
+
+    - `create()` Creates a new `Tournament` with the POSTed data.
+      Then renders the `tournaments/show` view.
+    - `update()` Updates the specified `Tournament` with the POSTed
+      data.  Then renders the `tournaments/edit` view.
+    - `end()` Ends the specified `Tournament`.  Then redirects to
+      `MainController#show_hompage()`.
+
+    All of these methods will interact with the `Tournament` model,
+    and all of its fields including users matches and
+    TournamentSettings.
+
+MatchesController
+  : The following methods respond to GET requests by rendering the
+    `matches/*` view with the same name:
+
+    - `index()`
+    - `show()`
+    - `edit()`
+
+    The following methods respond to POST requests, assuming the user
+    has permission:
+
+    - `update()` Updates the specified `Match` with the POSTed data.
+
+TeamsController
+  : The following methods respond to GET requests by rendering the
+    `teams/*` view with the same name:
+
+    - `index()`
+    - `show()`
+    - `edit()`
+
+    The following methods respond to POST requests, assuming the user
+    has permission:
+
+    - `update()` Update the specified `Team` with the POSTed data.
+
+UsersController
+  : The following methods respond to GET requests by rendering the
+    `users/*` view with the same name:
+
+    - `index()`
+    - `show()`
+    - `new()`
+    - `edit()`
+
+    The following methods respond to POST requests, assuming the user
+    has permission:
+
+    - `create()` Creates a new `User` with the POSTed data.
+    - `update()` Update the specified `User` with the POSTed data.
+    - `delete()` Deletes the specified `User` account.
+
+## UML Diagram of Classes
+
+This diagram does not show all models inheriting from
+`ActiveRecord::Base`, all views inheriting from `layouts/application`,
+or all controllers inheriting from `ApplicationController`.  It
+does not show interactions with the `User` model that solely check
+authorization to perform an action.  It does not show controller
+methods calling the error views.  It shows transitions from a view to
+a controller *only* when that is the *primary* purpose of the view; many
+workflows can be interrupted at any time.  Arrows between models and
+controllers indicate which direction data is flowing.  Any data
+flowing from a model to the method of a controller is implicitly
+passed to the view that method renders.
+
+![](DesignDocument-classes.pdf)\ 
diff --git a/doc/Diagram01.jpg b/doc/Diagram01.jpg
new file mode 100644
index 0000000..0c85216
--- /dev/null
+++ b/doc/Diagram01.jpg
diff --git a/doc/Makefile b/doc/Makefile
new file mode 100644
index 0000000..469b1a2
--- /dev/null
+++ b/doc/Makefile
@@ -0,0 +1,26 @@
+docs = $(patsubst %.md,%,$(wildcard *.md))
+
+pdf: $(addsuffix .pdf,$(docs))
+html: $(addsuffix .html,$(docs))
+
+%.pdf: %.md Makefile
+	pandoc $($@.args) -s $< -o $@
+%.html: %.md Makefile
+	pandoc -s $< -o $@
+%.png: %.dot Makefile
+	dot -Tpng < $< > $@
+%.pdf: %.dot Makefile
+	dot -Tpdf < $< > $@
+%.pdf: %.pptx Makefile
+	soffice --headless --convert-to pdf $<
+
+ProductBacklog.pdf: SystemModel.png
+SystemModel.png: stickman.png
+
+DesignDocument.pdf: DesignDocument-architecture-model2.pdf  DesignDocument-models.pdf DesignDocument-classes.pdf
+DesignDocument.pdf.args = --table-of-contents --number-sections -f markdown+definition_lists
+
+clean:
+	rm -f -- *.pdf *.html
+
+.DELETE_ON_ERROR:
diff --git a/doc/ProductBacklog.md b/doc/ProductBacklog.md
new file mode 100644
index 0000000..59b5e11
--- /dev/null
+++ b/doc/ProductBacklog.md
@@ -0,0 +1,89 @@
+---
+title: Team 6 - Leaguer
+author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumaker, Davis Webb ]
+---
+
+Problem Statement
+-----------------
+
+In team-based tournament sports, often individual contributions are
+overshadowed by the binary end result: win or lose.  This
+winner-takes-all mentality may unfairly pair players in later stages
+of the tournament based on the team's score rather than their own in
+early stages.
+
+
+Background
+----------
+
+Generally, new team based competitions have been managed
+electronically using archaic methods.  The winning team advances and
+the losing team is defeated.  In the real world there are many
+examples of individual review (as in football) and handicaps (as in
+golf).  Our goal is to create software that allows teams to compete
+and review their peers to more accurately represent modern team
+competitions.  Our domain is online competition management and
+e-sports.  The targeted audience is defined on two levels, on a broad
+level it is for any individual wishing to manage a competitive event,
+on a niche level it is for individuals looking to manage and
+participate in team competitions (like League of Legends).
+
+All existing solutions that we found were limited by the binary
+win/lose.  Several open-souce options exist, which we could possibly
+extend.
+
+The most prominent of these is "XDojo". It has not been modified in
+roughly two years, but has been used for several national
+tournaments.  Unfortunately, the documentation is not in English.
+Because of this, evaluating it for possible adaptation is at the very
+least, a spike.
+
+Another current offering is "OMGT" (Open Manager for Game
+Tournaments).  It seems to be reasonably well developed and stable,
+though the install process is mostly undocumented, and while probably
+not very complex, we haven't figured it out yet.
+
+The third current open source offering looked at was "tournamentmngr",
+which seems to be unstable/incomplete.  It is written in C#, which
+gets in the way of our "easy to install" requirement.
+
+System Model
+------------
+
+![](./SystemModel.png)\ 
+
+Requirements
+------------
+
+ - Essential functional requirements
+    - As a host, I would like to create a new tournament.
+    - As a host, I would like to set some of the parameters of a
+      tournamet, such as number of players per team, whether
+      spectators ar allowed, and game type.
+    - As a player, I would like to register for a tournament.
+    - As a host, I would like to assign members to team, or have the
+      option to randomly assign teams.
+    - As a player, I would like to rate my peers, and would like to be
+      reviewed by my peers.
+    - As a player, or spectator, I would like to see the standings of
+      all players.
+    - As a host, or a player, I would like my win/rating history to be
+      stored so that I can have the same profile throughout many
+      tournaments.
+ - Essential non-functional requirements
+    - As a host, player, or spectator I would like the Project Leaguer
+      interface to be simple and easy to use.
+    - As a host, player, or spectator I would like the Project Leaguer
+      server to be secure and to operate quickly.
+ - Non-essential functional requirements
+    - As a host, I would like to be able to send public alerts to
+      players and spectators.
+    - As a player, I would like to be able to exchange private
+      messages with a host.
+    - As a player or spectator I would like access to Advanced 
+      Tournament Search facilities.
+ - Non-essential non-functional requirements
+    - As a player or spectator I would like to utilize an Interactive Menu.
+    - As a spectator, I would like to be able to watch matches on "Twitch".
+    - As a player, or a spectator, I would like to be able to access
+      the service on a mobile device.
diff --git a/doc/ProjectCharter.md b/doc/ProjectCharter.md
new file mode 100644
index 0000000..f88ccd4
--- /dev/null
+++ b/doc/ProjectCharter.md
@@ -0,0 +1,26 @@
+1. In team-based tournament sports, often individual contributions are
+   overshadowed by the binary end result: win or lose.  This
+   winner-takes-all mentality may unfairly pair players in later
+   stages of the tournament based on the team's score rather than
+   their own in early stages.
+
+2. Project Objectives:
+  * To address issues of fairness in tournament orchestration and
+  * To create a general-purpose open source solution for organizing
+    team-based tournaments where individual performance matters
+    * by implementing an out-of-the-box open source server software
+    * capable of managing pairings, scoring, and statistics for a
+      variety of applicable game types
+    * accessable via an intuitive web interface.
+
+3. Stakeholders - the development team, testers, and a future community of users.
+
+4. A Project Leaguer server provides the user with everything needed
+   to run a tournament: regisration, pairing, scoring, and statistics,
+   right away through a simple web interface.  Project Leaguer also
+   gives its users a unique option for scoring, not available through
+   traditional tournament management techniques: peer review.  By
+   providing a forward facing, web-based interface for tournament
+   participants to score their teammates, Project Leaguer allows
+   individual ability and activity to be recognized within the context
+   of an all-in, win-or-lose multiplayer team game.
diff --git a/doc/ProjectLeaguerWorkloadBreakup.md b/doc/ProjectLeaguerWorkloadBreakup.md
new file mode 100644
index 0000000..99d9c2e
--- /dev/null
+++ b/doc/ProjectLeaguerWorkloadBreakup.md
@@ -0,0 +1,14 @@
+How to break up workload:

+

+ * Login/Registration/Verification System

+ * SQL Database Design and Access

+ * User Interface

+ * Officiator Interface/Admin Access

+ * Pairings and Statistics

+ * Peer Review

+ * Secure Saved Server Image (backed up user profiles, database, and statistics)

+ * Separate Game Module Plugins

+ * General Abstractions

+ * Unit Testing and Error Handling

+ * Installing and Running Out-of-the-box

+ * Icons and Images

diff --git a/doc/Sprint1.md b/doc/Sprint1.md
new file mode 100644
index 0000000..03baf5d
--- /dev/null
+++ b/doc/Sprint1.md
@@ -0,0 +1,92 @@
+---
+title: "Project Leaguer: Sprint 1"
+author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumaker, Davis Webb ]
+---
+
+# User Stories
+
+1) As an administrator, I would like to install and boot my own server.
+   - Alternately: As a developer, I would like a demo/testing server,
+     with a basic Rails setup.
+2) As a host/player, I would like to register and have an account.
+   - For this task, we will be creating the user registration and log
+     in capabilities for Leaguer.
+3) As a host, I would like to start a tournamnet.
+   - For this task, we will be creating a base tournament system for a
+     host to run.
+4) As a host/player, I would like to enter scores for players.
+	- For sprint own, the scores will be entered by hand.
+5) As an administrator, I want to specify how users become hosts.
+6) As a user I would like to see the progress of the tournament in my
+   browser.
+7) As a user, I would like a presentable homepage.
+	- For this task, we will be creating a Leaguer homepage and ensure that it
+	  is pleasing to the eye and easy to navigate.
+
+# Tasks
+
+The "size" is using the modified Fibonacci scale.  A '1' is expected
+to take less than an hour.  A '3' is expected to take 3-6 hours.  A
+'5' should take the better part of a day or two.  An 8 should take
+several days.
+
++---------------------------------------------------------+------+--------+----+
+| Task Description                                        | Size | Person | US |
++=========================================================+======+========+====+
+| Learn Rails, set up Scaffolding for all Models, Views,  |    8 | All    |  1 |
+| Controllers                                             |      |        |    |
++---------------------------------------------------------+------+--------+----+
+| Deploy rails on the server at 199.180.255.147           |    3 | Luke   |  1 |
++---------------------------------------------------------+------+--------+----+
+| Peer review                                             |    1 | All    |  1 |
++---------------------------------------------------------+------+--------+----+
+| Create log-in system backend (verification, cookies,    |    5 | Davis  |  2 |
+| and redirection)                                        |      |        |    |
++---------------------------------------------------------+------+--------+----+
+| Create log-in system UI (forms, CSS, and submission)    |    2 | Tomer  |  2 |
++---------------------------------------------------------+------+--------+----+
+| Test it                                                 |    1 | Foy    |  2 |
++---------------------------------------------------------+------+--------+----+
+| Peer review                                             |    1 | All    |  2 |
++---------------------------------------------------------+------+--------+----+
+| Create Preliminary Tournament Settings Page             |    3 | Guntas |  3 |
++---------------------------------------------------------+------+--------+----+
+| Design/Code Scoring/Pairing Algorithms and Procedures   |    5 | Foy    |  3 |
++---------------------------------------------------------+------+--------+----+
+| Observe Foy Design/Code Scoring/Pairing Algorithms      |    2 | Dav+Foy|  3 |
++---------------------------------------------------------+------+--------+----+
+| Implement Tournament Registration and Tournament        |    2 | Andrew |  3 |
+| Controller                                              |      |        |    |
++---------------------------------------------------------+------+--------+----+
+| Test it                                                 |    1 | Andrew |  2 |
++---------------------------------------------------------+------+--------+----+
+| Peer review                                             |    1 | All    |  1 |
++---------------------------------------------------------+------+--------+----+
+| Design and implement match score models                 |    3 | Foy    |  4 |
++---------------------------------------------------------+------+--------+----+
+| Implement match controller                              |    3 | Dav+And|  4 |
++---------------------------------------------------------+------+--------+----+
+| Create a Player-level Data Entry Page/Method for Results|    3 | Tomer  |  4 |
++---------------------------------------------------------+------+--------+----+
+| Test it                                                 |    1 | Andrew |  2 |
++---------------------------------------------------------+------+--------+----+
+| Peer review                                             |    1 | All    |  1 |
++---------------------------------------------------------+------+--------+----+
+| Implement permissions system over the users system      |    3 | Luke   |  5 |
++---------------------------------------------------------+------+--------+----+
+| Create Admin-level Server Management Page               |    2 | Luke   |  5 |
++---------------------------------------------------------+------+--------+----+
+| Test it                                                 |    1 | Tomer  |  2 |
++---------------------------------------------------------+------+--------+----+
+| Peer review                                             |    1 | All    |  1 |
++---------------------------------------------------------+------+--------+----+
+| Create View Tournament Page                             |    5 | All    |  6 |
++---------------------------------------------------------+------+--------+----+
+| Test it                                                 |    1 | All    |  2 |
++---------------------------------------------------------+------+--------+----+
+| Peer review                                             |    1 | All    |  1 |
++---------------------------------------------------------+------+--------+----+
+| Create Presentable Homepage                             |    5 | Guntas |  7 |
++---------------------------------------------------------+------+--------+----+
+| Peer review                                             |    1 | All    |  1 |
++---------------------------------------------------------+------+--------+----+
diff --git a/doc/SystemModel.dot b/doc/SystemModel.dot
new file mode 100644
index 0000000..ea1836a
--- /dev/null
+++ b/doc/SystemModel.dot
@@ -0,0 +1,60 @@
+digraph SystemModel {
+	rankdir=LR;
+	peripheries=0;
+
+	/* users */
+	{
+		node [image="stickman.png", labelloc="b", shape="none"];
+		player[label="Player"];
+		host[label="Host"];
+		spectator[label="Spectator"];
+	}
+
+	/* subsystems */
+	/* if you want to rename any of these, it is probably easiest
+	* to leave the ID the same, and just change the label */
+	subgraph clusterSystem {
+		label = "System Boundry";
+		style = filled;
+
+		node [style=solid];
+		peerReview[label="Peer Review"];
+		performance[label="Performance"];
+		standings[label="Standings"];
+		gs[label="Game Score"];
+		search[label="Search"];
+		pm[label="Private Message"];
+		alerts[label="Alerts"];
+		pairings[label="Pairings"];
+		details[label="Tournament Details"];
+		backup[label="Backup"];
+		registration[label="Registration"];
+	}
+
+	/* all the relationships */
+	spectator -> search;
+	standings -> spectator;
+	alerts -> spectator;
+	pairings -> spectator;
+	
+	player -> spectator [arrowhead="onormal"];
+	player -> peerReview;
+	player -> performance;
+	player -> registration;
+	player -> pm;
+	pm -> player;
+
+	host->spectator [arrowhead="onormal"];
+	host->alerts;
+	host->details;
+	host->registration;
+	host -> pm;
+	pm -> host;
+	
+	peerReview -> standings;
+	performance-> standings;
+	gs -> performance;
+	details -> backup;
+	details -> pairings;
+	registration -> pairings;
+}
diff --git a/doc/stickman.png b/doc/stickman.png
new file mode 100644
index 0000000..00f16fc
--- /dev/null
+++ b/doc/stickman.png