Due Monday, October 01, midnight
Admin, which is where all the administrator-specific code goes;
Player for all the player-specific code codes;
Common, which is where you place all code that both administrative components and player components need to access; and
Lib, for all library-like code you may need.
Also create a top-level directory 6. Place the xboard artifact in there and place all system-level tests into 6/board-tests.
Design Task The player and the administrative components must communicate. To this end, they must use a common form of data with a common interpretation.You may encounter the terminology of ontology in software engineering courses in this context.
the physical game pieces, see below
the rules of the game
Develop a specification of the rule checker’s interface. This interface must allow either of the two (players, administrators) to check the basic rules of the game.
The rule checker’s implementation will also reside in the Common directory of course.
the player interface
Develop a specification of the player’s interface. This interface must enable an administrative component to take a player component thru all phases of the game.
Recall that software components go thru start up (initialization), steady state, and shut down phases. We are ignoring configurations for now.
Write up your interface specification as a single source file in your chosen language. A good specification will mix technical terms from your language (e.g. function headers, interfaces) and English (purpose statements or data definitions in untyped languages). Keep in mind that a specification must define all terms. Make sure to start the file with a purpose statement.
Implementation Task Implement a data representation of the physical game pieces (the board, buildings, workers, etc.) and their functional capabilities (e.g., you can move a worker from one cell to another).
It is the playing field and consists of 36 squares.
The squares may contain a building up to four stories tall.
Services A board implementation must be able to move workers, add floors to buildings, and observe basic facts about squares that a player module considers relative to one of its workers.
Mock-up Context To test such a small system of a number of components, it is common to implement a mock-up environment.
A Board is [[Cell, ...], ...].
A Worker is a string of lowercase letters that ends in either 1 or 2. The last digit indicates whether it is the first or the second worker of a player. The lowercase letters make up the Name of the player that owns the worker.
A Board specification is valid if it has at most six rows and each row consists of at most six cells. A "short" Board is supplemented with empty rows. It must also contain exactly four Workers, two per player.
The harness moves the specified worker in the given direction and prints the empty JSON array.
The harness increases the building on the specified cell in the given direction and prints the empty JSON array.
The query determines whether there is a cell in the give direction, and the harness prints "yes" or "no".
The query determines whether there is worker on the cell in the give direction, and the harness prints "yes" or "no".
It yields the Height of the building that the worker is looking at.
These JSON values do not represent the interface (function/method call) that a board implementation should use, though the test harness must be able to interpret such requests smoothly with the given interface. It does not at all represent my board's interface.
Testing Task Develop at most five system-level tests to be used with your test harness. A test consists of a pair of files: n-in.json and n-out.json where n is in 1, 2, 3, 4 or 5.