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