8 —
Due Thursday, 19 November 2020, 11:59:59pm
Delivery Place the product of this week’s project steps into your repo as follows:
for the Programming Task, place manager.PP into the Admin/ directory;
for the Design Task, place remote.md in Planning/
for the Testing Task, place xref and Tests/ in a repo-level directory named 8
Programming Task Implement the tournament manager.
Do not worry about how players sign up; this piece of functionality is added when we get to the communication layer. Once all players for a tournament are "signed up", they are handed to the tournament manager.
The purpose of the manager is to run a single game tournament until a winner or several winners emerge. Its first task is to inform the players that the tournament has begun.
The tournament uses a knock-out elimination system. The top finisher(s) of every game of round n move on to round n+1. The tournament ends when two tournament rounds of games in a row produce the exact same winners, when there are too few players for a single game, or when the number of participants has become small enough to run a single final game (and yes this game is run). In both cases, the surviving players winners of all games share the Billion Thalers (nah, make this a Trillion; we’re all printing money now) FishHacker Award.
The allocation of players to games works as follows. The manager starts by assigning them to games with the maximal number of participants permitted in ascending order of age. Once the number of remaining players drops below the maximal number and can’t form a game, the manager backtracks by one game and tries games of size one less than the maximal number and so on until all players are assigned.
When the tournament is over, the manager informs all remaining active players whether they won or lost. Winners that fail to accept this message become losers.
Design Task We have reached the end of the second prototype stage. Our investors are happy with the tournament demo. It is time to plan for the third and final stage, getting ready for the release. See Fish.Com, a Plan.
Design a remote collaboration protocol. The design document should consist of two parts. The first one is an interaction diagram that specifies the timing and the kinds of interactions between the Fish.com server (plus its relevant components) and remote clients (and their relevant components). The second part of the document describes the first with English prose.
Start with the logical interaction diagram, sever the connections between
the administrative and the player side, and develop a layer that connects the
two parts. This last step demands both the design of new components and message
formats.—
Writing down a design specification twice is a debugging strategy. You and/or the recipients will notice discrepancies between the two descriptions and iron them out before the implementation starts.
Two pages should suffice. Less is more.
Testing Task Create a test harness named xref The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create three tests and place them in Tests/.
The tests are formulated as pairs of files: <n>-in.json, the input, and <n>-out.json, the expected result, for an integer <n> greater or equal to 1.
Its inputs are objects:
{ "row" : Natural in [2,5], |
"column" : Natural in [2,5], |
"fish" : Natural in [1,5] } |
|
The "players" field specifies an array whose length is in [2,4]. |
The pairwise distinct strings in this array are non-empty and consist of at |
most 12 alphabetical ASCII characters. Finally, the player |
specifications in this array are arranged in ascending |
order of age |
INTERPRETATION The object requests that the referee runs a game with
the specified number of players on a "row" by "column" board with
each tile populated by exactly the number of fish specified in the
object. The board must be large enough to accommodate all penguins allocated to the players. Each player uses the strategy from 5 —
Well-formed and Valid You may assume that all inputs for your test harnesses will be well-formed JSON and valid according to the homework descriptions.
The expected output type is [String, .., String], the result of runnung the specified game. The Strings must be arranged in ascending lexicographic order (see string<=?).
INTERPRETATION The array represents the players that shared first place.