Finished design docs revision 0

PythonChess/Doc/Design/MG/MG.tex

@@ -29,18 +29,16 @@
 \newcommand{\mthemnum}{M\themnum}
 \newcommand{\mref}[1]{M\ref{#1}}
 
-\title{SE 3XA3: Software Requirements Specification\\Title of Project}
+\title{SE 3XA3: Software Requirements Specification\\Module Guide}
 
-\author{Team \#, Team Name
-		\\ Student 1 name and macid
-		\\ Student 2 name and macid
-		\\ Student 3 name and macid
+\author{L02 Team 18, Checkmate Engineering
+		\\ Benjamin Dubois, duboisb
+		\\ Mihail Serafimovski, serafimm
+		\\ Aidan Mariglia, mariglia
 }
 
 \date{\today}
 
-\input{../../Comments}
-
 \begin{document}
 
 \maketitle
@@ -136,7 +134,9 @@ change.
   hardware on which the software is running.
 \item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The format of the
   initial input data.
-\item ...
+\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The operating system on which the software is running.
+\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The desired gamemode of chess being played
+
 \end{description}
 
 \subsection{Unlikely Changes} \label{SecUchange}
@@ -153,7 +153,8 @@ decisions will be changed.
   (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 ...
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] The rules of chess will not change
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] The API's of the libraries in use will not change
 \end{description}
 
 \section{Module Hierarchy} \label{SecMH}
@@ -165,7 +166,13 @@ actually be implemented.
 
 \begin{description}
 \item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Hardware-Hiding Module
-\item ...
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Display Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Input Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Input Format Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Game Model Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Main Controller Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Board Module
+\item \bf{M1} Is not a module which will be implemented in Python-Chess as all input output operations will be handled by the Pygame module.
 \end{description}
 
 
@@ -178,20 +185,20 @@ actually be implemented.
 
 {Hardware-Hiding Module} & ~ \\
 \midrule
-
-\multirow{7}{0.3\textwidth}{Behaviour-Hiding Module} & ?\\
-& ?\\
-& ?\\
-& ?\\
-& ?\\
-& ?\\
-& ?\\ 
-& ?\\
+\multirow{7}{0.3\textwidth}{Behaviour-Hiding Module} &~ \\
+&\begin{itemize}
+    \item Display Module
+    \item Input Module
+    \item Input Format Module
+    \item Main Controller Module
+    \item Game Model Module
+\end{itemize}\\
 \midrule
 
-\multirow{3}{0.3\textwidth}{Software Decision Module} & {?}\\
-& ?\\
-& ?\\
+\multirow{3}{0.3\textwidth}{Software Decision Module}
+&\begin{itemize}
+    \item Board Module
+\end{itemize}\\
 \bottomrule
 
 \end{tabular}
@@ -201,9 +208,7 @@ actually be implemented.
 
 \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}.
+The system was designed to satisfy the requirements provided in the SRS document. The main controller module controls all of the other modules and allows for the program to be executable, this is needed to ensure all functional requirements are satisfied. The display module satisfies the look and feel requirements as it allows for the game board to be displayed to the user and allows for any additional features that are visible to the user. The input module satisfies the usability requirements as it allows for the user to interact with the system simply and easily. The game module drives the physical gameplay and contains the rules and regulations that must be meet in order to play the game, thus this module satisfies the functional requirements of the system. Overall, the system was designed for the user to be able to quickly understand and play a game of chess. The input module allows for the user to play only using their mouse and this eliminates any need for coding knowledge and makes gameplay very simple as using a mouse is common knowledge. This specifically satisfies the requirements of "Usable with no training" and "Usable without understanding of English". The display module shows the entire chess board on the screen and displays large models of pieces, making it very easy for all users to see the board. Also, the board and pieces are a generic white and black colour, so all users can clearly see them. This specifically satisfies the requirements of "Usable by people with colour blindness" and "The product should use simple colours". The entire game is coded and created in Python and PyGame and does not require any additional software. Therefore, it can easily be used on Windows and Linux as these both support Python. All components of the game are internal and the only input that is accepted is from the click of a mouse, thus it is not possible for an external cultural or political violations and these requirements are satisfied. Lastly, the game does not require any kind of log in information or account to play, therefore the system collects no information from the user and the requirement of "The product shall not store user data" is satisfied. 
 
 \section{Module Decomposition} \label{SecMD}
 
@@ -223,7 +228,7 @@ 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})}
+\subsection{Hardware Hiding Modules}
 
 \begin{description}
 \item[Secrets:]The data structure and algorithm used to implement the virtual
@@ -246,16 +251,42 @@ selected.
 \item[Implemented By:] --
 \end{description}
 
-\subsubsection{Input Format Module (\mref{mInput})}
+\subsubsection{Display Module (M2)}
+\begin{description}
+\item[Secrets:]The GUI of the chess game.
+\item[Services:]Allows the user to view the chess game, as well as interact with it by moving pieces.
+\item[Implemented By:] \verb|Display.py|
+\end{description}
+
+\subsubsection{Input Module (M3)}
+\begin{description}
+\item[Secrets:]External input data from the user.
+\item[Services:]Handles input from the user, and processes it into data usable by other modules.
+\item[Implemented By:] \verb|Pygame|
+\end{description}
 
+\subsubsection{Input Format Module (M4)}
 \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]
+\item[Implemented By:] \verb|Pygame|
+\end{description}
+
+\subsubsection{Game Model Module (M5)}
+\begin{description}
+\item[Secrets:]Data structures for the game state and algorithms for modifying the state.
+\item[Services:]Represents the core functionality of the game of chess, handles all game logic and records game state. Serves as the 'Model' from an MVC perspective.
+\item[Implemented By:] \verb|Game.py|
+\end{description}
+
+\subsubsection{Main Controller Module (M6)}
+\begin{description}
+\item[Secrets:]The data passed between the display and input modules and the game model module.
+\item[Services:]Serves as an intermediary between the display/input modules and the game model module. Controls the flow of data between the user interface and core game logic. Serves as the 'Controller' from an MVC perspective.
+\item[Implemented By:] \verb|Main.py|
 \end{description}
 
-\subsubsection{Etc.}
 
 
 \subsection{Software Decision Module}
@@ -271,7 +302,12 @@ selected.
 \item[Implemented By:] --
 \end{description}
 
-\subsubsection{Etc.}
+\subsubsection{Board Module (M7)}
+\begin{description}
+\item[Secrets:]A generic $n \times n$ board data structure. 
+\item[Services:]Represents the chess board that the game model module uses to store the state of the game. Can be used as a general game board.
+\item[Implemented By:] \verb|Board.py|
+\end{description}
 
 \section{Traceability Matrix} \label{SecTM}
 
@@ -286,41 +322,66 @@ requirements and between the modules and the anticipated changes.
 \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}\\
+FR1 & M6\\
+FR2 & M6\\
+FR3 & M6, M5, M2, M7\\
+FR4 & M2, M7, M6\\
+FR5 & M5, M6, M2, M7\\
+FR6 & M3, M4, M5, M6, M7, M2\\
+FR7 & M6\\
+FR8 & M6, M7, M2, M3, M4\\
+FR9 & M6, M5, M7\\
+FR10 & M6, M5, M7\\
+FR11 & M6, M5, M7\\
+FR12 & M3, M4, M2, M5, M6, M7\\
+FR13 & M2\\
+FR14 & M2\\
 \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{Func. Req.} & \textbf{Modules}\\
+\midrule
+NFR1 & M2 \\
+NFR2 & M2 \\
+NFR3 & M2 \\
+NFR4 & M3 \\
+NFR5 & M3 \\
+NFR6 & M2 \\
+NFR7 & M2, M3, M4, M5, M6, M7\\
+NFR8 & M2, M3, M4, M5, M6, M7\\
+NFR9 & M2, M3, M4, M5, M6, M7\\
+NFR10 & M2 \\
+NFR11 & M2, M3, M4, M5, M6, M7\\
+NFR12 & M3, M4 \\
+NFR13 & M2 \\
+NFR14 & M2 \\
+NFR15 & M3, M4 \\
+NFR16 & M2 \\
+NFR17 & M2 \\
+NFR18 & M2, M3 \\
+\bottomrule
+\end{tabular}
+\caption{Trace Between Functional 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}\\
+AC1 & M6 \\
+AC2 & M4 \\
+AC3 & M1 \\
+AC4 & M5, M7 \\
 \bottomrule
 \end{tabular}
 \caption{Trace Between Anticipated Changes and Modules}
@@ -339,10 +400,11 @@ 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.
+\\ \\ Note that the hardware hiding module (M1) is not included in the uses hierarchy, since all other modules use the hardware hiding module.
 
 \begin{figure}[H]
 \centering
-%\includegraphics[width=0.7\textwidth]{UsesHierarchy.png}
+\includegraphics[width=0.7\textwidth]{UsesHierarchy.png}
 \caption{Use hierarchy among modules}
 \label{FigUH}
 \end{figure}
@@ -352,4 +414,5 @@ because they use modules from the lower levels.
 \bibliographystyle {plainnat}
 \bibliography {MG}
 
-\end{document}
\ No newline at end of file
+\end{document}
+

PythonChess/Doc/Design/MIS/README.md

 # Module Interface Specification #
 
-Use doxygen (or equivalent) to document the interface for your modules.
+The doxygen-generated interface for each module implemented in the project.

PythonChess/Doc/Design/README.md

@@ -2,4 +2,5 @@
 
 The folders and files for this folder are as follows:
 
-Describe ...
+MG: The module guide for the project
+MIS: The module interface specification for the project