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.
In this iteration, the learning goal is to use equivalence-class partitioning as technique to develop high quality test cases, and to apply a set of design patterns from the FRS catalog to your HotStone design.
Spend the first 15-20 minutes of the class in plenum discussing...
The learning goal of this kata is to explore the new role that Game must support: to be Observable; and thus help you in solving the 'Observer' exercise below.
Study FRS § 37.6 carefully, as it outlines the protocol to use in our HotStone system. You will find the full GameObserver interface in: GameObserver.java, and the Observable interface in Observable.java.
Consider the following scenarios during a HotStone game, and
sketch the expected call sequence of onX()
that
will arrive at the Observer of the game (no coding, just draw
a sequence diagram or list the onX()
calls as
shown below):
onUsePower(FINDUS) - due to the mutator being called onHeroUpdate(FINDUS) - due to hero spending mana onHeroUpdate(PEDDERSEN) - due to opponent health reduced
Furthermore, discuss the distinction between 'Direct' and 'Indirect/derived' events in the GameObserver interface. What reasons can there be for including the 'Direct' onX() calls?
Define a minimal set of test cases for the 'attack(who, card, opp)' function for the RhoStone game (FRS § 37.8.1), using the systematic black-box testing technique equivalence class partitioning.
Note: You should not implement RhoStone. This is a purely theoretical exercise.
This exercise is not to be handed in until Iteration 9! It is just a pre release so - read it, understand it, and let your subconscience work on it.
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.
The graphical user interface introduced in the next iteration accesses and modifies the HotStone game's state through the Game interface.
Argue whether the Game interface is a FACADE pattern or not. Argue for benefits and liabilities of this design.
Review the description of the observer system in HotStone in FRS 2nd Edition Section 37.6.1.
Use TDD to enhance your HotStone game system to notify observers of all relevant state changes.
Find details in the report template about how to document your work.
As outlined in FRS Section 37.6, take care to avoid unnecessary observer updates: do not emit onPlayCard() events if the card was not played due to the hero having too little mana left, etc.
You will find the GameObserver interface in: GameObserver.java, and the Observable interface in Observable.java. It is important that you respect the package structure to prepare for the user interface exercises later.
You can of course code all the notification algorithms in your game implementation, but that is not the Compositional way. Use a delegate instead. I have coded a ObserverHandler.java which can lessen your work effort a bit.
Hint: You need a specific type of test double to solve this exercise. Which one?
Your HotStone system evolved into supporting BetaStone, GammaStone, ect., by using the 3-1-2 process/compositional design to introduce Strategies. Or... Were they really Strategy patterns after all?
Analyze each of your compositional designs/developed strategies carefully and determine if they are really a Strategy or actually some other design pattern, like Command, Abstract Factory, or ?
Review the description of transcripting in HotStone in FRS 2nd Edition Section 37.6.2.
Enhance your HotStone game system with transcripting.
- Find a suitable design pattern to implement this requirement so any HotStone variant can be transcribed. Your implementation must be purely change by addition, not by modification. Specifically it is required not to use your Observer pattern.
- Implement your design and outline code fragments as illustration. Explain how you can turn transcribing on and off during the game.
Find details in the report template about how to document your work.
Notes:In this exercise, it is allowed to demonstrate that your transcript is working using manual tests, that is, just print the transcript using "System.out". This will lower your workload, compared to using a Test Spy.
Refactor (parts of) your EtaStone card effects to use the WizardHub effect library as outlined in FRS §37.6.3, by implementing an Adapter for your MutableGame private interface.
- Sketch an UML for your adapter design.
- Refactor (parts of) your EtaStone card effects using WizardHub.
- Outline the Adapter code.
Find details in the report template about how to document your work.
Read the hint below to get the library into your IntelliJ/Gradle project.
Draw a role diagram (see Chapter 18) showing the part of the HotStone design that handles finding a winner of the game. The diagram must include all winner variants.
Relate your design to the concepts of behavior, responsibility, role, and protocol. Find examples of abstractions, objects, and interactions in your HotStone system that are covered by each of the concepts above.
Deliveries:
To make your project's build.gradle use WizardHub library you need to do this:
- Include a dependency to 'wizardhub' version 1.0.0:
dependencies { [your existing dependencies here] // Maven Central dependency on WizardHub implementation group: 'com.baerbak.maven', name: 'wizardhub', version: '1.0.0' }- If you edit your build.gradle in IntelliJ, you need to tell IntelliJ to 'reload the build script' using the 'elephant' button that appears in the top-right corner of the window.
Now, the library is available in your project, and you can use name completion, etc. - If IntelliJ chokes completely and does not understand that it is a Java/Gradle project (as I experience sometimes), try 'rebooting' the project as outlined in my IntelliJ tutorial (Section "Panic Button").
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 7 Grade sheet to evaluate your submission.
Learning Goal | Assessment parameters |
Submission | Git repository contains merge request associated with "iteration7". Git repository is not public! Required artifacts (report following the template) are present. |
EC of attack() | A correct EC partitioning has been made, clearly describing and arguing for the partitioning heuristics used, and documented correctly in an EC table. Coverage and representation properties have been analyzed and discussed. |
Observer | The implementation of Observer is correct. The test cases are correct. |
Facade + Role diagram | The argumentation for Facade is correct and comprehensive. The role diagram is correct and argumentation is correct. |
Transcript | A correct design pattern is selected, the argumentation for choosing it is correct, and it is correctly implemented. |
Adapter | The UML diagram is correct, and proper code examples and argumentation are presented. |