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 onCardPlay() 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.
Implement the Personalized Decks requirement (FRS 37.6.3) by finding a suitable design pattern allowing to change by addition, not by modification of your HotStone system.
- Find a suitable pattern to implement this requirement.
- Implement your design and outline code fragments as illustration.
Find details in the report template about how to document your work.
The external deck library is demonstrated in the following gradle project: demo-deck.zip. Unzip it and follow the instructions in the ReadMe.md file. To include the library in your own HotStone, you need to update the build.gradle file, see Note 1 below.
Notes: To make the exercise easier, you are not required to shuffle the deck.
Disclaimer: The personal decks cannot be used with the graphical user interface as there are no images that match the cards.
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.
Heartstone's card library lists more than 1,000 cards, most of them having all kinds of effects. To code all these effects, an analyzable way for writing (many) effects is essential.
A Bloch builder/fluent API is one such analyzable technique to do so. I have written a builder object, Effect, with setter methods and a set of finalizing execution methods. This allows me to write Tomato Salad (add +1 attack to random own minion) like this:
new Effect(mutableGame) .forMe() .forRandomMinion() .deltaAttack(+1)and Chicken Curry (remove random opponent minion) like this:
new Effect(mutableGame) .forOpponent() .forRandomMinion() .removeMinion()and Holy Nova of Hearthstone (heal all my minions by 2; deal 2 damage to all opponent minions) as:
new Effect(mutableGame) .forOpponent() .forAll() .deltaHealthOrRemove(-2); new Effect(mutableGame) .forMe() .forAll() .deltaHealthOrRemove(+2);(mutableGame is my private interface holding the mutator methods of Game).
Refactor your hero powers and card effects to use a fluent API for effects.
Deliveries:
To make your project's build.gradle use the personal deck builder library you need to do this:
- Update the repository section to include SonaTypes snapshot repository:
// The deck building library is not an official library, so I have put it // in a SNAPSHOT repository that needs the full URL to pull. repositories { maven { url "https://s01.oss.sonatype.org/content/repositories/snapshots/" } mavenCentral() }- Include a dependency to 'hotstone-deck' version 1.0-SNAPSHOT:
dependencies { [your existing dependencies here] implementation 'com.baerbak.maven:hotstone-deck:1.0-SNAPSHOT' }- I often experience that IntelliJ does not understand, that a new dependency has been added. If you experience the same, you can call up the Gradle View and refresh it: Hit the menu item 'View' -> 'Tools Window' -> 'Gradle'. This will show a new window, and you have to click the 'Refresh' button, as shown below:
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 way too often), 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 + Personalized Decks | Correct design patterns are selected, the argumentation for choosing them is correct, and they are correctly implemented. |