1 files changed, 93 insertions, 0 deletions
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}