Iteration 10: Distribution using Broker II

Deadline

Always at 23.59 on the same day as your TA session (Except if another deadline has been agreed with the TA).

Consult the deadline for your class on the delivery plan.

Learning Goals

The primary learning goal of this iteration is to implement pass-by-reference handling in the Broker architecture, and do system testing. A secondary goal is to refactor the Invoker code so it uses multi type dispatching.

The project goal is to have a fully distributed HotStone system with the GUI integrated.

Prerequisites

Handling pass-by-reference involves quite a few new moving parts in Broker, and some FakeIt/scaffolding code from 'Broker I' needs to be undone. Be sure to study my lecture slides "W12-1" carefully, or find the lecture on Panopto/Zoom.

Kata

Spend the first 15-20 minutes of the class in plenum discussing...

The RunApp company is designing a framework for developing running apps for smartphones: the runner’s GPS location is read from the phone’s hardware device, next the location is adjusted to the nearest road or path, and the location is then shown overlaid on a graphical map; similar to the figure on the right.

Designed as a framework, it must support different GPS hardware variants (Initially: from Samsung and Apple) as well as different map services (Initially: from Apple and Google).

The central method in the RunApp app is updatePosOnMap(), which is called every 1 second by the RunApp framework code:

public class RunApp {
  [constructor here ...]
        
  public void updatePosOnMap() {
    Location loc = pollGPSLocation();
    loc = adjustLocationToBeOnARoad(loc);
    mapService.showLocationOnMap(loc);
  }
  private Location pollGPSLocation() {
    return gpsHardware.getCurrentLocation();
  }
  private Location adjustLocationToBeOnARoad(Location l) {
    // algoritms to compute nearest location
    // that is on a road/path
    return adjustedLoc;
  }
}  
        

The two delegates, gpsHardware and mapService, are provided via the constructor to the RunApp class.

Discuss the following points:

  1. Identify the Template Method and identify Frozen and Hot spots.
  2. Argue if the Template Method is made by Separation or by Unification.
  3. Argue why the first line Location loc = poll...() is a hotspot, even though it is a call to a private method in RunApp.
  4. RunApp does not implement an interface? Argue that this is an omission by the lecturer. Argue that the lecturer is correct in not letting RunApp implement any interface.
  5. In the argumentation for letting RunApp implement an interface, argue why it is incorrect to let that interface include the pollGPSLocation() method.
  6. Rewrite the above code to the other TM variant (Unification to Separation or vice versa).
  7. Define the interfaces that gpsHardware and mapService must implement.

Exercises

Broker 2.1. TDD of pass-by-reference methods in Game.

Implement the remaining Game methods that return object references (getHero(), getCardInHand(), getField(), etc.) and use object references in parameter lists (playCard(), attackCard(), etc.) using TDD.

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

Broker 2.2. System test.

Develop and manually system test/demonstrate that two HTTP based hotstone clients (target: 'hotstoneClient'), connected to the hotstone server (target: 'hotstoneServer'), each presenting the user with the MiniDraw based GUI can execute properly as a distributed system.

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

Your system test should validate that the two players can:

Broker 2.3. Refactor into SubInvokers and implement Multi Type Dispatching.

Refactor the "Blob invoker" from the previous exercise so it is split into subinvokers, and integrate into a full Multi Type Dispatcher system.

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

Deliveries:

  1. Develop on a feature branch named "iteration10" and release using a merge request.
  2. Document your group's work by following the requirements defined in the iteration 10 report template (pdf) (LaTeX source)
  3. Create one approximately 4-8 minutes long screencasts with audio narration, which demonstrates starting your HotStone server, then start two graphical clients, and perform/explain the system tests outlined in exercise Broker 2.2.

Notes and Hints

Getting started

I strongly advice to have a good look at the code base of the GameLobby system as well as the corresponding explanation in the "Flexible, Reliable, Distributed System" book. You should not implement a game lobby system but review the code to get the ideas for how to implement pass-by-reference and name service.

System testing using MiniDraw GUI

Review the process hints and coding hints in the W12-1 slide set.

In summary the exercise entails:

  1. Build a GameClient main() program
  2. Run HotStoneDrawing in the OPPONENT_MODE mode
  3. Refactor the actorMap in HotStoneDrawing so the key is unique card IDs (and the HotSeat program still works.)
  4. Create a new Tool that correctly handles tool state, so it allows playing remote games.
  5. Implement 'brute force' redrawing when a game mutator method is called, to fix the issue of the missing Observer.

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 10 Grade sheet to evaluate your submission.

Learning Goal Assessment parameters
Submission Git repository contains merge request associated with "iteration10". Git repository is not public! The system test targets all work; required artefact (report following the template, screencast video of good quality) is present.
Pass-by-Reference The implementations of the pass-by-reference methods are functionally correct (allow clients to correctly interact with associated server object through their ClientProxies), implement a suitable name service for object lookup at the server side, and the code is clean. The report document process and resulting code correctly.
System Testing The system test correctly runs a distributed SemiStone.
Multi Type Dispatching The implementations of multi type dispatching is functionally correct, sub invokers are cohesively and correctly associated with specific types, and the code is clean. The report document process and resulting code correctly.
Functional complete The HotStone mandatory project is functionally complete, i.e., all mandatory and optional requirements are implemented correctly. (You do not need to implement optional exercises, like ThetaStone, this is just extra points awarded if you have done so).