Merge branch 'master' of https://gitlab.cas.mcmaster.ca/wangs132/minecraft into Grades

Doc/Design/MG/.gitignore

+*.aux
+*.log
+*.gz
\ No newline at end of file

Doc/Design/MG/MG.bib

+%% This BibTeX bibliography file was created using BibDesk.
+%% http://bibdesk.sourceforge.net/
+
+
+%% Created for Spencer Smith at 2016-10-27 23:57:04 -0400 
+
+
+%% Saved with string encoding Unicode (UTF-8) 
+
+
+
+@inproceedings{Parnas1978,
+	Address = {Piscataway, NJ, USA},
+	Author = {David L. Parnas},
+	Booktitle = {ICSE '78: Proceedings of the 3rd international conference on Software engineering},
+	Date-Added = {2016-10-28 03:56:16 +0000},
+	Date-Modified = {2016-10-28 03:56:16 +0000},
+	Isbn = {none},
+	Location = {Atlanta, Georgia, United States},
+	Pages = {264--277},
+	Publisher = {IEEE Press},
+	Title = {Designing Software for Ease of Extension and Contraction},
+	Year = {1978}}
+
+@article{Parnas1972a,
+	Author = {David L. Parnas},
+	Date-Added = {2016-10-28 03:55:43 +0000},
+	Date-Modified = {2016-10-28 03:55:43 +0000},
+	Journal = {Comm. ACM},
+	Month = {December},
+	Number = {2},
+	Pages = {1053--1058},
+	Title = {On the Criteria To Be Used in Decomposing Systems into Modules},
+	Volume = {15},
+	Year = {1972},
+	Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QOS4uLy4uLy4uLy4uLy4uLy4uL1dvcmsvUmVzZWFyY2gvUmVmZXJlbmNlcy9QYXJuYXMxOTcyLnBkZtIXCxgZV05TLmRhdGFPEQGmAAAAAAGmAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAAXAgwOUGFybmFzMTk3Mi5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3+xs9CaVP4AAAAAAAAAAAAGAAQAAAkgAAAAAAAAAAAAAAAAAAAAClJlZmVyZW5jZXMAEAAIAADOl6vDAAAAEQAIAADQmptOAAAAAQAUABcCDAAXAE0AFv3tAAj3ZgACZI4AAgBGTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFdvcms6AFJlc2VhcmNoOgBSZWZlcmVuY2VzOgBQYXJuYXMxOTcyLnBkZgAOAB4ADgBQAGEAcgBuAGEAcwAxADkANwAyAC4AcABkAGYADwAaAAwATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAEgA0VXNlcnMvc21pdGhzL1dvcmsvUmVzZWFyY2gvUmVmZXJlbmNlcy9QYXJuYXMxOTcyLnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOAMoAzwDXAoECgwKIApMCnAKqAq4CtQK+AsMC0ALTAuUC6ALtAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAu8=}}
+
+@inproceedings{ParnasEtAl1984,
+	Author = {D.L. Parnas and P.C. Clement and D. M. Weiss},
+	Booktitle = {International Conference on Software Engineering},
+	Date-Added = {2016-10-28 03:55:23 +0000},
+	Date-Modified = {2016-10-28 03:55:23 +0000},
+	Pages = {408-419},
+	Title = {The modular structure of complex systems},
+	Year = {1984},
+	Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QPy4uLy4uLy4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0V0QWwxOTg0LnBkZtIXCxgZV05TLmRhdGFPEQHcAAAAAAHcAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAkx/Q0SUGFybmFzRXRBbDE5ODQucGRmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACTH9RNNvBNMAAAAAAAAAAAAFAAMAAAkgAAAAAAAAAAAAAAAAAAAAF1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzAAAQAAgAAM6Xq8MAAAARAAgAANNvPRMAAAABABQJMf0NCTHuxwASFacACPdmAAJkjgACAFVNYWNpbnRvc2ggSEQ6VXNlcnM6AHNtaXRoczoAUmVwb3M6AHNlNHNjOgBTY2lDb21wQW5kU29mdEVuZ1BhcGVyczoAUGFybmFzRXRBbDE5ODQucGRmAAAOACYAEgBQAGEAcgBuAGEAcwBFAHQAQQBsADEAOQA4ADQALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAENVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzRXRBbDE5ODQucGRmAAATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANAA1QDdAr0CvwLEAs8C2ALmAuoC8QL6Av8DDAMPAyEDJAMpAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAys=}}
+
+@book{RobertsonAndRobertson2012,
+	Author = {James Robertson and Suzanne Robertson},
+	Date-Added = {2016-09-22 13:54:40 +0000},
+	Date-Modified = {2016-09-22 14:01:42 +0000},
+	Edition = {16},
+	Publisher = {Atlantic Systems Guild Limited},
+	Title = {Volere Requirements Specification Template},
+	Year = {2012}}
+
+@article{ParnasAndClements1986,
+	Author = {David L. Parnas and P.C. Clements},
+	Date-Added = {2016-09-10 13:11:57 +0000},
+	Date-Modified = {2016-09-10 13:11:57 +0000},
+	Journal = {IEEE Transactions on Software Engineering},
+	Number = {2},
+	Pages = {251--257},
+	Title = {A Rational Design Process: How and Why to Fake it},
+	Volume = {12},
+	Year = {February 1986},
+	Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QRi4uLy4uLy4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGbSFwsYGVdOUy5kYXRhTxEB9gAAAAAB9gACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAAzpdzg0grAAAJMf0NGVBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkx/UPTbwTTAAAAAAAAAAAABQADAAAJIAAAAAAAAAAAAAAAAAAAABdTY2lDb21wQW5kU29mdEVuZ1BhcGVycwAAEAAIAADOl6vDAAAAEQAIAADTbz0TAAAAAQAUCTH9DQkx7scAEhWnAAj3ZgACZI4AAgBcTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFJlcG9zOgBzZTRzYzoAU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnM6AFBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYADgA0ABkAUABhAHIAbgBhAHMAQQBuAGQAQwBsAGUAbQBlAG4AdABzADEAOQA4ADYALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAEpVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzQW5kQ2xlbWVudHMxOTg2LnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANcA3ADkAt4C4ALlAvAC+QMHAwsDEgMbAyADLQMwA0IDRQNKAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA0w=}}

Doc/Design/MG/MG.tex

+\documentclass[12pt, titlepage]{article}
+
+\usepackage{fullpage}
+\usepackage[round]{natbib}
+\usepackage{multirow}
+\usepackage{booktabs}
+\usepackage{tabularx}
+\usepackage{graphicx}
+\usepackage{float}
+\usepackage{hyperref}
+\hypersetup{
+    colorlinks,
+    citecolor=black,
+    filecolor=black,
+    linkcolor=red,
+    urlcolor=blue
+}
+\usepackage[round]{natbib}
+
+\newcounter{acnum}
+\newcommand{\actheacnum}{AC\theacnum}
+\newcommand{\acref}[1]{AC\ref{#1}}
+
+\newcounter{ucnum}
+\newcommand{\uctheucnum}{UC\theucnum}
+\newcommand{\uref}[1]{UC\ref{#1}}
+
+\newcounter{mnum}
+\newcommand{\mthemnum}{M\themnum}
+\newcommand{\mref}[1]{M\ref{#1}}
+
+\title{SE 3XA3: Software Requirements Specification\\Title of Project}
+
+\author{Team \#, Team Name
+		\\ Student 1 name and macid
+		\\ Student 2 name and macid
+		\\ Student 3 name and macid
+}
+
+\date{\today}
+
+\input{../../Comments}
+
+\begin{document}
+
+\maketitle
+
+\pagenumbering{roman}
+\tableofcontents
+\listoftables
+\listoffigures
+
+\begin{table}[bp]
+\caption{\bf Revision History}
+\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
+\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
+\midrule
+Date 1 & 1.0 & Notes\\
+Date 2 & 1.1 & Notes\\
+\bottomrule
+\end{tabularx}
+\end{table}
+
+\newpage
+
+\pagenumbering{arabic}
+
+\section{Introduction}
+
+Decomposing a system into modules is a commonly accepted approach to developing
+software.  A module is a work assignment for a programmer or programming
+team~\citep{ParnasEtAl1984}.  We advocate a decomposition
+based on the principle of information hiding~\citep{Parnas1972a}.  This
+principle supports design for change, because the ``secrets'' that each module
+hides represent likely future changes.  Design for change is valuable in SC,
+where modifications are frequent, especially during initial development as the
+solution space is explored.  
+
+Our design follows the rules layed out by \citet{ParnasEtAl1984}, as follows:
+\begin{itemize}
+\item System details that are likely to change independently should be the
+  secrets of separate modules.
+\item Each data structure is used in only one module.
+\item Any other program that requires information stored in a module's data
+  structures must obtain it by calling access programs belonging to that module.
+\end{itemize}
+
+After completing the first stage of the design, the Software Requirements
+Specification (SRS), the Module Guide (MG) is developed~\citep{ParnasEtAl1984}. The MG
+specifies the modular structure of the system and is intended to allow both
+designers and maintainers to easily identify the parts of the software.  The
+potential readers of this document are as follows:
+
+\begin{itemize}
+\item New project members: This document can be a guide for a new project member
+  to easily understand the overall structure and quickly find the
+  relevant modules they are searching for.
+\item Maintainers: The hierarchical structure of the module guide improves the
+  maintainers' understanding when they need to make changes to the system. It is
+  important for a maintainer to update the relevant sections of the document
+  after changes have been made.
+\item Designers: Once the module guide has been written, it can be used to
+  check for consistency, feasibility and flexibility. Designers can verify the
+  system in various ways, such as consistency among modules, feasibility of the
+  decomposition, and flexibility of the design.
+\end{itemize}
+
+The rest of the document is organized as follows. Section
+\ref{SecChange} lists the anticipated and unlikely changes of the software
+requirements. Section \ref{SecMH} summarizes the module decomposition that
+was constructed according to the likely changes. Section \ref{SecConnection}
+specifies the connections between the software requirements and the
+modules. Section \ref{SecMD} gives a detailed description of the
+modules. Section \ref{SecTM} includes two traceability matrices. One checks
+the completeness of the design against the requirements provided in the SRS. The
+other shows the relation between anticipated changes and the modules. Section
+\ref{SecUse} describes the use relation between modules.
+
+\section{Anticipated and Unlikely Changes} \label{SecChange}
+
+This section lists possible changes to the system. According to the likeliness
+of the change, the possible changes are classified into two
+categories. Anticipated changes are listed in Section \ref{SecAchange}, and
+unlikely changes are listed in Section \ref{SecUchange}.
+
+\subsection{Anticipated Changes} \label{SecAchange}
+
+Anticipated changes are the source of the information that is to be hidden
+inside the modules. Ideally, changing one of the anticipated changes will only
+require changing the one module that hides the associated decision. The approach
+adapted here is called design for
+change.
+
+\begin{description}
+\item[\refstepcounter{acnum} \actheacnum \label{acHardware}:] The specific
+  hardware on which the software is running.
+\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The format of the
+  initial input data.
+\item ...
+\end{description}
+
+\subsection{Unlikely Changes} \label{SecUchange}
+
+The module design should be as general as possible. However, a general system is
+more complex. Sometimes this complexity is not necessary. Fixing some design
+decisions at the system architecture stage can simplify the software design. If
+these decision should later need to be changed, then many parts of the design
+will potentially need to be modified. Hence, it is not intended that these
+decisions will be changed.
+
+\begin{description}
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucIO}:] Input/Output devices
+  (Input: File and/or Keyboard, Output: File, Memory, and/or Screen).
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] There will always be
+  a source of input data external to the software.
+\item ...
+\end{description}
+
+\section{Module Hierarchy} \label{SecMH}
+
+This section provides an overview of the module design. Modules are summarized
+in a hierarchy decomposed by secrets in Table \ref{TblMH}. The modules listed
+below, which are leaves in the hierarchy tree, are the modules that will
+actually be implemented.
+
+\begin{description}
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Hardware-Hiding Module
+\item ...
+\end{description}
+
+
+\begin{table}[h!]
+\centering
+\begin{tabular}{p{0.3\textwidth} p{0.6\textwidth}}
+\toprule
+\textbf{Level 1} & \textbf{Level 2}\\
+\midrule
+
+{Hardware-Hiding Module} & ~ \\
+\midrule
+
+\multirow{7}{0.3\textwidth}{Behaviour-Hiding Module} & ?\\
+& ?\\
+& ?\\
+& ?\\
+& ?\\
+& ?\\
+& ?\\ 
+& ?\\
+\midrule
+
+\multirow{3}{0.3\textwidth}{Software Decision Module} & {?}\\
+& ?\\
+& ?\\
+\bottomrule
+
+\end{tabular}
+\caption{Module Hierarchy}
+\label{TblMH}
+\end{table}
+
+\section{Connection Between Requirements and Design} \label{SecConnection}
+
+The design of the system is intended to satisfy the requirements developed in
+the SRS. In this stage, the system is decomposed into modules. The connection
+between requirements and modules is listed in Table \ref{TblRT}.
+
+\section{Module Decomposition} \label{SecMD}
+
+Modules are decomposed according to the principle of ``information hiding''
+proposed by \citet{ParnasEtAl1984}. The \emph{Secrets} field in a module
+decomposition is a brief statement of the design decision hidden by the
+module. The \emph{Services} field specifies \emph{what} the module will do
+without documenting \emph{how} to do it. For each module, a suggestion for the
+implementing software is given under the \emph{Implemented By} title. If the
+entry is \emph{OS}, this means that the module is provided by the operating
+system or by standard programming language libraries.  Also indicate if the
+module will be implemented specifically for the software.
+
+Only the leaf modules in the
+hierarchy have to be implemented. If a dash (\emph{--}) is shown, this means
+that the module is not a leaf and will not have to be implemented. Whether or
+not this module is implemented depends on the programming language
+selected.
+
+\subsection{Hardware Hiding Modules (\mref{mHH})}
+
+\begin{description}
+\item[Secrets:]The data structure and algorithm used to implement the virtual
+  hardware.
+\item[Services:]Serves as a virtual hardware used by the rest of the
+  system. This module provides the interface between the hardware and the
+  software. So, the system can use it to display outputs or to accept inputs.
+\item[Implemented By:] OS
+\end{description}
+
+\subsection{Behaviour-Hiding Module}
+
+\begin{description}
+\item[Secrets:]The contents of the required behaviours.
+\item[Services:]Includes programs that provide externally visible behaviour of
+  the system as specified in the software requirements specification (SRS)
+  documents. This module serves as a communication layer between the
+  hardware-hiding module and the software decision module. The programs in this
+  module will need to change if there are changes in the SRS.
+\item[Implemented By:] --
+\end{description}
+
+\subsubsection{Input Format Module (\mref{mInput})}
+
+\begin{description}
+\item[Secrets:]The format and structure of the input data.
+\item[Services:]Converts the input data into the data structure used by the
+  input parameters module.
+\item[Implemented By:] [Your Program Name Here]
+\end{description}
+
+\subsubsection{Etc.}
+
+
+\subsection{Software Decision Module}
+
+\begin{description}
+\item[Secrets:] The design decision based on mathematical theorems, physical
+  facts, or programming considerations. The secrets of this module are
+  \emph{not} described in the SRS.
+\item[Services:] Includes data structure and algorithms used in the system that
+  do not provide direct interaction with the user. 
+  % Changes in these modules are more likely to be motivated by a desire to
+  % improve performance than by externally imposed changes.
+\item[Implemented By:] --
+\end{description}
+
+\subsubsection{Etc.}
+
+\section{Traceability Matrix} \label{SecTM}
+
+This section shows two traceability matrices: between the modules and the
+requirements and between the modules and the anticipated changes.
+
+% the table should use mref, the requirements should be named, use something
+% like fref
+\begin{table}[H]
+\centering
+\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
+\toprule
+\textbf{Req.} & \textbf{Modules}\\
+\midrule
+R1 & \mref{mHH}, \mref{mInput}, \mref{mParams}, \mref{mControl}\\
+R2 & \mref{mInput}, \mref{mParams}\\
+R3 & \mref{mVerify}\\
+R4 & \mref{mOutput}, \mref{mControl}\\
+R5 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}, \mref{mSeqDS}, \mref{mSolver}, \mref{mPlot}\\
+R6 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}, \mref{mSeqDS}, \mref{mSolver}, \mref{mPlot}\\
+R7 & \mref{mOutput}, \mref{mEnergy}, \mref{mControl}, \mref{mSeqDS}, \mref{mPlot}\\
+R8 & \mref{mOutput}, \mref{mEnergy}, \mref{mControl}, \mref{mSeqDS}, \mref{mPlot}\\
+R9 & \mref{mVerifyOut}\\
+R10 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}\\
+R11 & \mref{mOutput}, \mref{mODEs}, \mref{mEnergy}, \mref{mControl}\\
+\bottomrule
+\end{tabular}
+\caption{Trace Between Requirements and Modules}
+\label{TblRT}
+\end{table}
+
+\begin{table}[H]
+\centering
+\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
+\toprule
+\textbf{AC} & \textbf{Modules}\\
+\midrule
+\acref{acHardware} & \mref{mHH}\\
+\acref{acInput} & \mref{mInput}\\
+\acref{acParams} & \mref{mParams}\\
+\acref{acVerify} & \mref{mVerify}\\
+\acref{acOutput} & \mref{mOutput}\\
+\acref{acVerifyOut} & \mref{mVerifyOut}\\
+\acref{acODEs} & \mref{mODEs}\\
+\acref{acEnergy} & \mref{mEnergy}\\
+\acref{acControl} & \mref{mControl}\\
+\acref{acSeqDS} & \mref{mSeqDS}\\
+\acref{acSolver} & \mref{mSolver}\\
+\acref{acPlot} & \mref{mPlot}\\
+\bottomrule
+\end{tabular}
+\caption{Trace Between Anticipated Changes and Modules}
+\label{TblACT}
+\end{table}
+
+\section{Use Hierarchy Between Modules} \label{SecUse}
+
+In this section, the uses hierarchy between modules is
+provided. \citet{Parnas1978} said of two programs A and B that A {\em uses} B if
+correct execution of B may be necessary for A to complete the task described in
+its specification. That is, A {\em uses} B if there exist situations in which
+the correct functioning of A depends upon the availability of a correct
+implementation of B.  Figure \ref{FigUH} illustrates the use relation between
+the modules. It can be seen that the graph is a directed acyclic graph
+(DAG). Each level of the hierarchy offers a testable and usable subset of the
+system, and modules in the higher level of the hierarchy are essentially simpler
+because they use modules from the lower levels.
+
+\begin{figure}[H]
+\centering
+%\includegraphics[width=0.7\textwidth]{UsesHierarchy.png}
+\caption{Use hierarchy among modules}
+\label{FigUH}
+\end{figure}
+
+%\section*{References}
+
+\bibliographystyle {plainnat}
+\bibliography {MG}
+
+\end{document}
\ No newline at end of file

Doc/Design/MG/README.md

+# Module Guide
+
+The folders and files for the module guide.

Doc/Design/MIS/README.md

+# Module Interface Specification #
+
+Use doxygen (or equivalent) to document the interface for your modules.

Doc/Design/README.md

+# Design Documentation
+
+The folders and files for this folder are as follows:
+
+Describe ...

Doc/DevelopmentPlan/.gitignore

+*.aux
+*.log
+*.gz
\ No newline at end of file

Doc/DevelopmentPlan/DevelopmentPlan.out

+\BOOKMARK [1][-]{section.1}{Team Meeting Plan}{}% 1
+\BOOKMARK [2][-]{subsection.1.1}{Roles}{section.1}% 2
+\BOOKMARK [2][-]{subsection.1.2}{Rules For Agenda}{section.1}% 3
+\BOOKMARK [1][-]{section.2}{Team Communication Plan}{}% 4
+\BOOKMARK [1][-]{section.3}{Team Member Roles}{}% 5
+\BOOKMARK [1][-]{section.4}{Git Workflow Plan}{}% 6
+\BOOKMARK [1][-]{section.5}{Proof of Concept Demonstration Plan}{}% 7
+\BOOKMARK [2][-]{subsection.5.1}{Scope and Feasibility}{section.5}% 8
+\BOOKMARK [2][-]{subsection.5.2}{Potential Challenges and Risks}{section.5}% 9
+\BOOKMARK [2][-]{subsection.5.3}{Software Resources}{section.5}% 10
+\BOOKMARK [2][-]{subsection.5.4}{Demonstration}{section.5}% 11
+\BOOKMARK [1][-]{section.6}{Technology}{}% 12
+\BOOKMARK [1][-]{section.7}{Coding Style}{}% 13
+\BOOKMARK [1][-]{section.8}{Project Schedule}{}% 14
+\BOOKMARK [1][-]{section.9}{Project Review}{}% 15

Doc/DevelopmentPlan/DevelopmentPlan.tex

+\documentclass{article}
+\usepackage{hyperref}
+\usepackage{booktabs}
+\usepackage{tabularx}
+
+\title{\textbf{SE 3XA3: Development Plan\\MineCraft}}
+
+\author{\textbf{Group Number: }307\\
+		\textbf{Group Name: }3 Craftsmen \\
+		\textbf{Members: }\\
+		Hongqing Cao 400053625\\
+		Sida Wang	 400072157\\
+		Weidong Yang 400065354}
+
+\date{}
+
+%\input{../Comments}
+
+\begin{document}
+
+\begin{table}[hp]
+\caption{Revision History} \label{TblRevisionHistory}
+\begin{tabularx}{\textwidth}{llX}
+\toprule
+\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
+\midrule
+Jan 27 & Hongqing & Added team information\\
+Jan 30 & All & Discussed about the content\\
+Jan 30 & Sida Wang & Finished the content of all parts according to the discussion\\
+... & ... & ...\\
+\bottomrule
+\end{tabularx}
+\end{table}
+
+\newpage
+
+\maketitle
+
+\section{Team Meeting Plan}
+Meetings will primarily be held twice a week in the lab room according to the lab schedule. Additional meetings will be held in Thode Library at any time when necessary.
+
+\begin{itemize}
+	\item \textbf{Monday} 12:30 - 14:20,    ITB 236
+	\item \textbf{Thursday} 12:30 - 14:20,    ITB 236
+	\item Occasionally,    Thode Library 1st Floor
+\end{itemize}
+
+\subsection{Roles}
+\textbf{Chair:} Weidong Yang\\
+Responsible for selecting topics and creating the meeting agenda. \\\\
+\textbf{Timekeeper:} Hongqing Cao\\
+Responsible for ensuring the meeting starts and ends on time and keeping the distribution of time on each topic balanced.\\\\
+\textbf{Notetaker:} Sida Wang\\
+Responsible for recording valuable information and summarizing the meetings.\\
+
+\subsection{Rules For Agenda}
+\textbf{Pre-meeting:}
+\begin{itemize}
+	\item The chair will create an agenda sheet for a specific meeting including general topics, activities, and questions to be discussed. Other team members should preview the agenda sheet before the meeting.
+	\item An item checklist may be produced by the chair when multiple topics are to be discussed.
+	\item Any absence for meetings should be reported before the meeting starts.
+\end{itemize}
+\textbf{During meeting:}
+\begin{itemize}
+	\item The timekeeper should ensure that the meeting starts and ends on time.
+	\item The chair will record the attendance of each member at the beginning of the meeting. 
+	\item The meeting will start with a review of the agenda sheet. This will ensure that all team members are fully prepared.
+	\item The meeting will end with a review of the meeting's effectiveness. Each team member should give at least one piece of advice on how to improve the effectiveness of the next meeting. The notetaker will summarize the meeting at the end.
+\end{itemize}
+
+
+\section{Team Communication Plan}
+\begin{itemize}
+	\item \textbf{Facebook Messenger} group chat will be used for internal communications including inquiries, the share of resources, and discussion.
+	\item \textbf{Gitlab} will be the main tool for communications of development changes and updates.
+\end{itemize}
+
+
+\section{Team Member Roles}
+\begin{center}
+\begin{tabular}{ |c|l| } \hline
+\textbf{Team Member} & \textbf{Role(s)}\\\hline
+Weidong Yang & Team Leader, Pyglet \& Algorithm Expert\\\hline
+Hongqing Cao & LaTex \& Documentation Expert\\\hline
+Sida Wang & Scribe, Git Project Manager\\\hline
+\end{tabular}
+\end{center}
+
+\section{Git Workflow Plan}
+The \textbf{Git Master and Feature Branch} will be used to manage software development. One team member will create his/her local branch and work on it. This workflow allows different modules to be developed and tested in each team member's localized branch and do not cause conflicts. Sida will be responsible for the git master controls and will ensure all the files are completed.
+
+\section{Proof of Concept Demonstration Plan}
+\subsection{Scope and Feasibility}
+The original project is implemented using Python within one module. To optimize modularity, our reimplementation will follow the software architecture MVC(Model, View, Controller) model. Since Python is an object-oriented programming language, the modular design is feasible using different classes to implement. 
+\subsection{Potential Challenges and Risks}
+The hardest part of the reimplementation will be Adding new categories of blocks. In the original project, all blocks are static and have no other interactions with the player besides being built or destroyed. In our expectation, new blocks with unique properties such as Lava, which will burn the player out, will be added to the game. These new types of blocks will require more complex interactions with the player, which is difficult to implement. Since the original game is using the content of Minecraft, the customization of the reimplementation heavily depends on the texture resources from the internet. The most difficult part of testing is to test the interaction between the player and the world within the game. Similar to most 3D games, it is hard to mitigate the risk of bugs using traditional testing methods.
+\subsection{Software Resources}
+The Pyglet package provides cross-platform windowing and multimedia library. With Pyglet, visually rich small games can be feasible to build. Pytest provides powerful unit testing and functional testing but does not fully support solutions to integration testing. All the libraries using by this project will be easily installed on either Windows or Linux machines. The game will be delivered as an executable file(generated by Pyinstaller) in order to optimize the portability.
+\subsection{Demonstration}
+The demonstration will be done on both a Windows and a Linux system. On each machine, one team member will click on the icon of the executable game file and play the game. The player will travel the world for a certain distance and have some interactions between different types of blocks. The flying mode will also be activated to show its functionality. To overcome the risk of 3D bugs, some extreme spots(defined by exploratory testing) will be reached.
+
+\section{Technology}
+\begin{itemize}
+	\item \textbf{Programming Language: }Python
+	\item \textbf{Graphical User Interface: }Pyglet
+	\item \textbf{Testing Tools: }Pytest
+	\item \textbf{Documentation Tools: }Doxygen
+	\item \textbf{Version Control: }Gitlab
+	\item \textbf{Other Tools: }Pyinstaller
+\end{itemize}
+
+\section{Coding Style}
+The Coding Style is \textbf{PEP-8} for this project.
+\section{Project Schedule}
+The project schedule can be found \href{https://gitlab.cas.mcmaster.ca/wangs132/minecraft/blob/master/ProjectSchedule/ProjectSchedule_3XA3_307.pdf}{\textbf{HERE}}.
+
+\section{Project Review}
+To be completed in Revision 1.
+\end{document}
\ No newline at end of file

Doc/DevelopmentPlan/README.md

+# Development Plan
+
+The folders and files for this folder are as follows:
+
+Describe ...

Doc/FinalPresentation/README.md

+# Final Presentation
+
+The folders and files for this folder are as follows:
+
+Describe ...

Doc/ProjectApproval/.gitignore

+*.aux
+*.log
+*.gz
\ No newline at end of file

Doc/README.md

+# Documentation folders
+
+The folders and files for this folder are as follows:
+
+Describe ...
\ No newline at end of file

Doc/SRS/.gitignore

+*.aux
+*.log
+*.gz
+*.bib
+*.lof
+*.lot
+*.out
\ No newline at end of file

Doc/SRS/README.md

+# Software Requirements Specification
+
+The folders and files for this folder are as follows:
+
+Describe ...

Doc/SRS/SRS.tex

+\documentclass[12pt, titlepage]{article}
+
+\usepackage{booktabs}
+\usepackage{tabularx}
+\usepackage{hyperref}
+\hypersetup{
+    colorlinks,
+    citecolor=black,
+    filecolor=black,
+    linkcolor=red,
+    urlcolor=blue
+}
+\usepackage[round]{natbib}
+
+\title{SE 3XA3: Software Requirements Specification\\MineCraft}
+
+\author{Group 307, 3 Craftsmen\\
+		Hongqing Cao 400053625\\
+		Sida Wang	 400072157\\
+		Weidong Yang 400065354}
+
+\date{\today}
+
+%\input{../Comments}
+
+\begin{document}
+
+\maketitle
+
+\pagenumbering{roman}
+\tableofcontents
+\listoftables
+\listoffigures
+
+\begin{table}[bp]
+\caption{\bf Revision History}
+\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
+\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
+\midrule
+Jan 27 & 1.0 & Team information\\
+Date 2 & 1.1 & Notes\\
+\bottomrule
+\end{tabularx}
+\end{table}
+
+\newpage
+
+\pagenumbering{arabic}
+
+This document describes the requirements for ....  The template for the Software
+Requirements Specification (SRS) is a subset of the Volere
+template~\citep{RobertsonAndRobertson2012}.  If you make further modifications
+to the template, you should explicity state what modifications were made.
+
+\section{Project Drivers}
+
+\subsection{The Purpose of the Project}
+
+\subsection{The Stakeholders}
+
+\subsubsection{The Client}
+
+\subsubsection{The Customers}
+
+\subsubsection{Other Stakeholders}
+
+\subsection{Mandated Constraints}
+
+\subsection{Naming Conventions and Terminology}
+
+\subsection{Relevant Facts and Assumptions}
+
+User characteristics should go under assumptions.
+
+\section{Functional Requirements}
+
+\subsection{The Scope of the Work and the Product}
+
+\subsubsection{The Context of the Work}
+
+\subsubsection{Work Partitioning}
+
+\subsubsection{Individual Product Use Cases}
+
+\subsection{Functional Requirements}
+
+\section{Non-functional Requirements}
+
+\subsection{Look and Feel Requirements}
+
+\subsection{Usability and Humanity Requirements}
+
+\subsection{Performance Requirements}
+
+\subsection{Operational and Environmental Requirements}
+
+\subsection{Maintainability and Support Requirements}
+
+\subsection{Security Requirements}
+
+\subsection{Cultural Requirements}
+
+\subsection{Legal Requirements}
+
+\subsection{Health and Safety Requirements}
+
+This section is not in the original Volere template, but health and safety are
+issues that should be considered for every engineering project.
+
+\section{Project Issues}
+
+\subsection{Open Issues}
+
+\subsection{Off-the-Shelf Solutions}
+
+\subsection{New Problems}
+
+\subsection{Tasks}
+
+\subsection{Migration to the New Product}
+
+\subsection{Risks}
+
+\subsection{Costs}
+
+\subsection{User Documentation and Training}
+
+\subsection{Waiting Room}
+
+\subsection{Ideas for Solutions}
+
+\bibliographystyle{plainnat}
+
+\bibliography{SRS}
+
+\newpage
+
+\section{Appendix}
+
+This section has been added to the Volere template.  This is where you can place
+additional information.
+
+\subsection{Symbolic Parameters}
+
+The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
+Their values are defined in this section for easy maintenance.
+
+
+\end{document}
\ No newline at end of file