►Software Development
▼—Project Milestones
•7 — The Clean Up
8.15.0.6
    contents    up   

7 — The Clean Up🔗

Due Thursday, 31 November 2024 Thursday, 31 October 2024, 11:59:59pm

Purpose This milestone has several distinct learning goals:

A software system must be robust. Badly behaving, non-essential components must not bring down the system. In our software system, players—potentially produced by independent and potentially unreliable consultants—are non-essential components; the referee on the other hand is the core of the system together with components such as the rule book or the state representation. Think of your IDE, which is extensible with “modes” and tools; if one of these plug-in breaks, you don’t want the IDE to stop working.

Delivery Place the product of this week’s milestone into your git repo as follows:

Programming (Clean-up) Tasks Like all software projects, yours has accumulated a significant technical debt, partly due to the usual kinds of disagreement between your "customer" and you, mostly due to the usual deadline stress.

Your team manager has decided that the project needs to reduce this debt now that you will have a new partner soon. This will give you a chance to work through design rationales, rewrite or document all difficult to decipher code snippets, and reassess the qualities of the code base in general.

Step 1 Compile a list of todo items and priority-rank them. Commit and push as todo.md.

For sources of problems, consider the feedback you have gotten for the past six milestones. Still-failing integration tests should get the highest priority. Also, revisit all those purpose statements, complicated methods, overly large functions, and unit-test suites about which the TAs/reviewers complained.

Step 2 Work through this todo list. As you complete an item, move it from the todo list to a separate section, entitled “Completed.” Add the git commits plus the commit messages that fix the issue.

The TAs will cross-check that at the end all git commits are accounted for.

Guidance A clean-up task should always look forward, attempt to anticipate how the software may evolve. Here we provide two explicit prompts:

  1. Imagine a change to the points awarded for purchasing cards. If the table were to change, how many of your literal constants in the code would have to change?

    Pedagogy Implementing such a change points out infractions of rather basic design rules that may have significant repercussions in terms of technical debt. Think of this scenario as a simple example.

  2. The co-CEOs are considering changes to the rules and would like to know from their development team how difficult it would be to accommodate one or all of the following changes:

    • make all basic Bazaar game constants configurable;

    • modify the strategies so that a player trades even if it cannot buy a card after the trade; or

    • add a rule that rewards players at the end of the game for buying cards with certain characteristics, say cards with just "red" pebbles.

    Study the impact of each change on your code base. Rank it on a scale of 1 (extremely easy) to 5 (extremely hard) and explain your choice with one to three complete sentences. The memo in changes.md should not take more than a page.

    Note The decision has been made. Your answer will not influence the choice.

Additionally, the following testing task may demand “pay down” but, in principle, it should not. It essentially asks for a minor revision of your test script from 6 — Games!; the referee component and the player directory should already implement the functionality.

Testing Task Create a test harness named xgames. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create tests ([0-9]-{in,out}.json) and place them in the specified Tests/ folder.

A test case always consists of given inputs and expected outputs. For this course, a test consists of a pair of files: n-in.json, the input file, and n-out.json, the expected output file, where n is an integer between 0 and the requested number of tests (exclusive).—Constraint No test file may exceed the size limit of 40Kb.

The inputs of xgames consist of three JSON values:
Think of these values as a description of an interrupted game that replacement players wish to continue from where others left off. Since these new players don’t know the equations or the state of the game, they need to informed—meaning the referee starts by setting up each player with its corresponding state.

Technically, the test harness creates players that are going to use the specified strategies. It then hands these players the equations. At this point, it suffice to start granting turns, because according to Logical Interactions, granting a turn means informing players of the game state. The referee runs the game to its end and delivers the winning players and the drop-out players to the test harness, which computes and sorts their names.

The output consists of two arrays: (1) the first contains the alphabetically sorted (string<=?) ActorNames, of winners and (2) the second the alphabetically sorted event-sorted ActorNames of dropout players meaning the drop-out list enumerates the names of the player in the order in which they got kicked out.

Once the referee has determined the winners and losers, this ranking stands and will not change be re-computed. But, if players fail during the win calls, their names get moved from this ranking to the list of dropouts.

Here are the relevant data definitions:

    *Actors is a JSON array of Actors: [Actor, ..., Actor]

     CONSTRAINT A *Actors array contains at most 6 items.

     CONSTRAINT The names of any two different Actors must be distinct.

    

    An Actor is one of:

      - a JSON array of two elements: [ActorName, Policy]

         INTERPRETATION Denotes a well-behaved player.

           A good actor [n, p] denotes a player named `n` that pursues

           the maximization strategy `p` throughout the game and always

           requests legal actions.

    

      - a JSON array of three elements: [ActorName, Policy, Exn]

         INTERPRETATION Denotes an exception-raising player.

           An exn player [n, p, xn] denotes a player named `n` that pursues the

           maximization strategy `p` until method `xn` is called. When `xn` is

           called, it raises an exception.

    

    A Exn is one of: "setup","request-pebble-or-trades","request-cards","win".

    

    An ActorName is a string of at least one and at most 20 alpha-numeric

     characters, i.e., it also matches the regular expression "^[a-zA-Z0-9]+$".

    

     GLOBAL CONSTRAINT The array of Players in Game contains as many items

       as the *Actors array.

    

     GLOBAL INTERPRETATION The referee's knowledge about players is in the same

      order as those in the given *Actors specification.

    contents    up