From 79a2fa6eba1648bf2beaaf534d1fa3247c0d6a01 Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Wed, 1 Jun 2022 20:14:15 +0200
Subject: Some redesigning.

---
 doc/tex/systemDesign.tex | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 doc/tex/systemDesign.tex

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
new file mode 100644
index 0000000..5988ae0
--- /dev/null
+++ b/doc/tex/systemDesign.tex
@@ -0,0 +1,2 @@
+\section{System Design}
+
-- 
cgit v1.2.1


From 6724aeb3ba98c1b9f042344734c2d683e79dfc64 Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Wed, 29 Jun 2022 23:23:09 +0200
Subject: Made full class diagram.

---
 doc/tex/systemDesign.tex | 93 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index 5988ae0..ccd1c48 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -1,2 +1,95 @@
 \section{System Design}
 
+\subsection{Class diagram}
+
+The full class diagram is shown in \fref{fig:fullClasses}
+
+\begin{figure}[h]
+	\begin{center}
+		\includegraphics[width=\textwidth]{diagrams/fullClasses.png}
+		\caption{Full class diagram.}
+		\label{fig:fullClasses}
+	\end{center}
+\end{figure}
+
+% From here
+
+
+\subsection{Engine}
+
+An implementation of GTP, that is, the piece of software which offers the GTP
+interface to other applications.\@ It is designed to be used by a software
+controller but can also be directly run, mostly for debugging purposes. Its
+design is shown in \fref{fig:engine}. The core of the engine is related with
+three components, each with a separate responsibility:
+
+\begin{itemize}
+	\item The IO component is the one called from other applications and offers
+		the text interface. It reads and processes input and calls corresponding
+		commands from the core of the engine.
+	\item The EngineBoard component stores the state of the match, recording
+		information such as the history of boards positions and whose turn goes
+		next. The engine core uses it for these state-storing purposes.
+	\item The EngineAI component is responsible of analyzing the match and
+		generate moves. The engine core uses it when a decision has to be made
+		by the AI, such as when a move needs to be generated by the engine.
+\end{itemize}
+
+\begin{figure}[h]
+	\begin{center}
+		\includegraphics[width=\textwidth]{diagrams/engineModule.png}
+		\caption{Design of the GTP engine.}\label{fig:engine}
+	\end{center}
+\end{figure}
+
+\subsection{Modules}
+
+One module to store the state of the game and the game tree. One module to parse
+moves. One module to read and write SGF files. Modules are shown in
+\fref{fig:modules}.
+
+\begin{figure}[h]
+	\begin{center}
+		\includegraphics[width=\textwidth]{diagrams/modules.png}
+		\caption{Modules.}\label{fig:modules}
+	\end{center}
+\end{figure}
+
+\subsection{Representation of a match}
+
+A regular Go match is composed of a list of moves. But since game review and
+variants exploration is an important part of Go learning, \program{} allows for
+navigation back and forth through the board states of a match and for new
+variants to be created from each of these board states. Therefore, a match is
+represented as a tree of moves. The state of the board at any given move must
+also be stored so liberties, captures count and legality of moves can be
+addressed, so it is represented with its own class, which holds a reference both
+to the game tree and the current move. Moves depend on a representation of the
+game board to have access to its current layout and count of captured stones.
+These classes and their relationships can be seen in
+\fref{fig:gameRepresentation}.
+
+\begin{figure}[h]
+	\begin{center}
+		\includegraphics[width=0.7\textwidth]{diagrams/gameRepresentation.png}
+		\caption{A game is represented as a tree of moves.}\label{fig:gameRepresentation}
+	\end{center}
+\end{figure}
+
+\subsection{SGF}
+
+To parse SGF files a lexer and parser have been implemented using PLY.\@ The
+result of the parsing is an AST (Annotated Syntax Tree) reflecting the contents
+of the text input, each node with zero or more properties, and with the ability
+to convert themselves and their corresponding subtree into a GameTree. This is
+done for the root node, since from the SGF specification there are some
+properties only usable in the root node, like those which specify general game
+information and properties such as rank of players or komi. These components are
+shown in \fref{fig:sgfModule}.
+
+\begin{figure}[h]
+	\begin{center}
+		\includegraphics[width=\textwidth]{diagrams/sgfModule.png}
+		\caption{Components of the SGF file parsing module.}\label{fig:sgfModule}
+	\end{center}
+\end{figure}
-- 
cgit v1.2.1


From 4cc55348c8dbb1902a1246fba66237d5c59f0349 Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Fri, 1 Jul 2022 15:40:57 +0200
Subject: Finished writing documentation.

---
 doc/tex/systemDesign.tex | 327 ++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 278 insertions(+), 49 deletions(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index ccd1c48..80a2ccb 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -1,95 +1,324 @@
 \section{System Design}
 
-\subsection{Class diagram}
+\subsection{Class Diagram}
 
-The full class diagram is shown in \fref{fig:fullClasses}
+The full class diagram is shown in \fref{fig:fullClasses}.
 
 \begin{figure}[h]
 	\begin{center}
-		\includegraphics[width=\textwidth]{diagrams/fullClasses.png}
-		\caption{Full class diagram.}
-		\label{fig:fullClasses}
+		\makebox[0pt]{\begin{minipage}{1.2\textwidth}
+			\includegraphics[width=\textwidth]{diagrams/fullClasses.png}
+			\caption{Full class diagram.}
+			\label{fig:fullClasses}
+		\end{minipage}}
 	\end{center}
 \end{figure}
 
-% From here
+The design of each system of the diagram is explained after this section
+together with diagrams for each subsystem, since the full class diagram can be
+too big to be comfortably analyzed.
 
+\subsection{Game}
+
+\begin{figure}[h]
+	\begin{center}
+		\includegraphics[width=0.55\textwidth]{diagrams/gameModule.png}
+		\caption{Design of the implementation of the game of Go.}
+		\label{fig:game}
+		A game is represented as a tree of moves.
+	\end{center}
+\end{figure}
+
+A regular Go match is composed of a list of moves. But since game review and
+variants exploration is an important part of Go learning, \program{} and most
+playing and analysis existing programs allow for navigation back and forth
+through the board states of a match and for new variants to be created from each
+of these board states. Therefore, a match is represented as a tree of moves. The
+GameMove class has the information about a specific move and also a reference to
+the previous move and to a list of following moves, implementing this tree
+structure and allowing for navigating both forward and backwards in the move
+history.
+
+The state of the board at any given move must be stored so liberties, captures
+count and legality of moves can be addressed, so it is represented with the
+GameState class, which holds a reference to the current move.
+
+Moves depend on a representation of the game board to have access to its current
+layout and count of captured stones. There are also many logic operations needed
+to be performed on the board, such as getting the stones in a group, counting
+their liberties or checking if a move is playable. The layout of the board and
+these operations are implemented as the GameBoard class.
+
+A game can be started by the executable \texttt{go.py}.
+
+These classes and their relationships can be seen in \fref{fig:game}.
 
 \subsection{Engine}
 
+\begin{figure}[h]
+	\begin{center}
+		\includegraphics[width=0.8\textwidth]{diagrams/engineModule.png}
+		\caption{Design of the GTP engine.}\label{fig:engine}
+	\end{center}
+\end{figure}
+
 An implementation of GTP, that is, the piece of software which offers the GTP
-interface to other applications.\@ It is designed to be used by a software
+interface to other applications. It is designed to be used by a software
 controller but can also be directly run, mostly for debugging purposes. Its
 design is shown in \fref{fig:engine}. The core of the engine is related with
 three components, each with a separate responsibility:
 
 \begin{itemize}
-	\item The IO component is the one called from other applications and offers
-		the text interface. It reads and processes input and calls corresponding
-		commands from the core of the engine.
-	\item The EngineBoard component stores the state of the match, recording
-		information such as the history of boards positions and whose turn goes
-		next. The engine core uses it for these state-storing purposes.
-	\item The EngineAI component is responsible of analyzing the match and
-		generate moves. The engine core uses it when a decision has to be made
-		by the AI, such as when a move needs to be generated by the engine.
+
+	\item The ImagoIO component is the one imported from executables or other
+		applications and offers the text interface. It reads and processes input
+		and calls corresponding commands from the core of the engine.
+
+	\item The GameEngine contains the logic of the commands available from the
+		IO component. It uses a GameState to keep a record of the game and uses
+		a DecisionAlgorithm to generate moves.
+
+	\item The DecisionAlgorithm component is responsible of analyzing the match
+		and generate moves. The engine core uses it when a decision has to be
+		made by the AI, such as when a move needs to be generated by the engine.
+
+\end{itemize}
+
+Two implementations of DecisionAlgorithm have been made: one for the Monte
+Carlo Tree Search algorithm (on the MCTS class) and the other for neural
+networks (on the Keras class).
+
+The Keras class also makes use of the NeuralNetwork class, which offers
+functions for creating, training, saving and using neural network models. The
+designs of the network are implemented in the subclasses DenseNeuralNetwork and
+ConvNeuralNetwork as examples of dense and convolutional networks, respectively.
+
+The engine can be started with the executable \texttt{imagocli.py}.
+
+\subsubsection{Monte Carlo Tree Search Explained}
+
+Monte Carlo Tree Search is an algorithm that can be useful for exploring
+decision trees. It was used by AlphaGo in conjunction with neural networks as
+explained in the AlphaGo 2016 paper\cite{natureAlphaGo2016}.
+
+The algorithm assigns a score to each explored node based on how likely the
+player who makes the corresponding move is to win and updates this score on each
+exploration cycle.
+
+The exploration of the tree has 4 steps:
+
+\begin{enumerate}
+
+	\item \textbf{Selection}: The most promising move with unexplored children
+		is selected for exploration. Unexplored children are viable moves which
+		are not yet part of the tree.
+
+	\item \textbf{Expansion}: An unexplored children of the selected move is
+		added to the tree. This children is selected at random.
+
+	\item \textbf{Simulation}: The score of the new move is evaluated by playing
+		random matches from it.
+
+	\item \textbf{Backpropagation}: The score of the new move, as well as its
+		previous moves up to the root of the tree, is updated based on the
+		results of the simulation.
+
+\end{enumerate}
+
+The suggested move is the children of the current move with the best score from
+the perspective of the player which has to make the move.
+
+The implementation of the algorithm will use the existing GameMove class from
+the Game System to access the game logic it needs, such as to get the possible
+children from a node or to simulate random games.
+
+\subsubsection{Neural Networks Explained}
+
+A neural network is composed of nodes or ``neurons''. Each node contains a value
+named weight. During execution the node receives a numeric input, multiplies it
+for its weight and applies a function called activation function to the result.
+
+Nodes are organized in layers so that a network contains several layers and each
+layer one or more neurons. The input to the network forms the input layer, which
+contents are forwarded to the second layer. The second layer applies the weight
+and activation function as discussed before in each of its nodes and the result
+is forwarded to the next layer, and so on. At the end the last layer, called the
+output layer, contains the result of the input evaluation. Each layer can have a
+unique activation function for all its nodes and a different strategy of
+connecting to the previous and next layers.
+
+Several kinds of layers have been used in this project:
+
+\begin{itemize}
+
+	\item \textbf{Dense layers}, which connects each of its nodes to each of the
+		nodes of the previous layers.
+
+	\item \textbf{Convolutional layers}, which process their input by applying
+		a filter function to adjacent values. In the case of this project, the
+		board is filtered by grouping its vertices in 3x3 squares. The aim of
+		these layers is to detect patterns in the input, such as curves, edges
+		or more complex shapes, so they are used a lot on neural networks
+		processing images. They are used in this project because a configuration
+		of the Go board is not that different from a two-dimensional image.
+
+	\item \textbf{Max pooling layers}, which process their input in a similar
+		way to convolutional layers, but reducing the size of the input by
+		keeping the highest value in each of the groups they process. This
+		reduction accentuates the patterns detected by convolutional layers and
+		helps on the detection of bigger, more complex patterns.
+
+	\item \textbf{Flatten layers}, which just change the shape of the input so
+		that all the values are on one dimension.
+
 \end{itemize}
 
+Combinations of these layers have been used to define two neural networks.
+
+First, a network using mainly dense layers as an example of a more general
+purpose design of a network.
+
+Then, a network with convolutional and max pooling layers to compare the
+approach used on image processing to the more general one and studying its
+utility on the analysis of the Go board.
+
+These networks have been implemented on the DenseNeuralNetwork and
+ConvNeuralNetwork classes, respectively.
+
+The networks have been designed to process boards of size 9x9, which is the
+introductory size to the game. It is the easiest both for the hardware to handle
+and for the analysis of results while keeping able to support meaningful
+matches.
+
+Both networks have the same design for their input and output.
+
+Their input is a three-dimensional matrix of size 9x9x2 with values either 0 or
+1. It represents two views of the board, one with ones as the stones of a player
+and the other with ones as the stones of the other player.
+
+Their output is a vector with 82 elements of type float. Classification networks
+typically use a vector of probabilities with one element for each class they are
+trying to classify. Here the classes are the 81 positions of the 9x9 board and
+the pass move, hence 82 total elements. Each element signifies the chance of
+playing that move for the input board position, so the element with the highest
+value represents the suggested move.
+
+\subsubsection{Dense Neural Network Design}
+
+\begin{listing}[h]
+	\inputminted{text}{listings/denseModel.txt}
+	\caption{Dense neural network model.}
+	\label{code:denseModel}
+\end{listing}
+
 \begin{figure}[h]
 	\begin{center}
-		\includegraphics[width=\textwidth]{diagrams/engineModule.png}
-		\caption{Design of the GTP engine.}\label{fig:engine}
+		\includegraphics[width=0.7\textwidth]{img/models/denseModel.png}
+		\caption{Dense neural network model.}
+		\label{fig:denseNN}
 	\end{center}
 \end{figure}
 
-\subsection{Modules}
+This network first uses two dense layers with 81 nodes each. This number has
+been selected so each node can have as input each of the vertices of the board.
+A flatten layer acts then to make the output one-dimensional, and a final dense
+layer provides the vector containing the likelihood of each possible move.
 
-One module to store the state of the game and the game tree. One module to parse
-moves. One module to read and write SGF files. Modules are shown in
-\fref{fig:modules}.
+The design of this network is shown in \flist{code:denseModel} and
+\fref{fig:denseNN} as provided by Keras' summary and plot\_model functions
+respectively.
+
+\subsubsection{Convolutional Neural Network Design}
+
+\begin{listing}[h]
+	\inputminted{text}{listings/convModel.txt}
+	\caption{Convolutional neural network model.}
+	\label{code:convModel}
+\end{listing}
 
 \begin{figure}[h]
 	\begin{center}
-		\includegraphics[width=\textwidth]{diagrams/modules.png}
-		\caption{Modules.}\label{fig:modules}
+		\includegraphics[width=0.7\textwidth]{img/models/convModel.png}
+		\caption{Convolutional neural network model.}
+		\label{fig:convNN}
 	\end{center}
 \end{figure}
 
-\subsection{Representation of a match}
+This network uses two pairs of convolutional and max pooling layers with the aim
+of being trained to recognize patterns on the board. A flatten layer acts then
+to make the output one-dimensional, and a final dense layer provides the vector
+containing the likelihood of each possible move.
 
-A regular Go match is composed of a list of moves. But since game review and
-variants exploration is an important part of Go learning, \program{} allows for
-navigation back and forth through the board states of a match and for new
-variants to be created from each of these board states. Therefore, a match is
-represented as a tree of moves. The state of the board at any given move must
-also be stored so liberties, captures count and legality of moves can be
-addressed, so it is represented with its own class, which holds a reference both
-to the game tree and the current move. Moves depend on a representation of the
-game board to have access to its current layout and count of captured stones.
-These classes and their relationships can be seen in
-\fref{fig:gameRepresentation}.
+The design of this network is shown in \flist{code:convModel} and
+\fref{fig:convNN} as provided by Keras' summary and plot\_model functions
+respectively.
+
+\subsection{Training}
 
 \begin{figure}[h]
 	\begin{center}
-		\includegraphics[width=0.7\textwidth]{diagrams/gameRepresentation.png}
-		\caption{A game is represented as a tree of moves.}\label{fig:gameRepresentation}
+		\includegraphics[width=\textwidth]{diagrams/trainingModule.png}
+		\caption{Components of the SGF file parsing module.}
+		\label{fig:trainingModule}
+		Components not showing a capital C are not classes, as in they not
+		follow the object-oriented paradigm and do not implement any classes,
+		only functions.
 	\end{center}
 \end{figure}
 
-\subsection{SGF}
+Neural networks can be powerful machine learning algorithms, but they have to be
+trained first so they can provide meaningful results. For a Go AI it makes sense
+to have its algorithms trained on Go games. There exists a common text format to
+store Go games: SGF. If the system is able to process SGF files, it can provide
+the games stored on them to the neural networks for training. And so the need
+for an SGF parser arises.
 
 To parse SGF files a lexer and parser have been implemented using PLY.\@ The
 result of the parsing is an AST (Annotated Syntax Tree) reflecting the contents
 of the text input, each node with zero or more properties, and with the ability
-to convert themselves and their corresponding subtree into a GameTree. This is
-done for the root node, since from the SGF specification there are some
+to convert themselves and their corresponding subtree into a GameMove tree. This
+is done for the root node, since from the SGF specification there are some
 properties only usable in the root node, like those which specify general game
-information and properties such as rank of players or komi. These components are
-shown in \fref{fig:sgfModule}.
+information and properties such as rank of players or komi.
 
-\begin{figure}[h]
-	\begin{center}
-		\includegraphics[width=\textwidth]{diagrams/sgfModule.png}
-		\caption{Components of the SGF file parsing module.}\label{fig:sgfModule}
-	\end{center}
-\end{figure}
+Here follows an explanation of the role and motivation before each component of
+the Training module to show how these previous concerns have been addressed and
+solved. These components are shown in \fref{fig:trainingModule}.
+
+\begin{itemize}
+
+	\item \textbf{SGF}: Provides a high-level method to convert a path to a SGF
+		file to a GameMove tree.
+
+	\item \textbf{sgfyacc}: The implementation of a SGF parser using PLY. Takes
+		the tokens generated by \textbf{sgflex} and creates an ASTNode tree from
+		them.
+
+	\item \textbf{sgflex}: The implementation of a SGF lexer using PLY.\@ Takes
+		text input and generates the tokens of the SGF language from them.
+
+	\item \textbf{ASTNode}: The AST resulting from the parsing of a SGF file.
+		Has a method to convert it to a tree of GameMove and so obtain the
+		contents of the SGF in the internal representation used by the project's
+		systems.
+
+	\item \textbf{Property}: The representation of a property of an ASTNode
+		tree. Each property is made of a name and one or more values and this
+		class helps handling this specific situation.
+
+The training can be started with the executable \texttt{train.py}.
+
+\end{itemize}
+
+%\subsection{Modules}
+%
+%One module to store the state of the game and the game tree. One module to parse
+%moves. One module to read and write SGF files. Modules are shown in
+%\fref{fig:modules}.
+%
+%\begin{figure}[h]
+%	\begin{center}
+%		\includegraphics[width=\textwidth]{diagrams/modules.png}
+%		\caption{Modules.}\label{fig:modules}
+%	\end{center}
+%\end{figure}
-- 
cgit v1.2.1


From 9e0e14a9fceb6de53a69bc2b247ce284717ca25f Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Thu, 25 Aug 2022 21:01:41 +0200
Subject: Added space before cites.

---
 doc/tex/systemDesign.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index 80a2ccb..7975276 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -99,7 +99,7 @@ The engine can be started with the executable \texttt{imagocli.py}.
 
 Monte Carlo Tree Search is an algorithm that can be useful for exploring
 decision trees. It was used by AlphaGo in conjunction with neural networks as
-explained in the AlphaGo 2016 paper\cite{natureAlphaGo2016}.
+explained in the AlphaGo 2016 paper \cite{natureAlphaGo2016}.
 
 The algorithm assigns a score to each explored node based on how likely the
 player who makes the corresponding move is to win and updates this score on each
-- 
cgit v1.2.1


From e74f404f9cb5f0d5752178ab8baf4055c0a10f84 Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Wed, 26 Oct 2022 20:43:34 +0200
Subject: Adding examples of protocols.

---
 doc/tex/systemDesign.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index 7975276..f54032f 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -224,7 +224,7 @@ been selected so each node can have as input each of the vertices of the board.
 A flatten layer acts then to make the output one-dimensional, and a final dense
 layer provides the vector containing the likelihood of each possible move.
 
-The design of this network is shown in \flist{code:denseModel} and
+The design of this network is shown in \lref{code:denseModel} and
 \fref{fig:denseNN} as provided by Keras' summary and plot\_model functions
 respectively.
 
@@ -249,7 +249,7 @@ of being trained to recognize patterns on the board. A flatten layer acts then
 to make the output one-dimensional, and a final dense layer provides the vector
 containing the likelihood of each possible move.
 
-The design of this network is shown in \flist{code:convModel} and
+The design of this network is shown in \lref{code:convModel} and
 \fref{fig:convNN} as provided by Keras' summary and plot\_model functions
 respectively.
 
-- 
cgit v1.2.1


From 3b78e9f3751dfc7c77a7d137d0dbab04afcb23f5 Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Fri, 28 Oct 2022 19:09:24 +0200
Subject: Adding glossary.

---
 doc/tex/systemDesign.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index f54032f..3e82698 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -279,7 +279,7 @@ of the text input, each node with zero or more properties, and with the ability
 to convert themselves and their corresponding subtree into a GameMove tree. This
 is done for the root node, since from the SGF specification there are some
 properties only usable in the root node, like those which specify general game
-information and properties such as rank of players or komi.
+information and properties such as rank of players or \gls{komi}.
 
 Here follows an explanation of the role and motivation before each component of
 the Training module to show how these previous concerns have been addressed and
-- 
cgit v1.2.1


From e8b9bf589e698b51e55ae59693b5bb0293f86a26 Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Tue, 1 Nov 2022 18:06:40 +0100
Subject: Added SGF and GTP instances as acronyms.

---
 doc/tex/systemDesign.tex | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index 3e82698..f0762e8 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -58,11 +58,11 @@ These classes and their relationships can be seen in \fref{fig:game}.
 \begin{figure}[h]
 	\begin{center}
 		\includegraphics[width=0.8\textwidth]{diagrams/engineModule.png}
-		\caption{Design of the GTP engine.}\label{fig:engine}
+		\caption{Design of the \acrshort{gtp} engine.}\label{fig:engine}
 	\end{center}
 \end{figure}
 
-An implementation of GTP, that is, the piece of software which offers the GTP
+An implementation of \acrshort{gtp}, that is, the piece of software which offers the \acrshort{gtp}
 interface to other applications. It is designed to be used by a software
 controller but can also be directly run, mostly for debugging purposes. Its
 design is shown in \fref{fig:engine}. The core of the engine is related with
@@ -258,7 +258,7 @@ respectively.
 \begin{figure}[h]
 	\begin{center}
 		\includegraphics[width=\textwidth]{diagrams/trainingModule.png}
-		\caption{Components of the SGF file parsing module.}
+		\caption{Components of the \acrshort{sgf} file parsing module.}
 		\label{fig:trainingModule}
 		Components not showing a capital C are not classes, as in they not
 		follow the object-oriented paradigm and do not implement any classes,
@@ -269,15 +269,15 @@ respectively.
 Neural networks can be powerful machine learning algorithms, but they have to be
 trained first so they can provide meaningful results. For a Go AI it makes sense
 to have its algorithms trained on Go games. There exists a common text format to
-store Go games: SGF. If the system is able to process SGF files, it can provide
+store Go games: \acrshort{sgf}. If the system is able to process \acrshort{sgf} files, it can provide
 the games stored on them to the neural networks for training. And so the need
-for an SGF parser arises.
+for an \acrshort{sgf} parser arises.
 
-To parse SGF files a lexer and parser have been implemented using PLY.\@ The
+To parse \acrshort{sgf} files a lexer and parser have been implemented using PLY.\@ The
 result of the parsing is an AST (Annotated Syntax Tree) reflecting the contents
 of the text input, each node with zero or more properties, and with the ability
 to convert themselves and their corresponding subtree into a GameMove tree. This
-is done for the root node, since from the SGF specification there are some
+is done for the root node, since from the \acrshort{sgf} specification there are some
 properties only usable in the root node, like those which specify general game
 information and properties such as rank of players or \gls{komi}.
 
@@ -287,19 +287,19 @@ solved. These components are shown in \fref{fig:trainingModule}.
 
 \begin{itemize}
 
-	\item \textbf{SGF}: Provides a high-level method to convert a path to a SGF
+	\item \textbf{\acrshort{sgf}}: Provides a high-level method to convert a path to a \acrshort{sgf}
 		file to a GameMove tree.
 
-	\item \textbf{sgfyacc}: The implementation of a SGF parser using PLY. Takes
+	\item \textbf{sgfyacc}: The implementation of a \acrshort{sgf} parser using PLY. Takes
 		the tokens generated by \textbf{sgflex} and creates an ASTNode tree from
 		them.
 
-	\item \textbf{sgflex}: The implementation of a SGF lexer using PLY.\@ Takes
-		text input and generates the tokens of the SGF language from them.
+	\item \textbf{sgflex}: The implementation of a \acrshort{sgf} lexer using PLY.\@ Takes
+		text input and generates the tokens of the \acrshort{sgf} language from them.
 
-	\item \textbf{ASTNode}: The AST resulting from the parsing of a SGF file.
+	\item \textbf{ASTNode}: The AST resulting from the parsing of a \acrshort{sgf} file.
 		Has a method to convert it to a tree of GameMove and so obtain the
-		contents of the SGF in the internal representation used by the project's
+		contents of the \acrshort{sgf} in the internal representation used by the project's
 		systems.
 
 	\item \textbf{Property}: The representation of a property of an ASTNode
@@ -313,7 +313,7 @@ The training can be started with the executable \texttt{train.py}.
 %\subsection{Modules}
 %
 %One module to store the state of the game and the game tree. One module to parse
-%moves. One module to read and write SGF files. Modules are shown in
+%moves. One module to read and write \acrshort{sgf} files. Modules are shown in
 %\fref{fig:modules}.
 %
 %\begin{figure}[h]
-- 
cgit v1.2.1


From 2d895e4abb26eccefe6b4bc201fd60eb79600e3e Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Sat, 13 May 2023 19:44:54 +0200
Subject: Added visualization of SGF example.

---
 doc/tex/systemDesign.tex | 88 ++++++++++++++++++++++++++----------------------
 1 file changed, 48 insertions(+), 40 deletions(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index f0762e8..7a5db7b 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -34,20 +34,20 @@ variants exploration is an important part of Go learning, \program{} and most
 playing and analysis existing programs allow for navigation back and forth
 through the board states of a match and for new variants to be created from each
 of these board states. Therefore, a match is represented as a tree of moves. The
-GameMove class has the information about a specific move and also a reference to
+\texttt{GameMove} class has the information about a specific move and also a reference to
 the previous move and to a list of following moves, implementing this tree
 structure and allowing for navigating both forward and backwards in the move
 history.
 
 The state of the board at any given move must be stored so liberties, captures
 count and legality of moves can be addressed, so it is represented with the
-GameState class, which holds a reference to the current move.
+\texttt{GameState} class, which holds a reference to the current move.
 
 Moves depend on a representation of the game board to have access to its current
 layout and count of captured stones. There are also many logic operations needed
 to be performed on the board, such as getting the stones in a group, counting
 their liberties or checking if a move is playable. The layout of the board and
-these operations are implemented as the GameBoard class.
+these operations are implemented as the \texttt{GameBoard} class.
 
 A game can be started by the executable \texttt{go.py}.
 
@@ -74,24 +74,26 @@ three components, each with a separate responsibility:
 		applications and offers the text interface. It reads and processes input
 		and calls corresponding commands from the core of the engine.
 
-	\item The GameEngine contains the logic of the commands available from the
-		IO component. It uses a GameState to keep a record of the game and uses
-		a DecisionAlgorithm to generate moves.
+	\item The \texttt{GameEngine} contains the logic of the commands available
+		from the IO component. It uses a \texttt{GameState} to keep a record of
+		the game and uses a \texttt{DecisionAlgorithm} to generate moves.
 
-	\item The DecisionAlgorithm component is responsible of analyzing the match
-		and generate moves. The engine core uses it when a decision has to be
-		made by the AI, such as when a move needs to be generated by the engine.
+	\item The \texttt{DecisionAlgorithm} component is responsible of analyzing
+		the match and generate moves. The engine core uses it when a decision
+		has to be made by the AI, such as when a move needs to be generated by
+		the engine.
 
 \end{itemize}
 
-Two implementations of DecisionAlgorithm have been made: one for the Monte
-Carlo Tree Search algorithm (on the MCTS class) and the other for neural
-networks (on the Keras class).
+Two implementations of \texttt{DecisionAlgorithm} have been made: one for the
+Monte Carlo Tree Search algorithm (on the \texttt{MCTS} class) and the other for
+neural networks (on the \texttt{Keras} class).
 
-The Keras class also makes use of the NeuralNetwork class, which offers
-functions for creating, training, saving and using neural network models. The
-designs of the network are implemented in the subclasses DenseNeuralNetwork and
-ConvNeuralNetwork as examples of dense and convolutional networks, respectively.
+The \texttt{Keras} class also makes use of the \texttt{NeuralNetwork} class,
+which offers functions for creating, training, saving and using neural network
+models. The designs of the network are implemented in the subclasses
+\texttt{DenseNeuralNetwork} and \texttt{ConvNeuralNetwork} as examples of dense
+and convolutional networks, respectively.
 
 The engine can be started with the executable \texttt{imagocli.py}.
 
@@ -128,9 +130,9 @@ The exploration of the tree has 4 steps:
 The suggested move is the children of the current move with the best score from
 the perspective of the player which has to make the move.
 
-The implementation of the algorithm will use the existing GameMove class from
-the Game System to access the game logic it needs, such as to get the possible
-children from a node or to simulate random games.
+The implementation of the algorithm will use the existing \texttt{GameMove}
+class from the Game System to access the game logic it needs, such as to get the
+possible children from a node or to simulate random games.
 
 \subsubsection{Neural Networks Explained}
 
@@ -182,8 +184,8 @@ Then, a network with convolutional and max pooling layers to compare the
 approach used on image processing to the more general one and studying its
 utility on the analysis of the Go board.
 
-These networks have been implemented on the DenseNeuralNetwork and
-ConvNeuralNetwork classes, respectively.
+These networks have been implemented on the \texttt{DenseNeuralNetwork} and \\
+\texttt{ConvNeuralNetwork} classes, respectively.
 
 The networks have been designed to process boards of size 9x9, which is the
 introductory size to the game. It is the easiest both for the hardware to handle
@@ -273,13 +275,14 @@ store Go games: \acrshort{sgf}. If the system is able to process \acrshort{sgf}
 the games stored on them to the neural networks for training. And so the need
 for an \acrshort{sgf} parser arises.
 
-To parse \acrshort{sgf} files a lexer and parser have been implemented using PLY.\@ The
-result of the parsing is an AST (Annotated Syntax Tree) reflecting the contents
-of the text input, each node with zero or more properties, and with the ability
-to convert themselves and their corresponding subtree into a GameMove tree. This
-is done for the root node, since from the \acrshort{sgf} specification there are some
-properties only usable in the root node, like those which specify general game
-information and properties such as rank of players or \gls{komi}.
+To parse \acrshort{sgf} files a lexer and parser have been implemented using
+PLY.\@ The result of the parsing is an AST (Annotated Syntax Tree) reflecting
+the contents of the text input, each node with zero or more properties, and with
+the ability to convert themselves and their corresponding subtree into a
+\texttt{GameMove} tree. This is done for the root node, since from the
+\acrshort{sgf} specification there are some properties only usable in the root
+node, like those which specify general game information and properties such as
+rank of players or \gls{komi}.
 
 Here follows an explanation of the role and motivation before each component of
 the Training module to show how these previous concerns have been addressed and
@@ -288,23 +291,24 @@ solved. These components are shown in \fref{fig:trainingModule}.
 \begin{itemize}
 
 	\item \textbf{\acrshort{sgf}}: Provides a high-level method to convert a path to a \acrshort{sgf}
-		file to a GameMove tree.
+		file to a \texttt{GameMove} tree.
 
 	\item \textbf{sgfyacc}: The implementation of a \acrshort{sgf} parser using PLY. Takes
-		the tokens generated by \textbf{sgflex} and creates an ASTNode tree from
-		them.
+		the tokens generated by \textbf{sgflex} and creates an \texttt{ASTNode}
+		tree from them.
 
-	\item \textbf{sgflex}: The implementation of a \acrshort{sgf} lexer using PLY.\@ Takes
-		text input and generates the tokens of the \acrshort{sgf} language from them.
+	\item \textbf{sgflex}: The implementation of a \acrshort{sgf} lexer using
+		PLY.\@ Takes text input and generates the tokens of the \acrshort{sgf}
+		language from them.
 
-	\item \textbf{ASTNode}: The AST resulting from the parsing of a \acrshort{sgf} file.
-		Has a method to convert it to a tree of GameMove and so obtain the
-		contents of the \acrshort{sgf} in the internal representation used by the project's
-		systems.
+	\item \textbf{ASTNode}: The AST resulting from the parsing of a
+		\acrshort{sgf} file. Has a method to convert it to a tree of
+		\texttt{GameMove} and so obtain the contents of the \acrshort{sgf} in
+		the internal representation used by the project's systems.
 
-	\item \textbf{Property}: The representation of a property of an ASTNode
-		tree. Each property is made of a name and one or more values and this
-		class helps handling this specific situation.
+	\item \textbf{Property}: The representation of a property of an
+		\texttt{ASTNode} tree. Each property is made of a name and one or more
+		values and this class helps handling this specific situation.
 
 The training can be started with the executable \texttt{train.py}.
 
@@ -322,3 +326,7 @@ The training can be started with the executable \texttt{train.py}.
 %		\caption{Modules.}\label{fig:modules}
 %	\end{center}
 %\end{figure}
+
+%\subsection{Technical Testing Plan Specification}
+
+%TODO
-- 
cgit v1.2.1


From 88fbf5f8919211cfa06116a76f42fb26ec9f2e18 Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Fri, 2 Jun 2023 13:02:08 +0200
Subject: Second revision and added rules of the game.

---
 doc/tex/systemDesign.tex | 240 ++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 187 insertions(+), 53 deletions(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index 7a5db7b..78fb2dc 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -1,5 +1,8 @@
 \section{System Design}
 
+This section explains the design of the component systems of \program{}, the
+algorithms used and how they are to be implemented.
+
 \subsection{Class Diagram}
 
 The full class diagram is shown in \fref{fig:fullClasses}.
@@ -15,7 +18,7 @@ The full class diagram is shown in \fref{fig:fullClasses}.
 \end{figure}
 
 The design of each system of the diagram is explained after this section
-together with diagrams for each subsystem, since the full class diagram can be
+along with diagrams for each subsystem, since the full class diagram can be
 too big to be comfortably analyzed.
 
 \subsection{Game}
@@ -30,14 +33,14 @@ too big to be comfortably analyzed.
 \end{figure}
 
 A regular Go match is composed of a list of moves. But since game review and
-variants exploration is an important part of Go learning, \program{} and most
+exploration of variants is an important part of Go learning, \program{} and most
 playing and analysis existing programs allow for navigation back and forth
 through the board states of a match and for new variants to be created from each
 of these board states. Therefore, a match is represented as a tree of moves. The
-\texttt{GameMove} class has the information about a specific move and also a reference to
-the previous move and to a list of following moves, implementing this tree
-structure and allowing for navigating both forward and backwards in the move
-history.
+\texttt{GameMove} class has the information about a specific move and also a
+reference to the previous move and to a list of following moves, implementing
+this tree structure and allowing for navigating both forward and backwards in
+the move history.
 
 The state of the board at any given move must be stored so liberties, captures
 count and legality of moves can be addressed, so it is represented with the
@@ -62,11 +65,11 @@ These classes and their relationships can be seen in \fref{fig:game}.
 	\end{center}
 \end{figure}
 
-An implementation of \acrshort{gtp}, that is, the piece of software which offers the \acrshort{gtp}
-interface to other applications. It is designed to be used by a software
-controller but can also be directly run, mostly for debugging purposes. Its
-design is shown in \fref{fig:engine}. The core of the engine is related with
-three components, each with a separate responsibility:
+This will be an implementation of \acrshort{gtp}, that is, the piece of software
+which offers the \acrshort{gtp} interface to other applications. It is designed
+to be used by a software controller but can also be directly run, mostly for
+debugging purposes. Its design is shown in \fref{fig:engine}. The core of the
+engine is related with three components, each with a separate responsibility:
 
 \begin{itemize}
 
@@ -80,8 +83,8 @@ three components, each with a separate responsibility:
 
 	\item The \texttt{DecisionAlgorithm} component is responsible of analyzing
 		the match and generate moves. The engine core uses it when a decision
-		has to be made by the AI, such as when a move needs to be generated by
-		the engine.
+		has to be made by the \acrshort{ai}, such as when a move needs to be
+		generated by the engine.
 
 \end{itemize}
 
@@ -100,30 +103,33 @@ The engine can be started with the executable \texttt{imagocli.py}.
 \subsubsection{Monte Carlo Tree Search Explained}
 
 Monte Carlo Tree Search is an algorithm that can be useful for exploring
-decision trees. It was used by AlphaGo in conjunction with neural networks as
+decision trees. It has a history of use in Go engines, not being able to reach
+strong levels of play until it was paired with neural networks by AlphaGo as
 explained in the AlphaGo 2016 paper \cite{natureAlphaGo2016}.
 
-The algorithm assigns a score to each explored node based on how likely the
-player who makes the corresponding move is to win and updates this score on each
-exploration cycle.
+The algorithm assigns a score to each explored node of the game tree based on
+how likely the player who makes the corresponding move is to win and updates
+this score on each exploration cycle.
 
 The exploration of the tree has 4 steps:
 
 \begin{enumerate}
 
-	\item \textbf{Selection}: The most promising move with unexplored children
-		is selected for exploration. Unexplored children are viable moves which
-		are not yet part of the tree.
+	\item \textbf{Selection}: The most promising move with at least one
+		unexplored children is selected for exploration. Unexplored children are
+		viable moves which are not yet part of the tree.
 
 	\item \textbf{Expansion}: An unexplored children of the selected move is
 		added to the tree. This children is selected at random.
 
 	\item \textbf{Simulation}: The score of the new move is evaluated by playing
-		random matches from it.
+		different matches from it. How this matches are played varies: they can
+		be totally random, but here is where AlphaGo introduces one of its
+		neural networks so these simulation matches are more valuable.
 
-	\item \textbf{Backpropagation}: The score of the new move, as well as its
-		previous moves up to the root of the tree, is updated based on the
-		results of the simulation.
+	\item \textbf{Backpropagation}: The scores of the new move and its previous
+		moves up to the root of the tree are updated based on the results of the
+		simulation.
 
 \end{enumerate}
 
@@ -132,7 +138,7 @@ the perspective of the player which has to make the move.
 
 The implementation of the algorithm will use the existing \texttt{GameMove}
 class from the Game System to access the game logic it needs, such as to get the
-possible children from a node or to simulate random games.
+available children from a node or to simulate random games.
 
 \subsubsection{Neural Networks Explained}
 
@@ -156,13 +162,13 @@ Several kinds of layers have been used in this project:
 	\item \textbf{Dense layers}, which connects each of its nodes to each of the
 		nodes of the previous layers.
 
-	\item \textbf{Convolutional layers}, which process their input by applying
-		a filter function to adjacent values. In the case of this project, the
+	\item \textbf{Convolutional layers}, which process their input by applying a
+		filter function to adjacent values. In the case of this project, the
 		board is filtered by grouping its vertices in 3x3 squares. The aim of
 		these layers is to detect patterns in the input, such as curves, edges
-		or more complex shapes, so they are used a lot on neural networks
-		processing images. They are used in this project because a configuration
-		of the Go board is not that different from a two-dimensional image.
+		or more complex shapes, so they are used a lot on image processing. They
+		are used in this project because a configuration of the Go board is not
+		that different from a two-dimensional image.
 
 	\item \textbf{Max pooling layers}, which process their input in a similar
 		way to convolutional layers, but reducing the size of the input by
@@ -178,19 +184,19 @@ Several kinds of layers have been used in this project:
 Combinations of these layers have been used to define two neural networks.
 
 First, a network using mainly dense layers as an example of a more general
-purpose design of a network.
+purpose and baseline design of a network.
 
 Then, a network with convolutional and max pooling layers to compare the
-approach used on image processing to the more general one and studying its
-utility on the analysis of the Go board.
+approach used on image processing to the more general one and study its utility
+on the analysis of the Go board.
 
 These networks have been implemented on the \texttt{DenseNeuralNetwork} and \\
 \texttt{ConvNeuralNetwork} classes, respectively.
 
 The networks have been designed to process boards of size 9x9, which is the
 introductory size to the game. It is the easiest both for the hardware to handle
-and for the analysis of results while keeping able to support meaningful
-matches.
+and for the analysis of results while still being big enough to support
+meaningful matches.
 
 Both networks have the same design for their input and output.
 
@@ -269,16 +275,16 @@ respectively.
 \end{figure}
 
 Neural networks can be powerful machine learning algorithms, but they have to be
-trained first so they can provide meaningful results. For a Go AI it makes sense
-to have its algorithms trained on Go games. There exists a common text format to
-store Go games: \acrshort{sgf}. If the system is able to process \acrshort{sgf} files, it can provide
-the games stored on them to the neural networks for training. And so the need
-for an \acrshort{sgf} parser arises.
-
-To parse \acrshort{sgf} files a lexer and parser have been implemented using
-PLY.\@ The result of the parsing is an AST (Annotated Syntax Tree) reflecting
-the contents of the text input, each node with zero or more properties, and with
-the ability to convert themselves and their corresponding subtree into a
+trained first so they can provide meaningful results. For a Go \acrshort{ai} it
+makes sense to have its algorithms trained on Go games. There exists a common
+text format to store Go games: \acrshort{sgf}. If the system is able to process
+\acrshort{sgf} files, it can provide the games stored on them to the neural
+networks for training. And so the need for an \acrshort{sgf} parser arises.
+
+To parse \acrshort{sgf} files a lexer and parser have been implemented using PLY
+\cite{ply}. The result of the parsing is an \acrfull{ast} reflecting the
+contents of the text input, each node with zero or more properties, and with the
+ability to convert themselves and their corresponding subtree into a
 \texttt{GameMove} tree. This is done for the root node, since from the
 \acrshort{sgf} specification there are some properties only usable in the root
 node, like those which specify general game information and properties such as
@@ -290,23 +296,23 @@ solved. These components are shown in \fref{fig:trainingModule}.
 
 \begin{itemize}
 
-	\item \textbf{\acrshort{sgf}}: Provides a high-level method to convert a path to a \acrshort{sgf}
+	\item \textbf{\texttt{\acrshort{sgf}}}: Provides a high-level method to convert a path to a \acrshort{sgf}
 		file to a \texttt{GameMove} tree.
 
-	\item \textbf{sgfyacc}: The implementation of a \acrshort{sgf} parser using PLY. Takes
-		the tokens generated by \textbf{sgflex} and creates an \texttt{ASTNode}
+	\item \textbf{\texttt{sgfyacc}}: The implementation of a \acrshort{sgf} parser using PLY. Takes
+		the tokens generated by \texttt{sgflex} and creates an \texttt{ASTNode}
 		tree from them.
 
-	\item \textbf{sgflex}: The implementation of a \acrshort{sgf} lexer using
+	\item \textbf{\texttt{sgflex}}: The implementation of a \acrshort{sgf} lexer using
 		PLY.\@ Takes text input and generates the tokens of the \acrshort{sgf}
 		language from them.
 
-	\item \textbf{ASTNode}: The AST resulting from the parsing of a
+	\item \textbf{\texttt{ASTNode}}: The AST resulting from the parsing of a
 		\acrshort{sgf} file. Has a method to convert it to a tree of
 		\texttt{GameMove} and so obtain the contents of the \acrshort{sgf} in
 		the internal representation used by the project's systems.
 
-	\item \textbf{Property}: The representation of a property of an
+	\item \textbf{\texttt{Property}}: The representation of a property of an
 		\texttt{ASTNode} tree. Each property is made of a name and one or more
 		values and this class helps handling this specific situation.
 
@@ -327,6 +333,134 @@ The training can be started with the executable \texttt{train.py}.
 %	\end{center}
 %\end{figure}
 
-%\subsection{Technical Testing Plan Specification}
+\subsection{Technical Testing Plan Specification}
+
+This section lists and explains the exact testing plan.
+
+\subsubsection{Unitary Testing}
+
+Tests for the Python code will be developed using the unittest
+\cite{python_unittest} testing framework. It has been chosen by virtue of being
+thoroughly documented and widely used.
+
+The coverage of unit testing will be checked with Coverage.py
+\cite{python_coverage}, which can by itself run the unittest tests and generate
+coverage reports based on the results.
+
+\subsubsection{Integration Testing}
+
+\vspace{\interclassSpace}
+
+\begin{tabular}{p{0.4\linewidth}p{0.5\linewidth}}
+	\toprule
+	\multicolumn{2}{c}{\textbf{Engine and Game modules}} \\
+	\midrule
+	\textbf{Test} & \textbf{Expected behaviour} \\
+	\midrule
+	The GTP interface of the engine is used to play a match & The module handles
+	the game and can show its state. \\
+	\bottomrule
+\end{tabular}
+
+\vspace{\interclassSpace}
+
+\begin{tabular}{p{0.4\linewidth}p{0.5\linewidth}}
+	\toprule
+	\multicolumn{2}{c}{\textbf{Training and Engine module}} \\
+	\midrule
+	\textbf{Test} & \textbf{Expected behaviour} \\
+	\midrule
+	The training process is started & The training uses the network defined on
+	the Engine module. \\
+	\bottomrule
+\end{tabular}
+
+\subsubsection{System Testing}
+
+These are the tests to check the correct working of the system as a whole. The
+tests are grouped by the interface they are run against.
+
+\vspace{\interclassSpace}
+
+\begin{tabular}{p{0.4\linewidth}p{0.5\linewidth}}
+	\toprule
+	\multicolumn{2}{c}{\textbf{Game interface}} \\
+	\midrule
+	\textbf{Test} & \textbf{Expected behaviour} \\
+	\midrule
+	Play a game of Go with no engine & The game can be played until the end. \\
+	\midrule
+	Provide a wrong move & The interface shows it is wrong and the game
+	continues without a change of state. \\
+	\midrule
+	Close the game & The interface closes. \\
+	\bottomrule
+\end{tabular}
+
+\vspace{\interclassSpace}
+
+\begin{tabular}{p{0.4\linewidth}p{0.5\linewidth}}
+	\toprule
+	\multicolumn{2}{c}{\textbf{Engine interface}} \\
+	\midrule
+	\textbf{Test} & \textbf{Expected behaviour} \\
+	\midrule
+	Ask for the available commands & The interface outputs the available
+	commands. \\
+	\midrule
+	Provide a move & The state of the engine updates with the new move. \\
+	\midrule
+	Ask for a move & The engine suggests a move without changing the state of
+	the current game. \\
+	\bottomrule
+\end{tabular}
+
+\vspace{\interclassSpace}
+
+\begin{tabular}{p{0.4\linewidth}p{0.5\linewidth}}
+	\toprule
+	\multicolumn{2}{c}{\textbf{Training interface}} \\
+	\midrule
+	\textbf{Test} & \textbf{Expected behaviour} \\
+	\midrule
+	Provide some games to train on & A neural network model is created. \\
+	\midrule
+	Start the training without providing games & An error message is shown and
+	the execution terminated. \\
+	\bottomrule
+\end{tabular}
+
+\subsubsection{Usability Testing}
+
+Two different human users will be exposed to the interfaces of the project and
+asked to answer a questionary about their experience. The aim of this process is
+to identify and address any problems end users could have when using the
+system.
+
+As the training of the neural networks is part of the preparation of the system,
+its usability will not be tested for end users.
+
+These are the questions provided to the testers.
+
+\begin{itemize}
 
-%TODO
+	\item Playing a game against a human:
+		\begin{itemize}
+			\item Were you able to start the interface?
+			\item How hard to understand was the interface of the game?
+		\end{itemize}
+
+	\item Playing a game against the engine:
+		\begin{itemize}
+			\item Were you able to start the interface?
+			\item How hard to understand was the interface of the game?
+			\item How strong did you find the engine?
+		\end{itemize}
+
+	\item Playing a game against the interface through a third-party GUI:
+		\begin{itemize}
+			\item Were you able to start the interface?
+			\item Did you find any problems when setting up the engine?
+		\end{itemize}
+
+\end{itemize}
-- 
cgit v1.2.1


From 12431ce4c4ed52fcfc2180bcffdfec33e72b73ba Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Tue, 6 Jun 2023 20:09:08 +0200
Subject: Written user manuals.

---
 doc/tex/systemDesign.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index 78fb2dc..3542cb5 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -457,7 +457,7 @@ These are the questions provided to the testers.
 			\item How strong did you find the engine?
 		\end{itemize}
 
-	\item Playing a game against the interface through a third-party GUI:
+	\item Playing a game against the interface through a third-party \acrshort{gui}:
 		\begin{itemize}
 			\item Were you able to start the interface?
 			\item Did you find any problems when setting up the engine?
-- 
cgit v1.2.1


From a005228a986b17732ae7cccbedde450533cfe1f1 Mon Sep 17 00:00:00 2001
From: InigoGutierrez <inigogf.95@gmail.com>
Date: Fri, 9 Jun 2023 13:12:05 +0200
Subject: First usability test.

---
 doc/tex/systemDesign.tex | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

(limited to 'doc/tex/systemDesign.tex')

diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index 3542cb5..e166955 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -265,7 +265,7 @@ respectively.
 
 \begin{figure}[h]
 	\begin{center}
-		\includegraphics[width=\textwidth]{diagrams/trainingModule.png}
+		\includegraphics[width=0.7\textwidth]{diagrams/trainingModule.png}
 		\caption{Components of the \acrshort{sgf} file parsing module.}
 		\label{fig:trainingModule}
 		Components not showing a capital C are not classes, as in they not
@@ -444,23 +444,24 @@ These are the questions provided to the testers.
 
 \begin{itemize}
 
-	\item Playing a game against a human:
+	\item Playing against a human:
 		\begin{itemize}
 			\item Were you able to start the interface?
-			\item How hard to understand was the interface of the game?
+			\item How hard was the interface of the game to understand?
 		\end{itemize}
 
-	\item Playing a game against the engine:
+	\item Playing against the engine:
 		\begin{itemize}
 			\item Were you able to start the interface?
-			\item How hard to understand was the interface of the game?
+			\item How hard was the interface of the game to understand?
 			\item How strong did you find the engine?
 		\end{itemize}
 
-	\item Playing a game against the interface through a third-party \acrshort{gui}:
+	\item Playing against the interface through a third-party \acrshort{gui}:
 		\begin{itemize}
 			\item Were you able to start the interface?
 			\item Did you find any problems when setting up the engine?
+			\item Do you think this tool has value for studying Go?
 		\end{itemize}
 
 \end{itemize}
-- 
cgit v1.2.1

