Iteration 6: Compositional Design Principles

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

In this iteration, the learning goal is the compositional design principles, especially its ability to support multi-dimensional variance, and contrast it to corresponding parametric and polymorphic designs. A secondary goal is generalizing your HotCiv framework for new unit types.

Exercise

Solve and document exercises:

  1. FRS 36.22 (SemiCiv)
  2. FRS 36.23 (Parametric 'getWinner()')
  3. Polymorphic ZetaCiv: Consider a purely polymorphic design of the Alpha, Beta, ..., Zeta variants. That is, a design in which variants are created by subclassing the original AlphaCiv implementation, like shown below

    For instance, the BetaCiv world aging algorithm would be handled by overriding the getAge() method in class AlphaCiv, etc.
    1. Sketch a design proposal for how to implement ZetaCiv based upon a purely polymorphic design, by drawing a UML diagram of the interfaces and classes involved. You may consider a design in a language that supports multiple implementation inheritance, like C++.
    2. Sketch how the actual getWinner() method implementation in the ZetaCiv subclass would look like in (pseudo) code.
    (This exercise replaces 36.24 in FRS).
  4. ThetaCiv:

    Develop (much of) ThetaCiv using TDD and by generalizing/extending your HotCiv production code.

    ThetaCiv is identical to GammaCiv, except for the following additions:
    • A new unit type, B52 bomber airplane, is introduced identified by the type string "b52". A bomber costs 60, travels a distance 2 (also over oceans and mountains), defense strength 8, attack strength 1.
      Graphics:
    • Cities can, of course, produce B52s if the Game's method "changeProduc...." is called with the B52 type string.
    • A B52 can overfly an enemy city without conquering it, if there are no units on the city. If there is an enemy unit on the enemy city tile, it is considered a normal attack and conquest.
    • B52 action. When a B52 is told to perform its action, it bombs the city below it, which have its population decreased by 1; if it reaches 0, then the city is removed. If there is no city, then if the tile's terrain is of type 'Forests' the bombing causes the terrain type to change to 'Plains'. All other terrain types are not affected by bombing.

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

Deliveries:

  1. Instead of individual documentation for each exercise as stated in the FRS exercises, you should document your group's work by following the requirements defined in the iteration 6 report template (pdf) (LaTeX source)

Notes

The main learning goals of this iteration is SemiCiv and the compositional design principles. Thus, if you find yourself pressed for time, focus on SemiCiv and put some ThetaCiv features on the backlog.

ThetaCiv is a way to force you into considering what/what not to generalize in your HotCiv framework code using a new unit type. So for each new feature, consider if it is the framework ("StandardGame, StandardCity, ...") code that should handle it, or if it is the delegate code that should. For instance, the ability to reduce city population seems pretty 'B52' specific, whereas its characteristics as a flying unit and terrain type engineering seems something that other HotCiv variants may benefit from having provided by the framework.

Regarding 'travel distance 2', interpret this as "allowed to make two successful calls to 'moveUnit(f,t)' each moving the unit one tile". This is much easier than developing path finding algorithms.

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 6 Grade sheet to evaluate your submission. The score counts towards your final grade.

Learning Goal Assessment parameters
Submission Git repository can be pulled using "Release6". Git repository is not public! Code must compile; 'gradle test jacocoTestReport' must pass; required artefacts (report following the template) are present.
Composition The compositional design principles are correctly applied in the code base to support all variants and in particular support the multi-variance SemiCiv. There are no source-code-copy, parametric, or polymorphic based variant handling code. The 'variant to use' code is localized in the ConcreteFactory for each variant.
Variability Analysis The report clearly and concisely describes the SemiCiv configuration table and configuration code; and describes correct solutions to the parametric 'getWinner()' and polymorphic ZetaCiv through correct UML and (pseudo) code fragments.
ThetaCiv Behaviour The ThetaCiv implementation is behaviourally correct, and general behaviour, that makes sense for other variants, is provided by Game framework code.
TDD and Clean Code TDD process has been applied. Test code and Production code keeps obeying the criteria set forth in the previous iterations, including adhering to Clean Code properties for newly developed code (1). Missing features are noted in the backlog (ThetaCiv features allowed there).

Ad (1) Test code should also adhere to Clean Code properties with the exception of "Arguments in Argument Lists". It is common and correct that private helper methods in test code express "hardcoded arguments as part of the method name", like moveRedArcherToBlueCity(), because it is just a way to group this fixture code into a helper method. It does not make sense to make a general method moveUnitToCity(Unit u, City c) in the test code as this would involve complex algorithms (requirering TDD to develop) and time wasted for no gain.