Always at 23.59 on the same day as your TA session. (Except Monday classes)
Consult the deadline for your class on the delivery plan.
The learning goals of this week are twofold: working on one more equivalence partitioning exercise, as well as working on frameworks. The framework aspect is dealt with in two aspects: analyzing your current HotCiv system as a framework, as well as adding a graphical user interface for HotCiv using the MiniDraw framework.
Solve and document exercises:
Use EC techniques to develop a minimal set of high quality test cases for the attack function O()
Augment your EC analysis with boundary value test cases
Analyse HotCiv using framework concepts
Download the hotciv-framework-start (ZIP) and merge it carefully into your HotCiv project using the process I outline below in the Hints section. If you just extract the zip in your HotCiv folder, you will overwrite some of your existing code!
Next, use the updated project to solve the following FRS exercises. Note that the build file in the new zip has all the template Gradle targets and also the framework starter code has template Java code for each exercise.
CivDrawingclass such that all state changes in a Game are observed and reflected in proper GUI updates. (Hint: It is a bad idea to integrate with your real HotCiv Game implementation, instead extend the provided StubGame2.java or make another stub implementation, to avoid difficult-to-test conditions. (Note that some 'observer related' code needs to be copied/duplicated from the Observer exercise above into your stub game). Gradle target: update
My slides from Week 9 provides further details and hints on the exercises.
The MiniDraw JavaDoc and source code can come in handy - it will be installed automatically in IntelliJ, if you follow the guide below in the Hints section. Note: Do not use MiniDraw's BoardGame extension, as this is geared towards games that do not create/destroy objects.
I strongly advice to take small steps to avoid a lot of confusion. Here is my suggestion to a good process.
public void addObserver(GameObserver observer); public void setTileFocus(Position position);
By now, you should have all your own code compiling and passing all tests, and have all the new graphical targets executing to show graphical output with the MiniDraw based user interface.
And if you did it on a branch, merge it back to your master development branch.
Finally, IntelliJ probably does not understand the new dependency, Hit the menu item 'View' -> 'Tools Window' -> 'Gradle', click the 'Refresh' button:
Now, the MiniDraw library is available in your project, including the source code so you can actually 'Ctrl-B' on any Broker interface/class and browse the code; and the JavaDoc is also available.
The Composition tool needs to switch on the 'stuff' which is underneath to decide which tool it should delegate to: dragging a unit requires UnitMoveTool state, clicking the End of turn shield requires EndOfTurnTool state, etc. You have several options to handle that but all of them basically includes a switch 'on something' (it is a state machine, right).
The question is what 'something' is. Here are some suggestions.
drawing().findFigure(x,y). Most interesting spots to click are represented by MiniDraw figures, so if there is a figure there, you will get a non-null reference. The origin of that figure can be found using
f.displayBox().getLocation();which can be compared with the coordinates in GfxConstants.
instanceofto identify which figure you are clicking. Note that you end up with a lot of 'empty' subclasses (non behavioural polymorphic variation), only used to identify figure type which I generally advice against. An approach like the one I used for Tile types in Game (a 'getType()' method) is more flexible.
To handle shift-click'ing stuff: The MiniDraw tool receives the mouse event as a parameter, and you can test if the shift key is down using e.isShiftDown() (or use the MouseEvent's modifier bitmask: e.getModifiersEx() & InputEvent.SHIFT_DOWN_MASK will evaluate true in case the shift key was down during a click.)
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. The score counts towards your final grade.
|Learning Goal||Assessment parameters|
|Submission||Git repository can be pulled using "Release8". Git repository is not public! Code must compile; 'gradle test jacocoTestReport' must pass, and so must the new targets ('setfocus', 'move', etc.); required artefacts (screencast and report following the template) are present.|
|Systematic Testing||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. A correct set of test cases has been generated using proper application of Myers heuristics and are documented in a proper extended test case table. The boundary value analysis is present and correct.|
|Framework Analysis and Usage||The framework analysis of HotCiv is correct, uses the proper terminology (hotspots, frozen spots, inversion of control, etc.), and discusses Template Method (separation and unification variant discussed). MiniDraw's hotspots are used correctly to produce the GUI for HotCiv.|
|MiniDraw Domain to GUI Integration||
The Observer pattern's subject role in the HotCiv framework
code is implemented and correctly validated by JUnit test
|MiniDraw GUI to Domain Integration||Each and all of the integration tests ('gradle action', 'gradle move', 'gradle setfocus', etc.) correctly tests the required functional aspect; and uses appropriate and simple test stubs for Game. There is no Big Bang testing (see note).|
|MiniDraw System Test||The system test ('semi' target) correctly executes a SemiCiv game with full MiniDraw GUI integration.|
Big bang testing is the name of the highly problematic testing technique in which all units from many sources are assembled in one marathon system test session - in the hope that it works. Experiences are that it seldom does, and as the system is now very big and complex, it is next to impossible debug where the defect(s) are. In HotCiv, it translates into developing all the individual tools and their combination, using your full HotCiv implementation without stubs.