Assignment Specification

This page contains the tasks you’ll need to complete for this assignment, and how you’ll

be assessed.

_TOC_

1. Getting Started

   You can access your pair repository via the following URL:

   https://nw-syd-gitlab.cseunsw.tech/COMP2511/24T1/teams/YOUR_TEAM_NAME/assignment-ii

   YOUR_TEAM_NAME

   M18A_JIGGLYPUFF

   Replace with your team name (e.g. )

   For this assignment, you will need to make two sets of blog posts and add these to your repo:

   • Your pair blog post, which contains the answers to these questions and links to your code changes.

   • Your individual blog post, which serves as a record of your individual contribution.

   You can view instructions and templates for this blogging here.

2. Tasks

   Important Breadcrumbs…

   This Assignment has three tasks. However, we recommend you read the whole spec before starting Task 1. Parts of different tasks may affect how you complete the assignment.

   Follow the trail of breadcrumbs that leads to Task 3…

   Task 1) Code Analysis and Refactoring (40 marks)

   In this task, you will need to analyse the design of the monolith, including the patterns and smells present in the implementation, and apply refactoring techniques discussed in the course in order to improve the quality of the code.

   Instructions for Task 1:

   Put all of your answers to the following theory questions in your pair blog post.

   For each refactoring change, before you start coding take some time to plan and write up a design in your pair blog post. This should include:

   • What fields/methods you will need to add/change in a class

   • What new classes/packages you will need to create

     master

     After you finish coding, make a Merge Request into the repository with the following:

     branch of your

   • A meaningful MR title that encompasses the changes

   • A brief description which outlines the changes being made

   • Make sure to keep the MR as small as possible – don’t make any extra changes that aren’t absolutely necessary. Try to keep the number of files the changes touch to a minimum.

   • Make sure all the Continuous Integration checks (regression tests, linting, coverage) remain passing.

     Your partner will need to code review and either:

   • Leave comments in the MR with things to fix (you can do code reviews sync or async), requiring you to iterate on the MR and resubmit for review; or

   • Approve the MR.

Once the MR is approved, copy and paste the link to your MR into your blog post. Make sure to do this for each part of the question – if you don’t you will lose marks.

1. From DRY to Design Patterns (7 marks)

   1. Look inside src/main/java/dungeonmania/entities/enemies. Where can you notice an instance of repeated code? Note down the particular offending lines/methods/fields.

   2. What Design Pattern could be used to improve the quality of the code and avoid repetition? Justify your choice by relating the scenario to the key characteristics of your chosen Design Pattern.

   3. Using your chosen Design Pattern, refactor the code to remove the repetition.

2. Observer Pattern (5 marks)

   Identify one place where the Observer Pattern is present in the codebase, and outline how the implementation relates to the key characteristics of the Observer Pattern.

3. Inheritance Design (6 marks)

   @Override

   public void onOverlap(GameMap map, Entity entity) { return;

   }

   @Override

   public void onMovedAway(GameMap map, Entity entity) { return;

   }

   @Override

   public void onDestroy(GameMap gameMap) { return;

   }

   Currently, there is a significant flaw in the inheritance structure of entities. Consider the following three methods in the Exit entity class.

   1. Name the code smell present in the above code. Identify all subclasses of Entity which have similar code smells that point towards the same root cause.

   2. Redesign the inheritance structure to solve the problem, in doing so remove the smells.

4. More Code Smells (6 marks)

   The previous engineering team has left you with the following note:

   Collectable entities are a big problem. We tried to change the way picking up items is handled, to be done at the player level instead of within the entity itself but found that we had to start making changes in heaps of different places for it to work, so we abandoned

   it.

   1. What code smell is present in the above description?

   2. Refactor the code to resolve the smell and the underlying problem causing it.

5. Open-Closed Goals (6 marks)

   Look inside the goals package at the code provided.

   1. Do you think the design is of good quality here? Do you think it complies with the open- closed principle? Do you think the design should be changed?

   2. If you think the design is sufficient as it is, justify your decision. If you think the answer is no, pick a suitable Design Pattern that would improve the quality of the code and refactor the code accordingly.

6. Open Refactoring (10 marks)

Make any other refactoring improvements you see fit to the codebase. This can include resolving Design Smells, using Design Patterns discussed or any other general improvements to the health and quality of the code.

Some areas and questions you can consider:

• Look for violations of the Law of Demeter/Liskov Substitution Principle;

• The effects of potions (invisibility and invincibility) has been implemented using a State Pattern. However, the State Pattern hasn’t been used particularly effectively here and as a result, there is poor design.

• The current implementation of buildable entities contains a significant amount of

  hard coding. Think about how you can improve this.

  The above list isn’t exhaustive; there are plenty of other areas to improve the quality of the code.

  Don’t make solutions to problems that don’t exist yet! Avoid over-engineering or over- abstracting in places where you might want to improve the design for some future change in requirements – instead improve the design of the current system. This will inherently make your software open-closed.

  You’ll also want to split this task into one MR for each refactoring change you make.

  Task 2) Evolution of Requirements (50 marks)

  In this task, you and your partner/group will need to complete Part A – Microevolution and the same number of the following tasks as there are members in your group:

• b) Bosses (10 marks)

• c) Swamp Tile (10 marks)

• d) Sunstone & More Buildables (15 marks)

• e) Snakes (15 marks)

• f) Logic Switches (20 marks)

E.g. If there are two of you, you need to pick two of the above tasks, if there are three of you, you pick three. Each task has a different mark allocation based on its difficulty. You should pick tasks you feel comfortable completing. If you complete extra tasks, that is fine – we will take your performance in the best N tasks, where N is the number of people in your team.

If you are in a group of 3, your mark will be out of 65 and scaled to 50.

task2

Write all your tests for this question inside the folder.

Software Delivery – Task Lifecycle

For each part of this task, you will need to undertake the following process. This will help your tutor assess your design during marking.

1. Requirements Engineering. Analyse the task requirements, including the

   technical and product specifications. If you need to, make some assumptions and document these in your pair blog post.

2. Detailed Design. In your pair blog post, plan out a detailed design for the task. This should include:

   • What fields/methods you will need to add/change in a class

   • What new classes/packages you will need to create

3. Design Review. Have your partner review the design, and go back and iterate on the design if needed.

4. Create a Test List. Once the design is approved, write a test list (a list of all the tests you will write) for the task. Map out each of the conceptual cases you want to test. This can be written in your blog post, or if you want make function stubs for JUnit tests and put up a Merge Request (link in your blog).

5. Test List Review. Have someone else in your team review the test list to make sure the test cases all make sense and cover the input space.

6. Create the Skeleton. Stub out anything you need to with class/method prototypes.

7. Write the tests, which should be failing assertions currently since the functionality hasn’t been implemented.

8. Development. Implement the functionality so that your tests pass.

9. Run a usability test (check your functionality works on the frontend).

10. Where needed, refactor your code to improve the style and design while keeping the tests passing.

11. Put up a merge request with your changes into master. The CI should be passing. The merge request should have a meaningful title and contain a description of the changes you have made. In most cases you should just be able to link them to your design/test list blog.

12. Code Review from your partner, iterate where needed then they should approve the MR.

Feel free to split tasks further where you see fit, especially for larger tasks (e.g. Logic Switches). Keep your Merge Requests small and make the iteration cycle short, incrementally building your MVP as you go.

If you’ve done Task 1 well and have a nice healthy codebase, this task should be

relatively straightforward! If you’re finding parts of this task difficult to integrate with the existing design, that’s probably a sign you need to do some more refactoring

A note about backwards compatibility:

• All the regression tests we have provided to you in the starter code should remain passing.

• All of the MVP configuration files (in the provided config files) do not currently contain the fields listed in the technical specifications for Tasks 2a)-f). Rather than retroactively adding these fields to the existing configuration files, you will need to design your implementation to accomodate for this and maintain backwards compatibility. All configuration files in our Task 2 autotests

will contain all values from Task 2 and the MVP.

1. Microevolution – Enemy Goal (15 marks)

   In this section you will need to make a small-scale addition to the codebase to introduce a new type of goal – the enemy goal.

   To achieve the enemy goal, the player must fulfil both of the following requirements:

   Spider

   1. Defeat at least a certain number of enemies (i.e. ZombieToast ,

   2. Destroy all spawners (i.e. ZombieToastSpawner )

      , etc)

      Other existing goal rules, including rules of conjunction/disjunction and exits must be completed last, still apply. For example, if the end goal of the dungeon is set to be a conjunction of the enemy goal and the exit goal, the game will only be considered complete if the player first achieve the enemy goal before entering the exit.

      Note: for a given game of Dungeon Mania, the number of enemies that must be defeated is determined by the configuration field listed in the Technical Specification section below.

      Technical Specification

      enemies

      is now included in the list of goals specified in 4.1.4. of the MVP specification.

      The list of configuration fields in Section 4.2.1. of the MVP specification now includes the following fields:

      JSON Format	Description
      enemy_goal	At least x enemies must be killed to complete the enemy goal.

2. Bosses (10 marks)

In this task, you need to implement the following new entities.

Bosses are moving entities which are harder to defeat/conquer than normal enemies.

Technical Specification

The list of inputs in Section 4.1.1. of the MVP specification now includes the following entities:

The list of configuration fields in Section 4.2.1. of the MVP specification now includes the following fields: