Iteration 8: Frameworks and MiniDraw

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 learning goals of this week is frameworks aspects: analyzing your current HotStone system as a framework, as well as adding a graphical user interface for HotStone using the MiniDraw framework.

Code update 5-11-2024

The handed out code below is missing the class below, which contains a function to compute the 'atIndex' parameter to the 'playCard(..., atIndex)' call in your PlayCardTool.

Find DropZone in DropZone.java and put it into package hotstone.view.tool.

You can use it like the following example shows in your PlayCardTool:

  @Override
  public void mouseUp(MouseEvent e, int x, int y) {
    // Note: no check if draggedActor is null, as it is guaranteed
    // Invoke related facade method, if figure is a card
    boolean isHittingField = y < GfxConstants.Y_LIMIT_OF_FIELD;
    boolean moveCardBack = true;

    if (isHittingField) {
      Card associatedCard = draggedActor.getAssociatedCard();
      int index = DropZone.computeFieldIndexOfDropPosition(editor.drawing(),
              draggedActor.displayBox().getX(),
              draggedActor.displayBox().getY());
      ....
              
        

Alternatively, just always drop the card at index 0.

Kata

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

... One Step Test using scaffolding code

TDD and One Step Test tells us to to keep focus, take small steps and pick a next test (target of attention) from our list of tests/requirements which is doable and will teach us something.

When developing the From Domain to GUI coupling between your HotStone domain code (Game) and the MiniDraw GUI's visual representation of all game elements (HotStoneDrawing and its associated Figure instances) we have the problem that Game mutator method calls can not be made from the GUI, as we have not developed the MiniDraw tools yet.

This is a classic "mutual dependency" issue, and the solution is to "break that dependency". In the exercise below it is solved by introducing a kind of Fake Object: the TriggerUpdateTool (FRS §37.7.3) which acts a a surrogate/replacement of the real soon-to-be-developed tools.

1. Outline how the test-driven rhythm's five steps are translated into a visual testing process that involves adding code to the TriggerUpdateTool?
2. In building construction, a temporary construction, the scaffolding is used to support the building process of, say, a house. Compare that concept to our "ShowUpdate" visual test program and its TriggerUpdateTool.
3. Argue what benefits we get from this "scaffolding" code compared to building both MiniDraw Tools and Drawing code in one single process? [Combining all complex integrations tasks in a single development step is known in the testing community as Big Bang Integration - with a stress on Bang :) ]

Prerequisites

Ensure you have completely solved the Observer pattern exercise from Iteration 7. If not, you will never get the GUI running!

Carefully read FRS 37.7 "Frameworks" as it details the design you are required to implement, and the support code. You must carefully merge your own code with the provided code base 'hotstone-framework-start (ZIP)' code, the link is given below. See the hints below.

My slides from Week 9 on "HotStone GUI" provides further details and hints on the exercises.

Exercises

Frameworks

Analyse whether your HotStone production code is a framework, using the framework characteristics.

1. Contrast HotStone with the characteristics of frameworks (Section 32.2).
2. Find examples of frozen and hot spots.
3. Find examples of TEMPLATE METHOD in your HotStone

Merge MiniDraw Starter Code

Download the hotstone-framework-start (ZIP) and merge it carefully into your HotStone project using the process I outline below in the Hints section. If you just extract the zip in your HotStone folder, you will overwrite some of your existing code!

From Domain to GUI

This exercise is partially solved in the handed-out code base.

Complete the implementation of the provided but incomplete HotStoneDrawing class such that all state changes in a Game are observed and reflected in proper GUI updates.

Visual test class: ShowUpdate (package: hotstone.domain2gui), gradle target: update. Be sure to read the details in FRS 37.7.3!

It is advisable to integrate directly with a simple, real HotStone variant (for example AlphaStone) compared to using a Test Double/FakeObject. See the explanation in FRS 37.7.3.

From GUI to Domain

This exercise is partially solved in the handed-out code base.

Complete the implementation of the MiniDraw Tools such that all graphical interactions are translated into the correct game mutator calls.

Visual test class: ShowTools (package: hotstone.gui2domain), gradle target: tools. Be sure to read the details in FRS 37.7.4!

SemiStone System Testing

Develop a complete GUI based SemiStone for system testing: Combine your developed SemiStone variant from the previous mandatory sprints with the solutions to this iteration's exercises.

Main class: HotSeatStone, gradle target: hotseatstone. Executing this target should start a full HotStone game in hotseat mode, allowing you to play with a group member. Congratulations :).

Deliveries:

1. Develop on a feature branch named "iteration8" and release using a merge request.
2. Documentation for your work on framework analysis by following the requirements defined in the iteration 8 report template (pdf) (LaTeX source), including any backlog items you have.
3. Create one 6-12 minute screencast that details your solution to the SemiStone System Testing. Specifically, your screencast must be structured with
   1. Intro: State your names and group name
   2. Execute your 'hotseat' target and demonstrate "playing a couple of turns" involving card play, minion attack, hero power use, and swapping players/ending turns.
   3. Explain how your code handles updating graphics correctly when a minion attacks another minion, by running the 'update' target showing this aspect; next show and explain the HotStoneDrawing code which handles the respective observer notifications ('onAttackCard()', 'onCardUpdate()', etc.)
   4. Explain how your 'MinionAttackTool' works by running the gradle target 'tools' and demonstrating how the game's method is called; next show and explain the tool's code.
   In your screencast, you should clearly indicate which of the above parts you are about to cast ("We next describe item 4: The code for our MinionAttackTool looks like this, ..., and here we see it in action as we drag a minion ..." etc.).

Notes and Hints

Merge MiniDraw code into your existing code base

You have developed a lot of code, and now comes a new ZIP with even more code which poses the challenge of overwriting stuff. Be sure to make an 'integration' branch of your code and merge/extract the Zip file there, so you can "Do Over" in case it messes up.

I advice to unzip the supplied framework starter code in a distinct folder, and test that you can run the visual targes, like ShowText etc., correctly.

The process is that you can simply unzip or copy the contents of the Zip file onto your own code base (ensure that folders align up). This WILL overwrite some of your implementation files (probably 'StandardHotStoneGame.java' and 'TestAlphaStone.java'), so keep a backup ready or selectively merge from your main branch.

Next compile and test, and fix all issues until all is fixed. Run also the visual tests, like 'gradle update', etc.

When all your own test cases work; and the newly added programs run (ShowTools, etc.); then merge back into your main branch and push to the repository.

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