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 focus in this iteration is twofold: A) refactoring your HotCiv code base to an Strategy pattern based architecture, by using your existing test cases to refactor the code base to a new design; and B) introduce new variants of the HotCiv game by implementing new Strategy implementations.
Solve and document FRS exercises:
Instead of a report and compositional design sketches for each exercise, you must hand in:
Important Note: Regarding the GammaCiv solution, read exercise 36.11 (you are not required to solve it), and use a STRATEGY pattern based approach for the GammaCiv design! A sub classing approach is not wrong, it is just that we want to train skills in applying a compositional design in this course.
DeltaCiv clarification: The book's wording in §36.3.3
is a bit misleading, and it should have been (strike out text
Furthermore, it should be easy for programmers to write
their own algorithms for generating a world layout
be used in DeltaCiv without any source code changes
in the HotCiv production code. That is, it should be
possible to generate any type of map, just by providing a new
Secondly , DeltaCiv requires a world layout of tiles that is pretty tedious to code and test. To lower the algorithmic part of the exercise, feel free to src-code-copy parts of the StubGame1.java stub code to your solution to the architectural part of the exercise. I used StubGame1.java to generate the pictures used in the book, and it is definitely not a compositional design. Comprehensive testing is not required, instead make a few test cases that makes spot checks (like testing that tile (5,6), (12,1), and a few others are correctly set).
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 3 Grade sheet to evaluate your submission. The score counts towards your final grade.
|Learning Goal||Assessment parameters|
|Submission||Git repository can be pulled using "Release3". Git repository is not public! Code must compile; 'gradle test jacocoTestReport' must pass; required artifacts (document with contents as outlined in the sections) must all be present.|
|Refactoring Process||The code base is refactored before introducing test cases/production code for the given variant. All code changes are indeed refactoring changes (exact same behavior before and after code changes). Test cases are run frequently to ensure small steps and no defects are introduced.|
|Composition||The Strategy pattern and 3-1-2 process have been correctly applied in the code base to support the variants. There is no source-code-copy, parametric, or polymorphic based variant handling code. The 3-1-2 and Strategy pattern terminology is used correctly in the screencast to explain the design and process.|
|Unit and Integration Testing||The delegates/concrete strategies are unit tested/tested in isolation (if possible). Integration tests exist that test each of AlphaCiv, BetaCiv, GammaCiv, and DeltaCiv as a whole. Test classes are named appropriately. See footnote below.|
|UML||The UML diagram is syntactically correct, correctly reflects Strategy, and is a correct overview of the architecture (including aggregation arrows from interfaces to delegates, which is proper for this course). The UML diagram does not show irrelevant implementation oriented details. The interfaces include the method(s) that encapsulate the central algoritm.|
|TDD and Code||TDD process has been applied. Test code and Production code keeps obeying the criteria set forth in the previous iterations. The requirements of BetaCiv, GammaCiv, and DeltaCiv are correctly implemented (minor deviations allowed). Missing features are noted in the backlog.|
Unit and Integration Testing clarification: Some concrete strategies can be tested in isolation, that is, unit tested without the GameImpl instance; just as I test the 'ProgressiveRateStrategy' in isolation without using the PayStationImpl in the FRS code, in Chapter 8. One concrete example is BetaCiv's strategy to compute the world's age---if you parameterize the algorithm with, say, the number of turns or rounds taken since the start of the game, it needs no further information from Game, and can thus be unit tested directly. As a counter example, it is difficult to test BetaCiv's concrete winner strategy without it being coupled with the Game instance. Regarding naming of test classes, do not put tests of BetaCiv into a test class named "TestAlphaCiv" etc. Separate test suites into test classes with descriptive names, like done in FRS chapter 8.1.5 and onwards.