From 5f099f17a43fbe683b330ce4b23b508a06f88a5a Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 10:52:55 -0500 Subject: remove doc files in the root --- Diagram01.jpg | Bin 2008078 -> 0 bytes Makefile | 17 ------ ProductBacklog.md | 108 --------------------------------------- ProductBacklog.md~ | 55 -------------------- ProjectCharter.md | 26 ---------- ProjectLeaguerWorkloadBreakup.md | 14 ----- SystemModel.dot | 60 ---------------------- stickman.png | Bin 1308 -> 0 bytes 8 files changed, 280 deletions(-) delete mode 100644 Diagram01.jpg delete mode 100644 Makefile delete mode 100644 ProductBacklog.md delete mode 100644 ProductBacklog.md~ delete mode 100644 ProjectCharter.md delete mode 100644 ProjectLeaguerWorkloadBreakup.md delete mode 100644 SystemModel.dot delete mode 100644 stickman.png diff --git a/Diagram01.jpg b/Diagram01.jpg deleted file mode 100644 index 0c85216..0000000 Binary files a/Diagram01.jpg and /dev/null differ diff --git a/Makefile b/Makefile deleted file mode 100644 index 7a239c4..0000000 --- a/Makefile +++ /dev/null @@ -1,17 +0,0 @@ -docs = ProductBacklog ProjectCharter ProjectLeaguerWorkloadBreakup - -pdf: $(addsuffix .pdf,$(docs)) -html: $(addsuffix .html,$(docs)) - -%.pdf: %.md Makefile - pandoc -s $< -o $@ -%.html: %.md Makefile - pandoc -s $< -o $@ -%.png: %.dot Makefile - dot -Tpng < $< > $@ - -ProductBacklog.pdf: SystemModel.png -SystemModel.png: stickman.png - -clean: - rm -f -- *.pdf *.html diff --git a/ProductBacklog.md b/ProductBacklog.md deleted file mode 100644 index cb089c6..0000000 --- a/ProductBacklog.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -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 ------------- -<<<<<<< HEAD -// -+---------+-----------------------------------+-----------------------------+ -| | Functional Requirements | Non-Functional Requirements | -+=========+===================================+===================================================================================+ -| Must be | - Tournament Creation | - As a user and host, I would like the program to be simple and intuitive | -| done | - Tournament Settings Management | - As a user and host, I would like the program to be fast and memory efficient | -| | - Tournament Registration | - As a user and host, I would like installation to be as simple as possible | -| | - Tournament Pairings | | -| | - Peer Review System | | -| | - Standings | | -| | - Server File Backup | | -+---------+-----------------------------------+-----------------------------------------------------------------------------------+ -| If time | - Alert System | - Interactive Menu | -| allows | - Private Message System | - Twitch Integration | -| | - Advanced Tournament Search | - Mobile Access | -+---------+-----------------------------------+-----------------------------+ -======= - - - 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. ->>>>>>> 81ad3ea9605516711b798ba759a2dd1c7264d8d1 diff --git a/ProductBacklog.md~ b/ProductBacklog.md~ deleted file mode 100644 index b193d89..0000000 --- a/ProductBacklog.md~ +++ /dev/null @@ -1,55 +0,0 @@ ---- -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). - -TODO - Luke write about existing software. - -System Model ------------- - -![](./Diagram01.jpg)\ - -Requirements ------------- - -+---------+-----------------------------------+-----------------------------+ -| | Functional Requirements | Non-Functional Requirements | -+=========+===================================+===================================================================================+ -| Must be | - Tournament Creation | - As a user and host, I would like the program to be simple and intuitive | -| done | - Tournament Settings Management | - As a user and host, I would like the program to be fast and memory efficient | -| | - Tournament Registration | - As a user and host, I would like installation to be as simple as possible | -| | - Tournament Pairings | | -| | - Peer Review System | | -| | - Standings | | -| | - Server File Backup | | -+---------+-----------------------------------+-----------------------------------------------------------------------------------+ -| If time | - Alert System | - Interactive Menu | -| allows | - Private Message System | - Twitch Integration | -| | - Advanced Tournament Search | - Mobile Access | -+---------+-----------------------------------+-----------------------------+ diff --git a/ProjectCharter.md b/ProjectCharter.md deleted file mode 100644 index f88ccd4..0000000 --- a/ProjectCharter.md +++ /dev/null @@ -1,26 +0,0 @@ -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/ProjectLeaguerWorkloadBreakup.md b/ProjectLeaguerWorkloadBreakup.md deleted file mode 100644 index 99d9c2e..0000000 --- a/ProjectLeaguerWorkloadBreakup.md +++ /dev/null @@ -1,14 +0,0 @@ -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/SystemModel.dot b/SystemModel.dot deleted file mode 100644 index ea1836a..0000000 --- a/SystemModel.dot +++ /dev/null @@ -1,60 +0,0 @@ -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/stickman.png b/stickman.png deleted file mode 100644 index 00f16fc..0000000 Binary files a/stickman.png and /dev/null differ -- cgit v1.2.3-2-g168b From be87ec3bf30b75a1fdacd16f013ea4a4cfccd9fe Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 10:53:14 -0500 Subject: edit the root .gitignore to ignore editor files --- .gitignore | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/.gitignore b/.gitignore index ed193ea..3895d93 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,3 @@ -*.pdf -*.html -*.png -!stickman.png +.~lock.* +*~ +*# -- cgit v1.2.3-2-g168b From 84b34596d4291d95dfebf073a8e3e890a06ea2c0 Mon Sep 17 00:00:00 2001 From: AndrewMurrell Date: Mon, 10 Feb 2014 10:54:44 -0500 Subject: I can't edit the docx from here (using vim) so I added this file, when I get to work I'll add it to the other one. --- docs/DesignDocument_Purpose.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 docs/DesignDocument_Purpose.txt diff --git a/docs/DesignDocument_Purpose.txt b/docs/DesignDocument_Purpose.txt new file mode 100644 index 0000000..ed06d2f --- /dev/null +++ b/docs/DesignDocument_Purpose.txt @@ -0,0 +1,15 @@ +Purpose: + +The purpose of this document is to outlay the desgin, 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. +Whether it's League of Legends, Chess, Poker or more, Project Leaguer provides +tournament organizers, participants, and spectators with an online +interface to keep up with the score. + +The software itself operates as a stand-alone background application +accessible and configurable though its web interface. + +NOT FINISHED -- JUST COMMITING -- cgit v1.2.3-2-g168b From 93418436bfc078eca31724bf5b7170855fcbbcdb Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 10:56:59 -0500 Subject: remove lock file --- .gitignore | 1 + docs/.~lock.DesignDocument.docx# | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) delete mode 100644 docs/.~lock.DesignDocument.docx# diff --git a/.gitignore b/.gitignore index 3895d93..2c03f2a 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ .~lock.* *~ *# +.#* \ No newline at end of file diff --git a/docs/.~lock.DesignDocument.docx# b/docs/.~lock.DesignDocument.docx# deleted file mode 100644 index 50859f6..0000000 --- a/docs/.~lock.DesignDocument.docx# +++ /dev/null @@ -1 +0,0 @@ -Davis ,amelia,Amelia,10.02.2014 10:30,file:///home/amelia/.config/libreoffice/3; \ No newline at end of file -- cgit v1.2.3-2-g168b From 9edc561c4bc11a201c018f546e2ddafba581dac7 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 10:58:54 -0500 Subject: markdown-ize some of the design document --- docs/DesignDocument.md | 37 ++++++++++--------------------------- 1 file changed, 10 insertions(+), 27 deletions(-) diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 7d9bc14..29387dd 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -1,32 +1,15 @@ -Design Document +--- +title: Design Document +author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumaker, Davis Webb ] +--- Version 1.0 – 2014.02.09 -Created 2014.02.09 - -Leaguer -Nathaniel Foy -Guntas Grewal -Tomer Kimia -Andrew Murell -Luke Shumaker -Davis Webb - -1. Contents -1Purpose 3 -2Non-Functional Requirements 3 -3Design Outlines 3 -3.1Design Decisions and Components 3 -3.2Component Interaction 3 -4Design Issues 3 -4.1Scoring Algorithm 3 -4.2Offline Data Management 3 -4.3Fetching Data from Games 3 -5Design Details 4 -5.1Class Descriptions and Interactions 4 -5.2UML Diagram of Classes 4 +Created 2014.02.09 - -1 Purpose -This document describes all components of the Leaguer Tournament management system. Leaguer is a software to be installed and run on a server. TODO. ANDREW COMPLETE THIS. +# Purpose + +This document describes all components of the Leaguer Tournament +management system. Leaguer is a software to be installed and run on a +server. TODO. ANDREW COMPLETE THIS. 2 Non-Functional Requirements TODO Guntas. Email dunsmore and marco about this, then fill it out. -- cgit v1.2.3-2-g168b From 67594bd1950cfb2078075d4c3e8798eea7254b4d Mon Sep 17 00:00:00 2001 From: tkimia Date: Mon, 10 Feb 2014 11:00:44 -0500 Subject: added some views to 5.1 --- docs/DesignDocument.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 7d9bc14..9b781a7 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -69,7 +69,13 @@ Webpage: An abstract HTML file, all entries below are webpages (we represent the Homepage: This page has 3 basic options. Visually simple – two large buttons on a white screen, and a search bar above them. The search bar will allow you to search upcoming or current searchable tournaments. Log in (which will take you to the login page) and “Go to Tournament” in which you enter a tournament title. This interacts with the Homepage Controller. Login: Page with form entries for username, password. If user clicks “new user” more forms entries will appear. One for repeating the password, and one for email. This interacts with the Login controller. Tournament: A tree-like display of pairs 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. This will open up more options for the host to change. This interacts with the tournament controller. -Match: A display of both teams. +Match: A display of both teams. Each team's players are clickable which leads to the player's profile. A link above both teams leads back to the tournament the match belongs to. This interacts with the Match controller. +Search: A page with a searchbar and a list of searchable tournaments that match the search query. Each entry is clickable and leads to a tournament. +UserProfile: A page with the user's information. One can view the player's reviews. If the user is viewing his/her own profile, they can edit it. This interacts with the UserProfile controller. + + +CONTROLLERS +Homepage Controller: Server: Rails’ Server class handles all HTTP events. Our Server class is the class that is the main program. It instantiates other classes, manages requests from Views, and runs static methods. User: A class that represents someone using the Views (HTML, javascript) the user is in competitions and -- cgit v1.2.3-2-g168b From 9b2e34b9065ae61c229f3d088ae7ba13c284f3b1 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 11:10:11 -0500 Subject: texify more of the design doc --- docs/DesignDocument.md | 96 ++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 70 insertions(+), 26 deletions(-) diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 10e88bb..7b4d8d2 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -11,33 +11,77 @@ This document describes all components of the Leaguer Tournament management system. Leaguer is a software to be installed and run on a server. TODO. ANDREW COMPLETE THIS. -2 Non-Functional Requirements -TODO Guntas. Email dunsmore and marco about this, then fill it out. - -3 Design Outlines -3.1 Design Decisions and Components -Our system will on the Model 2 design pattern/architecture. TODO: Davis – add the purpose of EACH component as a list. -Controllers – The controllers will control any logic necessary to obtain the correct content for display. It then places the content in the request and decides which view it will be passed to. -Models – The classes in the UML document below will reside in the model… -Views – Views will be the HTML pages for Leaguer, and will display the users desired content inside of the web browser. -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 seven 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. 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. -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. -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. +# Non-Functional Requirements + +TODO Guntas. Email dunsmore and marco about this, then fill it out. + +# Design Outlines +## Design Decisions and Components + +Our system will on the Model 2 design pattern/architecture. TODO: +Davis – add the purpose of EACH component as a list. + +Controllers – The controllers will control any logic necessary to +obtain the correct content for display. It then places the content in +the request and decides which view it will be passed to. + +Models – The classes in the UML document below will reside in the +model… + +Views – Views will be the HTML pages for Leaguer, and will display the +users desired content inside of the web browser. + +## 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 seven controllers into Leaguer. Those will +be: + + 1. 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. + 2. Homepage – Used to handle the homepage. This will be the first + web page seen by any user of the application. + 3. Login – This controller will be used when a user attempts to sign + in to their profile on Leaguer. + 4. Search – This controller will be used to search the web-base for + on going tournaments, players and past tournaments. + 5. Tournament – Used for setting up a tournament. This will be + restricted to the host of the tournament. + 6. User – The controller that will take each user to their own + profile. + 7. Match/Peer Review – used for gather game statistics and the + separate player reviews. + +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. + +# 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. -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. 4.2 Offline Data Management TODO – Nathniel write this -- cgit v1.2.3-2-g168b From 181fa1673c5f151f808c3b5f3379e82aae042ed7 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 11:11:44 -0500 Subject: merge the Design document purpose --- docs/DesignDocument.md | 17 ++++++++++++++--- docs/DesignDocument_Purpose.txt | 15 --------------- 2 files changed, 14 insertions(+), 18 deletions(-) delete mode 100644 docs/DesignDocument_Purpose.txt diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 7b4d8d2..5ee831a 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -7,9 +7,20 @@ Created 2014.02.09 # Purpose -This document describes all components of the Leaguer Tournament -management system. Leaguer is a software to be installed and run on a -server. TODO. ANDREW COMPLETE THIS. +The purpose of this document is to outlay the desgin, 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. +Whether it's League of Legends, Chess, Poker or more, Project Leaguer provides +tournament organizers, participants, and spectators with an online +interface to keep up with the score. + +The software itself operates as a stand-alone background application +accessible and configurable though its web interface. + +NOT FINISHED -- JUST COMMITING +ANDREW COMPLETE THIS. # Non-Functional Requirements diff --git a/docs/DesignDocument_Purpose.txt b/docs/DesignDocument_Purpose.txt deleted file mode 100644 index ed06d2f..0000000 --- a/docs/DesignDocument_Purpose.txt +++ /dev/null @@ -1,15 +0,0 @@ -Purpose: - -The purpose of this document is to outlay the desgin, 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. -Whether it's League of Legends, Chess, Poker or more, Project Leaguer provides -tournament organizers, participants, and spectators with an online -interface to keep up with the score. - -The software itself operates as a stand-alone background application -accessible and configurable though its web interface. - -NOT FINISHED -- JUST COMMITING -- cgit v1.2.3-2-g168b From e796dc9457f566105e7f1f102a64e69dae5ad39c Mon Sep 17 00:00:00 2001 From: tkimia Date: Mon, 10 Feb 2014 11:12:24 -0500 Subject: Views are more technical (5.1) --- docs/DesignDocument.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 9b781a7..1fb852b 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -65,13 +65,19 @@ TODO – Nathaniel write this. 5.1 Class Descriptions and Interactions VIEWS -Webpage: An abstract HTML file, all entries below are webpages (we represent them as subclasses of the abstract “Webpage” class. All webpages will send HTTP requests to the server. Most of the visual effects and update the display with Javascript methods. Each page will have a link to either the login or the logged in user’s page. -Homepage: This page has 3 basic options. Visually simple – two large buttons on a white screen, and a search bar above them. The search bar will allow you to search upcoming or current searchable tournaments. Log in (which will take you to the login page) and “Go to Tournament” in which you enter a tournament title. This interacts with the Homepage Controller. -Login: Page with form entries for username, password. If user clicks “new user” more forms entries will appear. One for repeating the password, and one for email. This interacts with the Login controller. -Tournament: A tree-like display of pairs 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. This will open up more options for the host to change. This interacts with the tournament controller. -Match: A display of both teams. Each team's players are clickable which leads to the player's profile. A link above both teams leads back to the tournament the match belongs to. This interacts with the Match controller. -Search: A page with a searchbar and a list of searchable tournaments that match the search query. Each entry is clickable and leads to a tournament. -UserProfile: A page with the user's information. One can view the player's reviews. If the user is viewing his/her own profile, they can edit it. This interacts with the UserProfile controller. +Webpage: An abstract HTML file, all entries below are webpages (we represent them as subclasses of the abstract “Webpage” class. All webpages will send HTTP requests to the server. Most of the visual effects and update the display with Javascript methods. Each page will have a login dialogue which will POST to the login controller or the logged in user’s page. + +Homepage: This page has 3 basic options. Visually simple – two large buttons on a white screen, and a search bar above them. The search bar will cause a POST requeest to the search controller. Log in (which will cause a POST to the login controller) and “Go to Tournament” in which you enter a tournament title. This interacts with the Homepage Controller. + +Login: Page with form entries for username, password. If user clicks “new user” more forms entries will appear. One for repeating the password, and one for email. This POST to the Login controller. + +Tournament: A tree-like display of pairs 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. This will open up more options for the host to change. This will POST to the tournament controller. + +Match: A display of both teams. Each team's players are clickable which causes a GET for the player's profile HTML. A link above both teams will GET the tournament the match belongs to. This will POST its actions to the Match controller. + +Search: A page with a searchbar and a list of searchable tournaments that match the search query. The searchbar causes a POST to the search controller. Each entry is clickable and causes a GET to the enrry's tournament. + +UserProfile: A page with the user's information. One can view the player's reviews. If the user is viewing his/her own profile, they can edit it causing a POST to the userProfile controller. CONTROLLERS -- cgit v1.2.3-2-g168b From d3fac3566f7a9c395feecbfeaf7ea223246ee0c1 Mon Sep 17 00:00:00 2001 From: tkimia Date: Mon, 10 Feb 2014 11:35:44 -0500 Subject: Added some controllers --- docs/DesignDocument.md | 148 ++++++++++++++++++++++--------------------------- docs/Images.pptx | Bin 44675 -> 41303 bytes 2 files changed, 66 insertions(+), 82 deletions(-) diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index aaf42f0..d9761b1 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -1,87 +1,60 @@ ---- -title: Design Document -author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumaker, Davis Webb ] ---- +Design Document Version 1.0 – 2014.02.09 -Created 2014.02.09 - -# Purpose +Created 2014.02.09 + +Leaguer +Nathaniel Foy +Guntas Grewal +Tomer Kimia +Andrew Murell +Luke Shumaker +Davis Webb + +1. Contents +1Purpose 3 +2Non-Functional Requirements 3 +3Design Outlines 3 +3.1Design Decisions and Components 3 +3.2Component Interaction 3 +4Design Issues 3 +4.1Scoring Algorithm 3 +4.2Offline Data Management 3 +4.3Fetching Data from Games 3 +5Design Details 4 +5.1Class Descriptions and Interactions 4 +5.2UML Diagram of Classes 4 -This document describes all components of the Leaguer Tournament -management system. Leaguer is a software to be installed and run on a -server. TODO. ANDREW COMPLETE THIS. -# Non-Functional Requirements - -TODO Guntas. Email dunsmore and marco about this, then fill it out. - -# Design Outlines -## Design Decisions and Components - -Our system will on the Model 2 design pattern/architecture. TODO: -Davis – add the purpose of EACH component as a list. - -Controllers – The controllers will control any logic necessary to -obtain the correct content for display. It then places the content in -the request and decides which view it will be passed to. - -Models – The classes in the UML document below will reside in the -model… - -Views – Views will be the HTML pages for Leaguer, and will display the -users desired content inside of the web browser. - -## 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 seven controllers into Leaguer. Those will -be: - - 1. 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. - 2. Homepage – Used to handle the homepage. This will be the first - web page seen by any user of the application. - 3. Login – This controller will be used when a user attempts to sign - in to their profile on Leaguer. - 4. Search – This controller will be used to search the web-base for - on going tournaments, players and past tournaments. - 5. Tournament – Used for setting up a tournament. This will be - restricted to the host of the tournament. - 6. User – The controller that will take each user to their own - profile. - 7. Match/Peer Review – used for gather game statistics and the - separate player reviews. - -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. - -# 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. +1 Purpose +This document describes all components of the Leaguer Tournament management system. Leaguer is a software to be installed and run on a server. TODO. ANDREW COMPLETE THIS. + +2 Non-Functional Requirements +TODO Guntas. Email dunsmore and marco about this, then fill it out. + +3 Design Outlines +3.1 Design Decisions and Components +Our system will on the Model 2 design pattern/architecture. TODO: Davis – add the purpose of EACH component as a list. +Controllers – The controllers will control any logic necessary to obtain the correct content for display. It then places the content in the request and decides which view it will be passed to. +Models – The classes in the UML document below will reside in the model… +Views – Views will be the HTML pages for Leaguer, and will display the users desired content inside of the web browser. +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 seven 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. 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. +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. +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. 4.2 Offline Data Management TODO – Nathniel write this @@ -98,7 +71,11 @@ Homepage: This page has 3 basic options. Visually simple – two large buttons o Login: Page with form entries for username, password. If user clicks “new user” more forms entries will appear. One for repeating the password, and one for email. This POST to the Login controller. -Tournament: A tree-like display of pairs 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. This will open up more options for the host to change. This will POST to the tournament controller. +newTorunament: A form that interacts with users who are either hosts or becoming hosts. This interacts with tournament controller. + +Tournament: 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 the edit Tournament view. There will be an end button that will redirect to back to the homepage after posting to the tournament controller. The tournament will POST to the tournament controller. + +editTorunament: This view is a list of settings. Some are form entries, and some are checkboxes. More settings will be added later in develpment. This view interacts with the tournament controller. Match: A display of both teams. Each team's players are clickable which causes a GET for the player's profile HTML. A link above both teams will GET the tournament the match belongs to. This will POST its actions to the Match controller. @@ -108,7 +85,14 @@ UserProfile: A page with the user's information. One can view the player's revie CONTROLLERS -Homepage Controller: +HomepageController: This is the main controller. It has methods showHomepage() which renders the homepage view. It has editSettings() method, that gets the current settings of the entire server, provided that the host is viewing the homepage. + +LoginController: This has doLogin() and doLogout(). Both have access to the HTTP requrest. It will interact with the Users model to validate passwords and usernames. + +TournamentController: This controller will have methods: newTorunament(), getTournament(), editTournament(), and endTournament(). All of these methods will interact with the Tournament model, and all of its fields including users matches and TournamentSettings. And all will interact with their tournament view, for example, newTournament() will render newTorunament. + + + Server: Rails’ Server class handles all HTTP events. Our Server class is the class that is the main program. It instantiates other classes, manages requests from Views, and runs static methods. User: A class that represents someone using the Views (HTML, javascript) the user is in competitions and diff --git a/docs/Images.pptx b/docs/Images.pptx index 73f002d..01e8016 100644 Binary files a/docs/Images.pptx and b/docs/Images.pptx differ -- cgit v1.2.3-2-g168b