Iteration 3: Strategy Pattern and Refactoring

Deadline

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.

Learning Goals

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.

Exercise

Solve and document FRS exercises:

And release them using the tag/branch name "Release3".

Deliveries:

Instead of a report and compositional design sketches for each exercise, you must hand in:

  1. Create one 5-8 minute screencast that demonstrates the refactoring process in which you introduce the compositional design that will allow introducing the Beta-, Gamma-, or DeltaCiv behavior. (I.e. the resulting code should still only support AlphaCiv behavior but have the proper architecture in place for introducing the selected X-Civ requirement(s).)
  2. Create one 5-8 minute screencast that details the architecture and implementation of one of the required variants, specifically, you should screencast/show the code and explain it. Be sure to show and explain a) the interface(s) introduced, b) the variability point(s), c) the place(s) where variable behavior is selected ("this code chooses whether it becomes an AlphaCiv or GammaCiv game"), and d) the implementing delegates. Remember to argue why your code is a compositional design, and relate to the 3-1-2 process.
  3. An UML class diagram outlining the final compositional design including all variants. Only include aspects relevant for the compositional design/Strategy patterns, and avoid others such as Position, storage data structures, etc. Please, in your interfaces, include the method(s) that encapsulate the central algorithm! (Provide it as a diagram in PDF, or picture of a easily readable hand-drawn diagram).

Notes and Hints

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 removed): Furthermore, it should be easy for programmers to write their own algorithms for generating a world layout to 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 Strategy implementation.

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).

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 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.