CSSE2002/7023 — Semester 1, 2022 Assignment 2

Abstract

The goal of this assignment is to implement and test a set of classes and interfaces1, extending on the classes implemented in the first assignment.

Language requirements: Java version 11, JUnit 4.12.

Preamble

All work on this assignment is to be your own individual work.  As detailed in Lecture 1, code supplied by course staff (from this semester) is acceptable, but there are no other exceptions. You are expected to be familiar with  “What not to do” from Lecture 1 and https://www.itee.uq. edu.au/itee-student-misconduct-including-plagiarism.  If you have questions about what is acceptable, please ask course staff.

Please carefully read the Appendix A document. It outlines critical mistakes which you must avoid in order to avoid losing marks.  This is being heavily emphasised here because these are critical mistakes which must be avoided. If at any point you are even slightly unsure, please check as soon as possible with course staff!

All times are given in Australian Eastern Standard  Time.  It is your responsibility to ensure that you adhere to this timezone for all assignment related matters. Please bear this in mind, especially if you are enrolled in the External offering and may be located in a different time zone.

Introduction

In this assignment, you will continue developing a simple simulation of an interactive scenario system, building on the core model of the system you implemented in assignment one.

In assignment two, entities will now be able to move around the scenario if they implement the Movable interface.  Entities (such as Fauna) will move around the scenario according the a set algorithm given to you in a new class AnimalController .

The Coordinate class has had some additional helper methods added to facilitate the movement of entities.

The user or player in the simulation also must be implemented.  A user is special in that it can collect other entities. The Colletable interface allows classes to specify behaviour that occurs on collection by the User.

The keep track of these interactions a new Event subclass has been added (the CollectEvent). This class maintains a record of what a user has collected over time.

The Logger class provides a way to monitor various events in the scenario’s simulation. The Logger is similar to a database of all Event’s that occur within the simulation. On this ”database” certain calculations can be done to provide statistics such as how many entities have been collected or how many tiles have entities moved.

To facilitate saving and loading the state of the simulation to and from a file, the Encodable in- terface has been introduced. Any class implementing this interface must implement the encode() method, which encodes the current state of the class to a machine-readable string.  To faciliate the loading of a scenario from a file the Scenario class has a load() method implementation to construct a scenario.

Many classes now override the default equals() and hashCode() method implementations inher- ited from Object, allowing instances to be checked for equality according to their internal state.

A Graphical User Interface (GUI) using JavaFX has been provided in the researchsim.display package. Note that the GUI will not work correctly until the other parts of the assignment it relies on have been implemented.  The GUI consists of three classes:  View is responsible for creating the visual elements displayed on screen, ScenarioCanvas handles the graphics and drawing of the scenario in the main canvas, while ViewModel manages interaction between the View and the core classes of the model (e.g.  Scenario).  The Launcher class in the researchsim package initialises the GUI and passes the save file to the ViewModel.

While most of the GUI code has been provided to you, several methods must be implemented to complete the GUI. These are the methods marked with “Implement this for assignment 2” in ViewModel – you do not (and should not) need to modify any code in View or ScenarioCanvas.

Some  examples  have been provided  of the  save files  used  by the  GUI to  load the  saved  sce- nario simulation.   The files  saves/default.txt represents the simplest possible save file  and saves/test3.txt represents a full scenario with all possible entities.

Supplied Material

❼ This task sheet.

❼ Code specification document (Javadoc).2

❼ Gradescope, a website where you will submit your assignment.3

❼ A starting template for your assignment code, available for download on Blackboard.  The

files in this template provide a minimal framework for you to work from, and build upon. These files have been provided so that you can avoid (some of) the critical mistakes described in Appendix A. Each of these files:

– is in the correct directory (do not change this!)

– has the correct package declaration at the top of the file (do not change this!)

– has the correct public class or public interface declaration. Note that you may still need to make classes abstract, extend classes, implement interfaces etc., as detailed in the Javadoc specification.

As the first step in the assignment (after reading through the specifications) you should download the template code from Blackboard. Once you have created a new project from the files you have downloaded, you should start implementing the specification.

Javadoc

Code specifications are an important tool for developing code in collaboration with other peo- ple.  Although assignments in this course are individual, they still aim to prepare you for writing code to a strict specification by providing a specification document (in Java, this is called Javadoc).

You will need to implement the specification precisely as it is described in the specification docu- ment.

The Javadoc can be viewed in either of the two following ways:

1.  Open https://csse2002.uqcloud.net/assignment/2/in your web browser. Note that this will only be the most recent version of the Javadoc.

2.  Navigate to the relevant assignment folder under Assessment on Blackboard and you will be able to download the Javadoc .zip file containing HTML documentation. Unzip the bundle somewhere, and open doc/index.html with your web browser.

Tasks

1.  Fully implement each of the classes and interfaces described in the Javadoc.

2. Write JUnit 4 tests for all the methods in the following classes:

❼ Coordinate

(in a class called CoordinateTest)

Partially implemented in Assignment 1

❼ User (in a class called UserTest)

To facilitate in the creation of Scenario’s in your tests a few utility methods (createSafeTestScenario()) have been implemented for your use.

Marking

The 100 marks available for the assignment will be divided as follows:

The overall assignment mark will be A2   = FT + CF + SL + CR + JU with the following adjustments:

1. If FT is 0, then the manual code style review will not be marked. CR will be automatically 0.

2. If SL is 0, then the manual code style review will not be marked. CR will be automatically 0.

3. If SL + CR > FT , then SL + CR will be capped at a maximum of FT.

❼ For example: FT = 22, CF = 5, SL = 7, CR = 18, J = 13

⇒ A2  = 22 + 5 + (7 + 18) + 13.

⇒ A2  = 22 + 5 + (25) + 13. Limitation will now be applied.

⇒ A2  = 22 + 5 + (22) + 13.

The reasoning here is to place emphasis on good quality functional code.

Well styled code that does not implement the required functionality is of no value in a project, consequently marks will not be given to well styled code that is not functional.

Functionality Marking

The number of functionality marks given will be

Unit Tests passed

FT = Total number of Unit Tests · 45

Conformance

Conformance is marked starting with a mark of 5.

Every single occurrence of a conformance violation in your solution then results in a 1 mark de- duction, down to a minimum of 0.  Note that multiple conformance violations of the same type will each result in a 1 mark deduction.

Conformance violations include (but are not limited to):

❼ Placing files in incorrect directories.

❼ Incorrect package declarations at the top of files.

❼ Using modifiers on classes, methods and member variables that are different to those specified

in the  Javadoc.   Modifiers  include private,  protected,  public,  abstract,  final,  and static. For example, declaring a method as public when it should be private.

❼ Adding extra public methods, constructors, member variables or classes that are not de-

scribed in the Javadoc.

❼ Incorrect parameters and exceptions declared as thrown for constructors.

❼ Incorrect parameters, return type and exceptions declared as thrown for methods. ❼ Incorrect types of public fields.

Code Style

Code Structure and Layout

The Code Structure and Layout category is marked starting with a mark of 10.

Every single occurrence of a style violation in your solution, as detected by Checkstyle using the course-provided configuration4, results in a 0.5 mark deduction, down to a minimum of 0.  Note that multiple style violations of the same type will each result in a 0.5 mark deduction.

Note:  There is a plugin available for IntelliJ which will highlight style violations in your code. Instructions for installing this plugin are available in the Java Programming Style Guide on Black- board (Learning Resources _ Guides). If you correctly use the plugin and follow the style require- ments, it should be relatively straightforward to get high marks for this section.

Code Review

Your assignment will be style marked with respect to the course style guide, located under Learn- ing Resources _ Guides. The marks are broadly divided as follows:

Note that style marking does involve some aesthetic judgement  (and the marker’s aesthetic judge- ment is final).

Note that the plugin available for IntelliJ mentioned in the Code Structure and Layout section cannot tell you whether your code violates style guidelines for this section. You will need to man- ually check your code against the style guide.

The Code Review is marked starting with a mark of 20.  Penalities are then applied where appli- cable, to a minimum of 0.