From ace4c680b352dedd21e25b8fa5cb2c70c76d2911 Mon Sep 17 00:00:00 2001 From: DavisLWebb Date: Mon, 10 Feb 2014 09:57:04 -0500 Subject: I have added the basic skeleton of the design outline describing the Model 2 design. This will be refined but I am looking for some feed back (Mostly from Luke and Andrew). Anything I got wrong? Any suggestions for the web browser section? --- docs/DesignDocument.docx | Bin 54890 -> 42682 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/docs/DesignDocument.docx b/docs/DesignDocument.docx index f9be66d..aae07db 100644 Binary files a/docs/DesignDocument.docx and b/docs/DesignDocument.docx differ -- cgit v1.2.3-2-g168b From 9c38e418bbd86a630ae995ff9b1f1566c9fd5c92 Mon Sep 17 00:00:00 2001 From: DavisLWebb Date: Mon, 10 Feb 2014 10:06:57 -0500 Subject: Ive changed the design doc by adding the Model 2 application design --- .gitignore | 4 ++ Diagram01.jpg | Bin 0 -> 2008078 bytes Makefile | 17 ++++++ ProductBacklog.md | 108 +++++++++++++++++++++++++++++++++++++++ ProductBacklog.md~ | 55 ++++++++++++++++++++ ProjectCharter.md | 26 ++++++++++ ProjectLeaguerWorkloadBreakup.md | 14 +++++ SystemModel.dot | 60 ++++++++++++++++++++++ docs/.~lock.DesignDocument.docx# | 1 + docs/DesignDocument.docx | Bin 42682 -> 42692 bytes stickman.png | Bin 0 -> 1308 bytes 11 files changed, 285 insertions(+) create mode 100644 .gitignore create mode 100644 Diagram01.jpg create mode 100644 Makefile create mode 100644 ProductBacklog.md create mode 100644 ProductBacklog.md~ create mode 100644 ProjectCharter.md create mode 100644 ProjectLeaguerWorkloadBreakup.md create mode 100644 SystemModel.dot create mode 100644 docs/.~lock.DesignDocument.docx# create mode 100644 stickman.png diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..ed193ea --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +*.pdf +*.html +*.png +!stickman.png diff --git a/Diagram01.jpg b/Diagram01.jpg new file mode 100644 index 0000000..0c85216 Binary files /dev/null and b/Diagram01.jpg differ diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..7a239c4 --- /dev/null +++ b/Makefile @@ -0,0 +1,17 @@ +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 new file mode 100644 index 0000000..cb089c6 --- /dev/null +++ b/ProductBacklog.md @@ -0,0 +1,108 @@ +--- +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~ new file mode 100644 index 0000000..b193d89 --- /dev/null +++ b/ProductBacklog.md~ @@ -0,0 +1,55 @@ +--- +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 new file mode 100644 index 0000000..f88ccd4 --- /dev/null +++ b/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/ProjectLeaguerWorkloadBreakup.md b/ProjectLeaguerWorkloadBreakup.md new file mode 100644 index 0000000..99d9c2e --- /dev/null +++ b/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/SystemModel.dot b/SystemModel.dot new file mode 100644 index 0000000..ea1836a --- /dev/null +++ b/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/docs/.~lock.DesignDocument.docx# b/docs/.~lock.DesignDocument.docx# new file mode 100644 index 0000000..e66fdd4 --- /dev/null +++ b/docs/.~lock.DesignDocument.docx# @@ -0,0 +1 @@ +Davis ,amelia,Amelia,10.02.2014 10:01,file:///home/amelia/.config/libreoffice/3; \ No newline at end of file diff --git a/docs/DesignDocument.docx b/docs/DesignDocument.docx index aae07db..4215ce0 100644 Binary files a/docs/DesignDocument.docx and b/docs/DesignDocument.docx differ diff --git a/stickman.png b/stickman.png new file mode 100644 index 0000000..00f16fc Binary files /dev/null and b/stickman.png differ -- cgit v1.2.3-2-g168b From 2c9640b00d0de74fce98a5af511b7b08784b24b3 Mon Sep 17 00:00:00 2001 From: DavisLWebb Date: Mon, 10 Feb 2014 10:31:46 -0500 Subject: I have completely changed my format for the design section. Sorry about the first sloppy work. Luke and Andrew, I have no clue what the model section should be. --- docs/.~lock.DesignDocument.docx# | 2 +- docs/DesignDocument.docx | Bin 42692 -> 42937 bytes 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/.~lock.DesignDocument.docx# b/docs/.~lock.DesignDocument.docx# index e66fdd4..50859f6 100644 --- a/docs/.~lock.DesignDocument.docx# +++ b/docs/.~lock.DesignDocument.docx# @@ -1 +1 @@ -Davis ,amelia,Amelia,10.02.2014 10:01,file:///home/amelia/.config/libreoffice/3; \ No newline at end of file +Davis ,amelia,Amelia,10.02.2014 10:30,file:///home/amelia/.config/libreoffice/3; \ No newline at end of file diff --git a/docs/DesignDocument.docx b/docs/DesignDocument.docx index 4215ce0..f621ac6 100644 Binary files a/docs/DesignDocument.docx and b/docs/DesignDocument.docx differ -- cgit v1.2.3-2-g168b From c54aa13522dae9b0d19af50b7cb218c4f7e2407e Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 10:46:56 -0500 Subject: DesignDocument -> to text --- docs/DesignDocument.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 docs/DesignDocument.md diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md new file mode 100644 index 0000000..6fb6b37 --- /dev/null +++ b/docs/DesignDocument.md @@ -0,0 +1,79 @@ +Design Document +Version 1.0 – 2014.02.09 +Created 2014.02.09 + +Leaguer +Nathaniel Foy +Guntas Grewal +Tomer Kimia +Andrew Murell +Luke Shumaker +Davis Webb + + +Contents + +Purpose 4 +Non-Functional Requirements 4 +Design Outlines 4 +Design Decisions and Components 4 +Component Interaction 4 +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. 4 +Design Issues 4 +Scoring Algorithm 4 +Offline Data Management 5 +Fetching Data from Games 5 +Design Details 5 +Class Descriptions and Interactions 5 +UML Diagram of Classes 5 + + + + + +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. + +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: + 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. + +Offline Data Management +TODO – Nathniel write this +Fetching Data from Games +TODO – Nathaniel write this. + +Design Details +Class Descriptions and Interactions +TODO – I will do this, but Andrew you will guide me through some of the ideas +Note – All of these classes are represented in the “Model” part of the Model 2 software pattern. +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 + + +UML Diagram of Classes +TODO – I’m working on this -- cgit v1.2.3-2-g168b