Assignment 4 – Backgammon:   the rule checker
1 Design, Build and Test

Assignment 4 – Backgammon: the rule checker

Due Wednesday 4/21 5:00pm for the testing deliverables and Friday 4/23 11:59pm for the code deliverables

1 Design, Build and Test

Take a look back at the component you built for assignment 3. If it doesn’t consist of at least two separate libraries (one for backgammon boards and one for marshaling/unmarshaling JSON values), then refactor your code from last week.

When you have a separate library for boards, re-use it to implement a rule checker for the rules of Backgammon.

It is up to you to decide what specific interface your component should implement and how. However, your code should come with a clear description of the interface you pick that includes an account of all operations the component is supposed to provide and all their contracts. You should also enhance your implementation with code that enforces as many of these contracts as possible and produces appropriate errors if it discovers that the contracts are violated. At the very least, your rule-checker should provide a way to decide whether a turn is legal.

If, while implementing the rule-checker, you realize that your board component does not provide all the operations you need, feel free to revisit its design and implementation. However, do record these changes so that we can discuss them during the code walks.

For this week, the JSON specification builds on that in assignment 3 (but the extra rules about boards and moves are different, as below). Here’s the input and output specification:

test-case-4

 ::= 

[ board, color, dice, turn ]

turn

 ::= 

[ [ cpos, cpos ], ... ]

dice

 ::= 

[ die, die ]

 | 

[ die, die, die, die ]

die

 ::= 

1 | 2 | 3 | 4 | 5 | 6

test-case-4-result

 ::= 

false

 | 

board

You are determining if the turn is legal. If it is illegal, your result should simply be false. If the turn is legal, the result should be the new board, after the turn has occurred. Note that bops are not shown as explicit checker moves – they must be inferred from the moves that do the bopping as they will affect the final board.

These are the additional rules about the input and output:
  • As with assignment 3, you may assume that number of cpos in each of the black and white portions of board is exactly 15 and that the checkers are sorted; your results must also be in that form.

  • You may also assume that each point on the board contains either white or black checkers, but not both. (Of course, the home and the bar may contain both colors of checkers.)

  • You may not assume that the starting point of a move contains a checker. Instead, you must check for it and declare the move illegal if there aren’t any checkers of the right color on the starting point.

  • You may assume that the dice are legal, i.e., if there are two dice, the numbers are different and if there are four dice, the numbers are the same according to backgammon doubling rule for dice.

Everything else about the legality of the turn you must check yourself.

Testing Deliverables: In your team’s GitHub repository, create a directory "Deliverables/4/4.1/" and deposit there at least five input files for the test driver and their expected output files. Each input file should contain one valid JSON value, as described above. Use the same naming convention as in previous assignments.

You will receive up to ten points for your tests, two points for each valid pair of input and output files.

Code Deliverables: In your team’s GitHub repository, create a directory "Deliverables/4/4.1/" and deposit there a Makefile for your test driver.

You will receive up to fifty points for your rule checker depending on how many tests its test driver passes.