6.5.0.3

3 — Development includes maintenance

Due Sunday, 31 January, midnight

The assignment consists of two separate tasks. The first one illustrates simple maintenance tasks and underlines why following basic design principles from the beginning reduces the time and cost of a project. The second concerns the design of a protocol, an interface specification between two remote parties.

If you already created a player implementation for project 2, that’s fine. Move the files to 3/ and re-link them to 2/ as needed so that they run from there.

Task 1 Implement the player component that you imagined when you completed 2 — Living up to interfaces (task 2). Connect it to the rest of your 6 Nimmt! system in your folder ../2/ so that you can run complete game simulations with 2, 3, and 4 players.

Create git-diffs patches for directory 2/ for two situations:
  • A mandatory git-diff patch must modify the main component in 2/ so that it refers to the new player component in 3/. If this git-diff patch requires more than one code line of change, justify the change in your README file.

  • If your work uncovers bugs in the rest of the system (2/), also create git-diffs patches and add them to your directory.

Explain all git-diffs patches in README.txt. We will inspect them and may apply them to create running systems.

Once you have your own implementation of a player, create git-diffs patches that implement the following requests from management:
  1. Force players to pick up a stack if it is six cards deep instead of just five. Call the resulting game take6.

  2. Use 210 cards with face values between 1 and 210.

  3. Hand players nine cards instead of ten at the beginning of a round.

  4. Permanently increase the minimum bull points on all cards from 2 to 3.

  5. Implement a player who places cards in increasing order of face value during a round.

These changes are simple and should consist of a single, one-line change to the entire program. For any git-diff patch that consists of more than one code line, explain in the README.txt file why you had to change more than one line.

Your diffs and their documentation ought to live up to a simple claim: if we apply the diffs, the test suite will still run successfully and it is possible to perform complete runs from the command line.

Delivery Create a sub-directory named take5 within your assignment’s folder and place all relevant files into this folder. We will run your main file in 2/ as explained in your README there.

Task 2 Your marketing department has decided to let real-world players develop player-strategy software so that they can participate in large-scale take5 tournaments playing their favorite strategies. You are turning your existing, statically linked system into a distributed one with dynamic connections. Naturally your company doesn’t wish to integrate bad, broken or malicious software into its code base, meaning it will offer this tournament option via a remote-procedure protocol. Your company’s software will run on its severs; the players will run on their creators’ computers; and these components are connected via protocols.

Your task is to develop the communication protocol. Assume servers and players exist independently, and assume that players must actively register with a server to participate in a game. Otherwise, base the protocol specification on your system design.

Learn from the lessons of your first out-sourcing attempt. A protocol comprises three essential pieces: an interaction diagram including signatures for the messages between different components, precise specifications of the data format for the messages, and timing constraints that are not expressible in the diagram. Use English and JSON to describe the data format of the messages; it is the current teenage-heartbreak data-exchange description language.

Delivery Deposit a plain text file into your assignment’s folder and name it player-protocol.txt. The file must contain an ASCII-art diagram and whatever you deem necessary to make the protocol implementable.