diff options
Diffstat (limited to 'doc/tex/systemAnalysis.tex')
| -rw-r--r-- | doc/tex/systemAnalysis.tex | 204 |
1 files changed, 190 insertions, 14 deletions
diff --git a/doc/tex/systemAnalysis.tex b/doc/tex/systemAnalysis.tex index 7753018..5868422 100644 --- a/doc/tex/systemAnalysis.tex +++ b/doc/tex/systemAnalysis.tex @@ -5,9 +5,9 @@ \subsection{System Requirements} The requirements for the system are expressed here in a nested list way, each of -them with a textual and numeric reference so they are traceable. The functional -requirements are exposed first, followed by the other kinds of requisites needed -for the system. +them with a textual and numeric reference for them to be traceable. The +functional requirements are exposed first, followed by the other kinds of +requisites needed for the system. \setlist[enumerate,2]{label*=\arabic*.} \setlist[enumerate,3]{label*=\arabic*.} @@ -58,7 +58,47 @@ for the system. \begin{enumerate} - \item Coordinates of the board representing valid moves must be printed. + \item The engine implements the GTP (\textit{Go Text Protocol}) for its + interface. + \begin{enumerate} + \item Commands are read from standard input. + \item Responses are provided via standard output. + \item There exist commands to set up the conditions of the match. + \begin{enumerate} + \item The size of the board can be set. + \item The komi can be set. + \end{enumerate} + \item There exist commands to manipulate the internal representation + of the match. + \begin{enumerate} + \item It is possible to indicate a move being played. + \item It is possible to clear the board. + \end{enumerate} + \item There exists a command to generate a move. + \begin{enumerate} + \item The generated move must be a playable move. + \item Generating a move does not change the internal + representation of the match. + \end{enumerate} + \item There exist commands to ask for information about the engine. + \begin{enumerate} + \item It is possible to ask for the protocol version + implemented. + \item It is possible to ask for the name of the engine. + \item It is possible to ask for the version of the engine. + \item It is possible to ask whether a specific command is + known to the engine. + \item It is possible to ask for a list of the known commands. + \end{enumerate} + \item There exists a command to stop the engine. + \end{enumerate} + + \item The engine can be executed from the command line. + \begin{enumerate} + \item The engine can be executed directly from an interactive shell. + \item The engine can be executed by another program to be used as + backend. + \end{enumerate} \end{enumerate} @@ -121,7 +161,7 @@ for the system. \item It will be possible to pass the maximum time as a launch argument. \item It will be possible to store the maximum time as a setting - in a configuration file + in a configuration file. \end{enumerate} \end{enumerate} @@ -170,22 +210,36 @@ The engine is used as the backend for generating moves for a machine player. \subsection{Subsystems} -\subsubsection{Subsystems description} - There will be two main subsystems. % TODO: Are there really two different subsystems? They look very coupled, since % the engine will use some classes of the game. This section is more suited for % independently run systems which communicate through some common interface. +% ...Or maybe not. From the template: "Subsystems are groupings of packages and +% classes with a common objective. Examples of subsystems are the classes which +% handle the database, classes joining a group of related services..." + +\subsubsection{Game System} The first, called the Game System, will be in charge of storing all the state information regarding a Go match, such as the history of moves, the possible variations, the state of the board at any given time or the current number of captured stones. +This system will include a command-line interface with which to play Go matches +between human players to show and test its capabilities. + +\subsubsection{Engine System} + The second, called the Engine System, will implement the GTP interface and use the Game System to analyze positions and generate moves via decision algorithms. +This system can be directly called to manually set up game states and ask for +moves or can be called by other programs to be used as backend for playing +matches against a computer player. + +%\subsubsection{Interface between subsystems} + \subsection{Class analysis} \subsubsection{Class diagram} @@ -262,7 +316,7 @@ The classes resulting from the analysis phase are shown in \tabitem{Analyzing game states and generating moves.} \\ \midrule \textbf{Proposed attributes} \\ - \textit{Depends on the algorithm.} \\ + \textit{(Depends on the algorithm.)} \\ \midrule \textbf{Proposed methods} \\ \tabitem{\textbf{genmove()}: Gives the coordinates of a move to play.} \\ @@ -321,20 +375,27 @@ The classes resulting from the analysis phase are shown in \begin{tabular}{p{\linewidth}} \toprule - \textbf{GameTree} \\ + \textbf{GameBoard} \\ \midrule \textbf{Description} \\ - Stores the moves and variations in a match. \\ + Stores the state of a board position and handles its logic. \\ \midrule \textbf{Responsibilities} \\ - \tabitem{Store the base node of the tree of moves of a match.} \\ + \tabitem{Store the vertices of a board position.} \\ + \tabitem{Logic related to a board position.} \\ \midrule \textbf{Proposed attributes} \\ - \tabitem{\textbf{GameMove root}: First move of the match (normally a - symbolic move representing the empty board before the actual first move of a - player).} \\ + \tabitem{\textbf{Player[][] board}: An array of the stones on the board.} \\ \midrule \textbf{Proposed methods} \\ + \tabitem{\textbf{getGroupLiberties()}: Returns a set with the empty vertices + adjacent to the group occupying a vertex.} \\ + \tabitem{\textbf{getGroupLibertiesCount()}: Returns the number of liberties + of the group occupying a vertex.} \\ + \tabitem{\textbf{getGroupVertices()}: Returns a set with the vertices of the + group occupying a vertex.} \\ + \tabitem{\textbf{getGroupVerticesCount()}: Returns the number of stones of + the group occupying a vertex.} \\ \bottomrule \end{tabular} @@ -379,3 +440,118 @@ The classes resulting from the analysis phase are shown in \end{tabular} \vspace{\interclassSpace} + +\subsection{Use case analysis and scenarios} + +\indent + +\begin{tabular}{lp{0.7\linewidth}} + \toprule + \multicolumn{2}{c}{\textbf{Play a match (Make a move?)}} \\ + \midrule + \textbf{Preconditions} & The game interface has been started. \\ + \midrule + \textbf{Postconditions} & Description of postconditions \\ + \midrule + \textbf{Actors} & Actors \\ + \midrule + \textbf{Description} & Description \\ + \midrule + \textbf{Secondary scenarios} & Secondary scenarios \\ + \midrule + \textbf{Exceptions} & Exceptions \\ + \midrule + \textbf{Notes} & + ---\\ + \bottomrule +\end{tabular} + +\vspace{\interclassSpace} + +\begin{tabular}{lp{0.7\linewidth}} + \toprule + \multicolumn{2}{c}{\textbf{Generate a move}} \\ + \midrule + \textbf{Preconditions} & The game engine has been started. \newline + Optionally, some moves have already been played. \\ + \midrule + \textbf{Postconditions} & A move is suggested via the engine output. \\ + \midrule + \textbf{Actors} & Human user and GUI program. \\ + \midrule + \textbf{Description} & + 1. The user or program enters the player to generate the move + for.\newline + 2. The suggested move is outputted by the engine, either as + coordinates or as an indication to pass. + \\ + \midrule + \textbf{Secondary scenarios} & + \textbf{The move is illegal}: An error message is shown. Go back to step 1 of + main scenario. \\ + \midrule + \textbf{Exceptions} & + \textbf{The input is wrong}: An error message is shown. Go back to step 1 of + main scenario.\\ + \midrule + \textbf{Notes} & + ---\\ + \bottomrule +\end{tabular} + +\vspace{\interclassSpace} + +\subsubsection{Use as backend for machine player} + +\begin{figure}[h] + \begin{center} + \includegraphics[width=\textwidth]{diagrams/useCase_useAsBackend.png} + \caption{Use as backend for machine player} + \end{center} +\end{figure} + +\begin{tabular}{lp{0.7\linewidth}} + \toprule + \multicolumn{2}{c}{\textbf{Use as backend for machine player}} \\ + \midrule + \textbf{Preconditions} & The game engine has been configured as engine for + the software. \\ + \midrule + \textbf{Postconditions} & A match has been played against the engine. \\ + \midrule + \textbf{Actors} & GUI program. \\ + \midrule + \textbf{Description} & + 1. The program gives commands to the engine. The specific commands will + vary from program to program.\newline + 2. The engine suggest moves to the program.\newline + 3. The moves are shown by the program as if made by another player.\\ + \midrule + \textbf{Secondary scenarios} & + ---\\ + \midrule + \textbf{Exceptions} & + ---\\ + \midrule + \textbf{Notes} & + ---\\ + \bottomrule +\end{tabular} + +\subsection{Testing Plan Specification} + +\subsubsection{Unitary Testing} + +Tests for the python code are 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 is checked with Coverage.py\cite{python_coverage}, +which can by itself run the unittest tests and generate coverage reports based +on the results. + +% Maybe put an example report here? + +\subsubsection{Integration Testing} + +\subsubsection{System Testing} |