Iteration 9: Distribution using Broker I

Deadline

At 23.59 on the day that your class has agreed with the TA.

Any late hand-in must be agreed with your TA; failing to do so will allow the TA to reject evaluating your hand-in.

Workload Estimate

Medium

Learning Goals

The primary learning goal of this iteration is understanding and implementing Broker delegates to make HotStone into a distributed system. A secondary learning goal is reinforced learning of how test doubles can be used to have automated testing of (much of) a distributed system. And third, you will revisit EC testing.

The product goal is to get all methods that are pass-by-value only developed for HotStone.

Learning Context

HotStone is suited for a Broker based client-server system: The central Game interface is a Facade pattern which serves as the role to split between client and server. On a central server a GameServant keeps track of the game's state, while a number of clients run a HotStone GUI (one for each player) which interacts with the game state via GameClientProxy, CardClientProxy, and HeroClientProxy. However, it is also complex in the sense that the GameServant will create new objects (like new cards) that must be accessible on the client side. And, it uses the Observer pattern for the UI, which our Broker pattern cannot handle, and thus needs special care.

Therefore, the development will be broken into two iterations:

1. Iteration 9 (this one): Here you will develop distribution for those methods in interface Game, Card, and Hero that does not involve objects references, and you will develop the two main programs, one for the server and one for the client.
2. Iteration 10 (next one): Here you will extend your Broker system to the methods that are pass-by-reference (getCardInHand(), playCard(), etc.), and you will make the MiniDraw GUI operate in the clients, to allow a full distributed system.

Prerequisites

Download the hotstone-broker-start (ZIP) and create an integration branch and merge it into your HotStone project. It should merge cleanly with your previous HotStone + MiniDraw code, and not overwrite anything this time.

Broker takes some time to understand as there are quite a lot of moving parts involved. Be sure to study my lecture slides "W11-1 Mandatory Intro" carefully, or find the lecture on Panopto. It contains detailed guides on how to start the process of solving the exercises.

I also recommend to study and experiment with the TeleMed code first. You will find it in TeleMed folder in the FRDS.Broker Library.

Exercises

Broker 1.1. TDD of pass-by-value Game methods

Use TDD and test doubles to develop well tested Broker role implementations of the Game's ClientProxy and Invoker role for pure pass-by-value methods under automated testing control.

Find details in the report template about how to document your work.

Note: There are only a few methods that are purely pass-by-value: getTurnNumber(), getHandSize(who), endTurn(), etc.

As a simplification you should let your server only handle a single game (only a singleton GameServant instance.) In the Broker Starter Code, you will find an initial (failing) test case in hotstone.broker.TestGameBroker, that you can use as starting point.

Broker 1.2. TDD of Card and Hero methods

Use TDD, test doubles, and "FakeSomeOfIt" to develop well tested Broker role implementations of the ClientProxies and Invoker(s) to handle all Card and Hero methods.

Find details in the report template about how to document your work.

Important: Handle the server side method dispatch for Game, Card and Hero methods in a single "blob" Invoker. Otherwise you will run into trouble in the Broker II exercise, find details in the W11-1 slides.

Broker 1.3. Integration test

Extend the provided MANUAL test client (target: 'hotstoneStorytest'), and demonstrate distributed execution on 'localhost'.

Find details in the report template about how to document your work.

Test your developed code in exercise 1.1 by letting the manual test client execute a user story ala:

1. Connect to the HotStoneServer and establish the GameClientProxy.
2. Executes a few of the developed pass-by-value methods (getPlayerInTurn(), getTurnNumber(), getDeckSize(), endTurn(), etc.) and outputs the returned value (if any) as shell output, as a manual test.

EC test of SigmaStone 'augmentMinion()'

Define a minimal set of test cases for the 'augmentMinion(...)' function defined by the SigmaStone game (FRS § 37.8.2), using the systematic black-box testing technique equivalence class partitioning.

Find details in the report template about how to document your work.

This is a pure theoretical exercise, SigmaStone should not be implemented.

1. Outline a list of the relevant conditions that influence augmentMinion().
2. Document an EC equivalence class table that enumerates all your found equivalence classes and briefly argue for the representation property and the set's coverage property.
3. Document a extended test case table of concrete test cases defined from the previous analysis, and argue for the heuristics applied to generate them.

You should assume that preconditions are met so ignore all the situations like 'trying to attack with opponents card, player is not in turn', etc.

Consider the representation property carefully and repartition when you are in doubt. For instance, field support is at first glance just the range 0..4. However, 0 is neutral element and not representative because if all test cases uses field support = 0, then no tests will validate if the method to calculate support is correct or added correctly. Thus, this set must be repartitioned. Next, you may consider if opponent fielded minions of the same class are by mistake added as support.

Deliveries:

1. Develop on a feature branch named "iteration9" and release using a merge.
2. Document your group's work by following the requirements defined in the iteration 9 report template (pdf) (LaTeX source)

Notes and Hints

... on Broker 1.3 Integration Test

Exercises 1.1 and 1.2 use a FakeObject IPC layer/network layer. The goal of the 1.3 Integration Test exercise is to demonstrate that a real client-server system is 'clean code that works'. As shown in my own solution below, I first start the hotstone server in one shell ('hotstoneServer'); and next run the manual test client program ('hotstoneStoryTest') in a second shell. Thus they run as a real client-server system using the network, even though they communicate over 'localhost' and thus not "very remotely".

Evaluation criteria

Your submission is evaluated against the learning goals and adherence to the submission guidelines. The grading is explained in Grading Guidelines. The TAs will use the Iteration 9 Grade sheet to evaluate your submission.