head	1.23;
access;
symbols
	tonic_4:1.23
	tonic_3:1.23
	tonic_2:1.23
	demo:1.23.0.2
	design_report:1.23
	oral_presentation_freeze:1.18.0.2;
locks; strict;
comment	@% @;


1.23
date	95.12.11.21.26.22;	author daveg;	state Exp;
branches;
next	1.22;

1.22
date	95.12.11.21.17.01;	author jered;	state Exp;
branches;
next	1.21;

1.21
date	95.12.11.20.33.02;	author hartmans;	state Exp;
branches;
next	1.20;

1.20
date	95.12.11.19.59.42;	author hartmans;	state Exp;
branches;
next	1.19;

1.19
date	95.12.01.03.38.51;	author hartmans;	state Exp;
branches;
next	1.18;

1.18
date	95.11.25.10.12.10;	author hartmans;	state Exp;
branches
	1.18.2.1;
next	1.17;

1.17
date	95.11.21.11.23.08;	author daveg;	state Exp;
branches;
next	1.16;

1.16
date	95.11.21.08.55.01;	author daveg;	state Exp;
branches;
next	1.15;

1.15
date	95.11.21.00.19.46;	author daveg;	state Exp;
branches;
next	1.14;

1.14
date	95.11.20.06.20.24;	author hartmans;	state Exp;
branches;
next	1.13;

1.13
date	95.11.20.05.59.10;	author daveg;	state Exp;
branches;
next	1.12;

1.12
date	95.11.20.05.03.40;	author daveg;	state Exp;
branches;
next	1.11;

1.11
date	95.11.20.00.24.53;	author hartmans;	state Exp;
branches;
next	1.10;

1.10
date	95.11.19.22.44.19;	author hartmans;	state Exp;
branches;
next	1.9;

1.9
date	95.11.19.18.14.00;	author jered;	state Exp;
branches;
next	1.8;

1.8
date	95.11.19.18.11.09;	author hartmans;	state Exp;
branches;
next	1.7;

1.7
date	95.11.18.22.32.04;	author hartmans;	state Exp;
branches;
next	1.6;

1.6
date	95.11.18.22.27.54;	author hartmans;	state Exp;
branches;
next	1.5;

1.5
date	95.11.18.22.13.57;	author hartmans;	state Exp;
branches;
next	1.4;

1.4
date	95.11.18.22.06.47;	author jered;	state Exp;
branches;
next	1.3;

1.3
date	95.11.18.17.59.41;	author hartmans;	state Exp;
branches;
next	1.2;

1.2
date	95.11.18.06.45.50;	author hartmans;	state Exp;
branches;
next	1.1;

1.1
date	95.11.17.22.55.38;	author hartmans;	state Exp;
branches;
next	;

1.18.2.1
date	95.11.30.10.50.28;	author hartmans;	state Exp;
branches;
next	1.18.2.2;

1.18.2.2
date	95.11.30.10.55.33;	author hartmans;	state Exp;
branches;
next	;


desc
@Design overview
@


1.23
log
@ispelled version
@
text
@\documentstyle[epsf]{report}
\textheight 10in \topmargin -0.5in
% $Source: /mit/6.170/groups/se01/.cvsroot/design/design.tex,v $
\textwidth 6.5 in
\oddsidemargin 0 in
\catcode`\| 13
\def\ttuntil#1|{\nonfrenchspacienvisionedrfeitstantiationount
\tt
#1\endgroup}

\def|{\protect \begingroup\catcode`\_11\relax
\ttuntil}

\title{Antichess:Final Report}
\author{
Jered Floyd\\
David Golombek\\
Sam Hartman\\
Ronnie Misra
}
\begin{document}
\maketitle
\tableofcontents

\chapter{Design Overview}

\section{Design Goals}

	The overall design goal of this project was to design a flexible model for implementing board  games with a web server interface.  In drafting the design, the following were considered desirable characteristics:
\begin{enumerate}

	\item  Avoid dependence on any particular game whenever possible.  For example, there is no reason for a machine player to even be aware of the game it is playing unless special optimizations are required.

	\item Maximize flexibility by minimizing the ammount of code that needs to be changed in order to implement changes in game rules.

	\item  Use portable code  so that the server compiles on as many platforms as is feasible.

	\item Conform to Internet standards and to good protocol design, providing alternatives to specified protocols when these specifications do not fully meet these goals.

\end{enumerate}




\section{Top-level Task Overview}
	
Tasks completed by the project:
\begin{itemize}

	\item  Work as a web server

	\item  Present anti-chess games to user and accept moves

	\item  Validate moves and change state of board

	\item  Determine and make best response for machine player

	\item  Present changes in board state

	\item  Handle timing 

	\item  Interpret tournament protocol as well as presenting something useful to humans

	\item  Present help and documentation

	\item  Handle meta-game information: player names, concurrent games, game initiation and termination

	\item  Deal with games between two humans, managing to the extent possible under {\sc HTTP} notifications of moves, detaching and attaching, etc
\end{itemize}

\label{s:tasks}

\section{Abstraction Layers}
\begin{figure}[p]
\leavevmode
\begin{center}
\leavevmode
\epsfbox{mdd.ps}

\caption{Modular dependencies}

\end{center}
\end{figure}
	The following abstractions are proposed to complete the tasks presented in Section~\ref{s:tasks}.

\begin{description}

	\item[|top\_node|] Abstraction, mostly provided from supplied code to represent the information associated with a server

	\item[|game|] Abstraction to represent a game that is being played: Includes meta information, move history, etc.  The game also manages interactions between other components, sequencing application of moves and notification of state change.  In addition, web requests are redirected by game to sub-components.

	\item[|board|]  Abstraction to represent the particular state of a game, including board position and timing information.  The game abstraction will have at least one |board| representing the current move.

	\item[|chess\_display\_board|] Abstraction of board to those games that use a $8\times 8$ board as their playing field.  The starting state will always be read in from a given stream.  

	\item[|player|]  A generic player abstraction used to insulate the |game| and |board| abstractions from the difference between human and machine players.  

	\item[|machine\_player|] Abstraction to represent machine players.

\end{description}


\section{Division of labor}
	Preliminary design details were worked out by the group.  Sam
wrote the first draft of the specifications, and these were revised by the group through a process of evaluating how the design worked under expected game conditions.

	David implemented |chess_display_board| and |antichess_board|,
writing the static evaluator and move generator.  In addition, he
worked on |player| and |human_player|.

	Jered wrote all the methods for doing web output from |board|,
|game| and~|player| objects and subtypes.  In addition, he wrote the
machine player and |tic_board|, a implementation of tic tac toe used to test the basic design while |antichess_board| was incomplete.

	Sam wrote the methods to deal with the incoming web requests as well as designing the enhanced protocol used in addition to the protocol specified in the problem set.

	Ronnie wrote the {\sc HTML} used for the help and welcome pages.  In addition, he implemented several methods in |top_node| and several web enhancements.


\section{Schedule}
	
	Our schedule was based upon the given due dates, then expanded
to cover all of the abstractions we created.

\begin{itemize}

	\item November 14 Preliminary Design.  Create preliminary
draft of this document.
	
	\item November 21 Revised Design.  Finish this design
document, flesh out all abstractions and implement code for lowest
levels of abstraction.

	\item November 30 Oral Presentation.  By this time, design
should be stable, and a large portion of the code should have been
roughed out, but not completely tested.

	\item December 05 Functionality Freeze.  This should be date
for last check-in of added functionality code changes, to give us a
chance to begin final testing. 

	\item December 11 Final Report.  All but extreme bug changes
should be completed and finalized.  

	\item December 12 Demonstration.  All code better be done by
this point.

	\item December 14 Tournament.  And even more finished by this point.

\end{itemize}

\section{User Interface}

		After a user initially connects to the server, the server will accept at least the following options:
\begin{itemize}
	\item  Begin a game

	\item Help on Antichess

\item Load new games

\item  Show incomplete games

\end{itemize}


	Users who begin a game will be asked to fill out appropriate
meta-information such as user name, and machine player
characteristics, then the game will enter the movement phase.  A page
will be presented containing an Antichess board.  Above the board, a
list will contain the last few moves and any additional status
messages.  Below this will be an $8\times 8$ Antichess board; this
will either be presented using tables, or a series of images on a
line, depending on the apparent capabilities of the browser and what
ends up looking good.  

	Below the board will be a form entry where the user can enter
a textual move and click submit.  It is expected that this interface
will rarely be used outside of testing.

	Each image on the board will be a link.  If the image is
selected, the board will enter select state.  The board in selected
state looks much as the normal board, except:
\begin{itemize}

	\item  The piece that is selected  will be replaced with a image showing it as highlighted.

	\item  The source section of the movement entry form will be filled in with the square of the piece that is selected.
\end{itemize}


	If another square is selected while the board is in select state, the user is assumed to have attempted a move from the source square to the destination square.    

	If a move is entered either by entering one in the movement area, or by selecting a destination from select state, the move is processed and the board is updated.

	Additional options may be provided below the board for things
like help, viewing previous game positions, getting hints, configuring
the game, etc.
\chapter{Design and Implementation comments}
\section{Design of game}
\label{d:game}
	This abstraction implements the concept of a game, with a
state represented by a board.  This abstraction makes few assumptions
about the game that the board ``plays''.  It also keeps a move history
and maintains state about each player.

Task List:
\begin{itemize}

	\item  Keep track of the current player and board

	\item Keep track of previous moves

	\item  Apply moves to the board

	\item  Ask players to make new moves

	\item  Dispatch web requests to players and boards

	\item  Inform players when another player makes a move

	\item  Handle compatibility web protocol

\end{itemize}


	Unfortunately, some fairly complicated dependencies exist
between |game|, |board| and |player| to allow for the various
strategies for entering moves.  four mechanisms exist for entering moves, and |game| must deal with all of these:
\begin{enumerate}
	\item When a game is initialized, if a machine player is
first, it will need to move.  Generalizing this solution, it is
important that players used with |game| support a method to ask them
to consider moving whenever the game state changes significantly.
Such changes include initialization, or extra-game editing of the
board.

	\item  In order to allow a machine player to think and return a move, |game| must call each player giving that player an opportunity to return a move.  For human players, this will never result in a move being generated, as the move will be returned by a web request, instead of from a call to a method of |player|.

	\item An incoming request in either the 6.170 mandatory
protocol, or in our extended protocol may indicate the current player
has moved.  This request will be dispatched to the appropriate
instantiation of |player| or |board|.  

	\item A request, directed at the board, may select a
destination square for a move.  This may cause the board to generate a
move for the current player.

\end{enumerate}
These interactions become important at the design phase  because it is necessary to understand how moves can be generated in order to best  design an interface that minimizes duplication of code and places emphasis on the underlying problem---the problem of reading and acting on a move.  In order to implement a clean interface for dealing with moves, the following approach is taken:
\begin{enumerate}

	\item Whenever the game state changes in response to game
	initialization or any event besides one of the players moving,
	a state change method is called on each player.  If an
	instance of |player| has valid moves it can make when this
	method is called, it is required to take actions that will
	avoid deadlock.  Generally, moving is sufficient, although a
	subtype of |player| could simply arrange to move at some
	future time.  Other options include presenting some web interface to force the player to move.


\item If a web request is dispatched to an
	inferior node such as an instance of |player| or |board|, the
	corresponding response is returned unmodified.  This allows
	for non-movement-related requests such as help, etc.

	\item A request handler that wishes to enter a move will call
a method on |game| to handle all the work of entering the move.  Such
requests will eventually call another method on |game| to obtain an
updated state of the game.  This state will be the complete,
unmodified response of the request.

	\item When an instance of |player| is informed of an
opponent's move, it is legal for the player to make its own move by
calling the appropriate method on |game|.

\end{enumerate}



\input{game.h.tex}

\section{Design of board, the interface between game and game state}

	The |board| abstraction is a abstract base class inheriting
from |web_node|.  It is designed to present the interfaces required by
|game| and a reasonable machine player without including any specific
knowledge of a particular game or its rules.  For this reason, moves
are represented as abstract members of class~|move|.  

	Several pure virtual interfaces, required by |game| and
|player| are included.  Any implementation of these interfaces will
require specific knowledge of the particular game being represented by
the board.  

	A decision was made to include the interface to the static
evaluator in |board| and to include implementations in subtypes of
|board|.  It is likely that only machine players will find the static
evaluator useful.  However, by including it in |board|, it is possible
to write a machine player that isn't aware of what game it is playing.
Also, this helps concentrate game-specific code in one
place---subtypes of |board|.  

Tasks required by this abstract interface:
\begin{enumerate}

	\item Accept web requests from |game|

	\item Apply moves as requested by |game|

	\item Provide a generator that returns all legal moves at the current point, along with the static evaluation of the board after applying one of these moves
	\item Provide a static evaluator

	\item Provide a routine to generate the board representation for inclusion in the response to web requests to |game|.


	\item Suggest the amount of time to be spent on a particular move.
\end{enumerate}


\input{board.h.tex}
 
\section{ Design of chess\_display\_board}

	This subtype of the |board| interface implements functions
required for an $8\times8$board where a square can hold one chess
piece.  This board is not aware of the rules of the game in that the
moves generator and static evaluator are still pure virtual, but it
can display a chess board, and generate a move by selecting a source
and destination square.  The initial state of a chess\_display\_board 
shall be specified in a given stream, which will meet the specifications 
below:

\input{chess_board_format.tex}

\input{chess_display_board.h.tex}

\section{Design of antichess\_board}


This subtype of |chess_display_board| implements the rules of Antichess.    In particular, all methods specified in |board| are implemented in such a way that it is possible for this board to be used with |game|.

\input{antichess_board_format.tex}

\input{antichess_board.h.tex}


\section {Design of {\tt player}}

This is a subtype of |web_node|.  The |player| class embodies an abstract entity capable of making moves in a game.  It accomplishes the following:

\begin{enumerate}

	\item Keeps track of time elapsed and remaining and forfeits when time runs out

	\item  Has interface so |game| can notify it about moves made both by itself and by the opponent and of state changes not resulting from moves
	
	\item  Keeps track of player name and if set, position

	\item  Provides a method so that boards in games like Antichess can set the position of the player to ``white'' or ``black''.

	\item  Provides a method so that |game| can get a representation of the player state to include in a web response.  This state should include name, position (if set), and time remaining at a minimum.  

	\item  Accepts web requests including at a minimum requests to change the player name and time remaining.
\end{enumerate}




\input {player.h.tex}

		There are two subclassess of |player| essential to the operation   of the server: |machine_player| and |human_player|.

\subsection{machine\_player}

	The machine player abstraction implements a computer player.
It uses one of two algorithms to choose a move.  If possible, it uses
a min-max search with alpha-beta pruning.  Otherwise, it simply
chooses the best move at the current level.  It is expected that the
alpha-beta algorithm will not fail, but in case it does, the simple
algorithm is included.

\input{machine_player.h.tex}

\subsection{human\_player}

	The human player object implements functionality necessary for
human--human games and to allow humans to change parameters about
their players.  In particular, it has the ability to forfeit and
change time remaining.  Clock management is handled to work properly
for someone connected over the web.

\input{human_player.h.tex}


	\section{Design of {\tt move}}

	The |move| class implements the concept of an abstract move.
Required by |board| and |player|.  Moves can be compared for equality,
and can return a string representation of themselves.  All other operations are reserved to subclasses of |move|.

	Because |move| is expected to be small, and because many
instances of |move| are expected to exist, |move| must be able to be a
stack abstraction.  Note that several constructors and operators on
|move| are protected, so that |move| objects are not chopped by
inadvertent copying.


	For this reason, |move| requires a special |move_generator|
that returns pointers to |move| instead of actual move objects.

	However, in order for |game| to maintain a move history, it
must be able to copy a |move| without knowing what type of move it is.
Thus, |move| must also be capable of being a heap abstraction.  It is
envisioned that |board::valid_moves| will produce a large number of
moves of a particular type in a compact form, and will return pointers
to these one-at-a-time.  Only moves that are actually used will be
copied by |game|.

\input{move.h.tex}

\section{Implementation Overview}

	The implementation of the program was split into three
components: modified versions of web server code supplied with the
problem set, basic components such as players and |game|, and
antichess specific components.

	
	For the most part, the design allowed components to be
implemented without any unnecessary dependencies or unusual features.
However, the required {\sc HTTP} protocol was designed for a less
modular design.  In order to implement it, some unnecessary
dependencies had to be introduced into |game|.

	Because of design errors in the required protocol, it was felt
acceptable to introduce these dependencies and provide a better
default protocol than to redesign around the broken protocol.

	
	

\input{http_proto.tex}

\chapter{Validation Strategy}

Several methods were used to verify test the implementation and design:

\begin{enumerate}

	\item A small test framework was used to test the interactions
between |game|, |board| and~|player|.  This framework tested the
simple machine player, playing in a simplified game.  The framework
confirmed that there were no apparent design flaws, and that the
movement structure would allow moves to be made without deadlocks.

	\item Along with the test framework, a simple board was
constructed: a board to play tic tac toe was implemented in parallel
with |antichess_board|.Having multiple implementations of
|board|provided additional confirmation that |board| was a reasonable design.

	\item In |antichess_board|, a different algorithm is used to
confirm the validity of moves than is used to generate the valid
moves.  These multiple implementations tend to illustrate bugs in each other.

	\item The web protocol was tested by constructing a subset of
valid requests that were likely to happen.  In particular, each
request in Chapter~\ref{s:http} was tested with reasonable arguments.  Error conditions were also tested.

	\item Once the load game feature was implemented, several test
case boards were loaded and responses of the move generator was
tested.



	\item A clear method of notifying all developers of changes in
design specification.


	\item All compilations will be done with -Wall to help catch
casting and coding errors.

	\item Where possible, methods and procedures will have a
checks clause that ensures input meets requirements from this design
document. 

%	\item Automated testing will be performed when it becomes
%viable to do so, by creating a harness for the web server and throwing
%requests at it.

	\item Outside testers, untainted by source, shall test working
code to find bugs not seen by programmers.
	
\end{enumerate}

\chapter{Description of Progress}


	Currently, almost all specifications have been implemented.
Testing, including play testing from outsiders proceeds well; many
bugs have been found, and it is unlikely that any serious bugs remain.
The following lists known deficiencies that may correct themselves by
the time of the demonstration:

\begin{enumerate}

	\item The |nnnn/display|request does not always work;
sometimes it is not found.  This creates somewhat of a problem for human players; you just have to ``know'' the other player has moved.

	\item  The `Can I move yet?'' button ` doesn't work very predictably.
\end{enumerate}



\end{document}

@


1.22
log
@Doc fixes
@
text
@d3 1
a3 1
% $Source: /afs/athena.mit.edu/course/6/6.170/groups/se01/.cvsroot/design/design.tex,v $
d7 1
a7 1
\def\ttuntil#1|{\nonfrenchspacing
d36 1
a36 1
	\item  Use portable code  so that the server compiles on as many platforms as is feisible.
d142 1
a142 1
	\item December 11 Final Report.  All but exreme bug changes
d148 1
a148 1
	\item Dececmber 14 Tournament.  And even more finished by this point.
d222 1
a222 1
	\item  Handle compatability web protocol
d240 1
a240 1
	\item An incoming request in either the 6.170 mandentory
d243 1
a243 1
instanciation of |player| or |board|.  
d300 1
a300 1
evaluator useful.  H.wever, by including it in |board|, it is possible
d318 1
a318 1
	\item Suggest the ammount of time to be spent on a particular move.
d323 1
a323 1

d379 2
a380 2
a min-max search with alpha-beta prooning.  Otherwise, it simply
choosesthe best move at the current level.  It is expected that the
d390 1
a390 1
their players.  In particular, it has the ability to forefit and
d407 1
a407 1
inadvertant copying.
d416 1
a416 1
invisioned that |board::valid_moves| will produce a large number of
d461 1
a461 1
|board|provided additional confirmationthat |board| was a reasonable design.
d465 1
a465 1
moves.  These multiple implementations tend to illustrate bugsin each other.
d472 1
a472 1
case boardswere loaded and responses of the move generator was
@


1.21
log
@Changes so it goes through latex
@
text
@d2 2
a3 1
% $Source: /mit/6.170/groups/se01/.cvsroot/design/design.tex,v $
d14 1
a14 1
\title{Antichess:Oral Report}
@


1.20
log
@Update design
@
text
@d374 1
a374 1
\subsection{|machine\_player|}
d385 1
a385 1
\subsection{|human\_player|}
d452 4
a455 2
between |game|, |board| and~|player~.  This framework tested the
simple machine player, playing in a simplified game.  The framework confirmed that there were no apparent design flaws, and that the movement structure would allow moves to be made without deadlocks.
d511 1
@


1.19
log
@Integrate oral presentation changes into main line.
@
text
@d18 1
a18 1
%Ronnie Misra
d26 18
d67 1
d87 1
a87 1
	\item[|web\_server|] Abstraction, mostly provided from supplied code to represent the information associated with a server
d89 1
a89 1
	\item[|game|] Abstraction to represent a game that is being played: Includes meta information, move history, etc.
d103 6
d110 3
a112 5
	David and Sam will work on the data representation and
user-interface abstractions.  Specifically, Sam will work primarially
on |web_server|, |game| and internal representation of |board|.  David
will work on the presentation of the user interface in |game| and
|board|; significant overlap is expected.
d114 1
a114 1
	Ronnie and Jered will focus on the |player| abstractions, especially the |machine_player|.  Jered is also expected to help out with graphical manipulations, such as creating piece tiles, and designing web pages.
d116 1
a116 1
	We will all contribute to design and documentation.  
d118 1
d159 4
d221 2
d242 1
a242 1
instanciation of |player|.  
d259 1
a259 1
	future time.  
d317 1
d372 24
d424 4
a427 23
	The Abstraction Functions and Rep Invariants of each of our
abstractions is listed at the bottom of their respective include
files.  With our current design, each of these individual rep's is
fairly trivial.  It is the interactions among them, listed above, that
provide the neccessary levels of control.  

	Our strategy for dealing with player moves is the most
complicated set-up defined so far, because we have put both the
machine and human players under the same |player| abstraction.  To
deal with the stateless nature of the http-protocol, our design
passes players two different signals, you\_moved, and opponent\_moved,
to indicate the beginning and end of turns.  There is a third method,
state\_changed, to allow player notification of non-move events as
well.  Between these three methods, we can assure that a |server| is
never in a hung state, waiting for a player to complete a move.  This
setup is more fully described above.

	We have not yet implemented our static evaluator, and thus still
have to work out the algorithms that it will use.  However, since the
alpha-beta pruning algorithm was provided to us, we do not expect to
encounter any serious problems with the base implementation of the
|board's| evaluate method.  Further enhancements to this design will
follow, but should not present particularly large problems.
d429 13
d447 1
a447 2
	To keep our code as bug free as possible, we will use several 
verification techniques, including:
d450 21
a470 2
	\item A source control system (CVS) to avoid bugs introduced
by multiple programmers.
d472 2
a476 2
	\item A full make system will be implemented, to make sure all
build's are done with the most recent version of source code.
a480 3
	\item Design document and all abstractions are decided before
coding begins.

d485 3
a487 3
	\item Automated testing will be performed when it becomes
viable to do so, by creating a harness for the web server and throwing
requests at it.
d496 15
a510 9
	As of the Revised Design, we have fleshed out this design
document to describe the continuing evolution of our design.  We have
also created header files to describe the various abstractions that
are described above (and are included as well).  We have begun to
implement the lowest level of our abstractions, in particular the
board, game, and player code.  We have validated this code by
extensive discussion and clarification of the design document.  Any
bugs so far have been cleaned up (further code development may hilight
design bugs though).
@


1.18
log
@Check in first version of HTTP protocol for our ps; this is rough
and not complete, but a good start.
Also, split design.tex into chapters.

to
make any this evening, really.  all of my stuff has been new code.
     UNAUTHENTIC Personal message at 05:11:34 on Sat Nov 25 1995
          From: Gymnast <daveg> on BART-SAVAGEWOOD.MIT.EDU
                     To: hartmans@@ATHENA.MIT.EDU-------------------------------
make any this evening, really.  all of my stuff has been new code.
od start.
@
text
@d1 1
a1 1
\documentstyle{report}
d13 1
a13 1
\title{Antichess: Preliminary Design}
d18 2
a19 1
Ronnie Misra}
d22 2
d54 10
d394 2
@


1.18.2.1
log
@Make this bigger, remove rgmisra from author line for the present
@
text
@d1 1
a1 1
\documentstyle[epsf]{report}
d13 1
a13 1
\title{Antichess:Oral Report}
d18 1
a18 2
%Ronnie Misra
}
a50 10
\begin{figure}[p]
\leavevmode
\begin{center}
\leavevmode
\epsfbox{mdd.ps}

\caption{Modular dependencies}

\end{center}
\end{figure}
a380 2
\input{http_proto.tex}

@


1.18.2.2
log
@Add table of contents
@
text
@a21 2
\tableofcontents

@


1.17
log
@Revised Design version of Design Document
@
text
@d1 1
a1 1
\documentstyle{article}
d21 2
d48 4
a51 1
\subsection{Abstractions Layers}
d70 1
a70 1
\subsection{Division of labor}
d157 1
a157 1

d381 1
a381 1
\section{Validation Strategy}
d415 1
a415 1
\section{Description of Progress}
d428 1
@


1.16
log
@renamed input files
@
text
@d21 1
a21 1
\section{Exploration of top-level Task}
d23 1
a23 2

Overall task list for the project:
d30 1
a30 1
	\item Validate moves and change state of board
d46 1
a46 1
\subsection{Proposed Abstractions}
d349 27
d379 1
a379 1
verification techniques:
d388 3
d397 2
a398 2
	\item Where possible, all methods and procedures will have a
checks that makes sure input meets requirements from this design
@


1.15
log
@more minor mods
@
text
@d234 1
a234 1
\input{game-h.tex}
d252 1
a252 1
evaluator useful.  However, by including it in |board|, it is possible
d273 1
a273 1
\input{board-h.tex}
d288 1
a288 1
\input{chess-display-h.tex}
d297 1
a297 1
\input{antichess-h.tex}
d322 1
a322 1
\input {player-h.tex}
d348 1
a348 1
\input{move-h.tex}
@


1.14
log
@Design changes to document:
1) change state method
2) implications for move ordering, etc.
@
text
@d51 2
d59 1
a59 4
	\item[|web\_server|] Abstraction, mostly provided from supplied
code to represent the information associated with Antichess server

	\item[|machine\_player|] Abstraction to represent the machine player
d61 1
a61 1
	\item[|player|]  It is possible that a generic player abstraction will be used to insulate the |game| and |board| abstractions from the difference between human and machine players.  It isn't clear how much can be gained from this, and the decision to include or exclude this abstraction will be made after examining interfaces that are needed.
d68 1
a68 3
	A firm division of labor will not be established until
interfaces and modules are somewhat more firm.  Temporary assignments
are as follows.  David and Sam will work on the data representation and
d74 1
a74 1
	Ronnie and Jered will focus on the machine player.  jered is also expected to help out with graphical manipulations.
a82 1

d285 1
d294 2
@


1.13
log
@Modified description of the chess_display_board abstraction.
@
text
@d185 1
a185 1
strategies for entering moves.  Three mechanisms exist for entering moves, and |game| must deal with all of these:
d187 6
d209 14
a222 1
	\item If a web request is dispatched to an inferior node such as an instance of |player| or |board|, the corresponding response is returned unmodified.  This allows for non-movement-related requests such as help, etc.
d309 1
a309 1
	\item  Has interface so |game| can notify it about moves made both by itself and by the opponent 
@


1.12
log
@Added Schedule, Validation Strategy, and Description of Progress
sections, to bring file up to requirements for Revised Design
specifications.
@
text
@d55 2
d62 1
a62 1
\item[|player|]  It is possible that a generic player abstraction will be used to insulate the |game| and |board| abstractions from the difference between human and machine players.  It isn't clear how much can be gained from this, and the decision to include or exclude this abstraction will be made after examining interfaces that are needed.
d267 4
a270 1
and destination square.
@


1.11
log
@Make lots of K00L changes
@
text
@a46 1

d79 33
d325 13
d339 2
d342 17
a358 1
\input{move-h.tex}
d360 9
d370 1
a370 1
\end{document}@


1.10
log
@Add info about class move.
@
text
@d276 4
a279 4
instances of |move| are expected to exist, |move| is a stack
abstraction.  Note that several constructors and operators on |move|
are protected, so that |move| objects are not chopped by inadvertant
copying.
d285 9
@


1.9
log
@Fixed TeX borkennesses (item, document, |, 8)
@
text
@d2 1
a2 1
% $Source: /afs/athena.mit.edu/course/6/6.170/groups/se01/.cvsroot/design/design.tex,v $
d261 1
a261 1
	\item  Accepts web requests to change the player name and time remaining.
d269 20
@


1.8
log
@Fix backslash and add \end{document}
@
text
@d2 1
a2 1
% $Source: /mit/6.170/groups/se01/.cvsroot/design/design.tex,v $
d124 1
a124 1
\section{Design of |game|}
d187 1
a187 1
\section{Design of |board|, the interface between |game| and game state}
d226 1
a226 1
\section{ Design of |chess\_display\_board|}
d229 1
a229 1
required for an $8\times\8$board where a square can hold one chess
d237 1
a237 1
\section{Design of |antichess\_board|}
d251 1
a251 1
\	\item Keeps track of time elapsed and remaining and forfeits when time runs out
d269 1
a269 3


\end{document}
@


1.7
log
@Player is a subtype of web_node
@
text
@d175 1
a175 1
unmodified response of the request.  
d177 3
a179 1
	\item  When an instance of |player| is informed of an opponent's move, it is legal for the player to make its own move by calling the appropriate method on |game|.  
d251 1
a251 1
\	item Keeps track of time elapsed and remaining and forfeits when time runs out
d269 3
@


1.6
log
@Design of player
@
text
@d245 1
a245 1
The |player| class embodies an abstract entity capable of making moves in a game.  It accomplishes the following:
d265 2
@


1.5
log
@Fix typo.
@
text
@d242 23
@


1.4
log
@Clarified web access to the server, other minor changes.
@
text
@d2 1
a2 1
% $Source: /afs/athena.mit.edu/course/6/6.170/groups/se01/.cvsroot/design/design.tex,v $
d216 1
a216 1
	\item Provide a routine to generate the board representation for inclusion in the respone to web requests to |game|.
@


1.3
log
@Changes for board and its subtypes.
@
text
@d2 1
a2 1
% $Source: /mit/6.170/groups/se01/.cvsroot/design/design.tex,v $
d82 1
a82 1
		Initially after connecting to the server, a user will be presented with a menu including at least the following options:
d110 1
a110 1
	\item  The peace that is selected  will be replaced with a image showing it as highlighted.
d112 1
a112 1
	\item  The source section of the movement entry form will be filled in with the square of the peace that is selected.
d224 1
a224 1
\section{ Design of |ches\_display\_board|}
d228 1
a228 1
peace.  This board is not aware of the rules of the game in that the
@


1.2
log
@Add basic design info for game and header for
board.
@
text
@d187 5
a191 1
	The |board| abstraction is a abstract base class inheriting from |web_node|.
d193 49
@


1.1
log
@Commit preliminary design we turned in
@
text
@d2 1
a2 1
% $Source$
d124 6
d131 53
d185 1
d187 1
a187 1
PP
@
