CSSE2002代写、代写Java程序语言

日期：2023-05-26 11:16

School of ITEE

CSSE2002/7023 — Semester 1, 2023

Assignment 2

Due: 19th May 2023 16:00AEST

Revision: 1.4

Abstract

The goal of this assignment is to implement and test a set of classes and interfaces1

. These classes

will be distinct from the classes implemented in the first assignment but will cover similar topics.

Language requirements: Java version 17, JUnit 4.

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 should

circumvent 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 time-zone 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 be developing classes and methods to support an application that

simulates a Production Factory Belt System. The code for this assignment will be centred around

a detailed loading system, a unique hexagonal coordinate system, and a path iteration system, and

their accompanying supporting classes.

You are working in collaboration with a fictional second team who have developed some functionality, for which working code has been supplied. You will be expected to complete your code

to work with this provided code.

For assignment 2, you will develop the code based on the supplied JavaDoc and will focus on

splitting your development strategy, so that you are working on one part of a bigger project. Your

task will rest on ensuring that the code you write will function correctly when it is connected to the

already in development GUI system and factory components. Your focus will be on developing the

classes and methods to support a Production Belt Factory Simulator. The system will necessitate

the development of a robust and complicated file loading system. The loading-system will load and

parse specific text data, stored in a very specific format and provided in a .txt file form, as detailed

in the JavaDoc specifications. The factory production line manages a number of hexagonal nodes.

1From now on, classes and interfaces will be shortened to simply “classes”

1

Each node performs a specific purpose within the context of the production belt system. There

are numerous nodes, or hexagonal units, defined in a factory grid, that are defined as such:

• Producer - This node produces an Item on every second tick.

• Consumer - This node consumes an Item, if one arrives to it via the Belt system.

• Belt - A pathway node that allows items to flow in one direction, from Producer to Consumer.

• Splitter (for CSSE7023 students only) - A Node that allows two belts of the same production

line to Split2

.

There will also be Open and Wall hexagonal nodes too2

. Your completed code will model the

movement of items in a factory, as detailed in the Javadoc.

Story

Hello there, esteemed programmer! I have great news for you. Based on your previous work,

you’ve been offered a new project that’s right up your alley. You’re now tasked with completing a

Factory Production Line Simulator, and I have a feeling you’re going to crush it! After receiving

your code, the newly self appointed space captain, Jesko Thoch became quite giddy and excitable.

The captain also owns a space fairing production and consumer factory, equipped with advanced

item delivery belts. In a tizzy, captain Matter wrote a Dr Suess inspired preamble to inspire your

worthy talents to assist in another quest.

Oh, dear programmer,

do I have a story to tell?

A project has come your way

that’ll make your heart swell!

A Factory Production Line Simulator is what you’ll create,

and let me tell you, it’ll be simply great!

You’ll be given a JavaDoc script and some other code,

and off you’ll write like a well-oiled node.

Your mission, should you choose to accept,

is to produce items and move them on a conveyor belt.

Around a hexagonal grid they’ll go,

to the consumer, where belts can split, so you know.

With a tick-tock-tick, the items will bop along,

alternating with each other like a soulful song.

And don’t fret, my kind and dear friend,

for you won’t be alone on this journey’s end.

A team of experienced programmers will be by your side,

ready to guide and support you with glowing pride.

So let’s get to work, my dear programmer3

,

and let your imagination run wild like a woolly llama.

With your reputation and skills, you’ll excel in this task,

and who knows, it could be the start of a fantastic career that will last!

So let’s get started, and don’t forget to have fun,

for this Factory Production Line Simulator is going to be second to none!

2Detailed in the Javadoc section

3pronounced pro:gra:ma

2

You will need to create the class files, interfaces and exceptions (including method algorithms) to

support the GUI to produce a working simulation of a production factory. The system must load

the grid file, and parse the data correctly, as defined. The data parsed from the file is used to

create the model for the factory grid simulator, in the form of object classes that represent working

elements in the production line.

Supplied Material

• This task sheet.

• Code specification document (Javadoc).2

• Gradescope, a website where you will submit your assignment.4

• Provided classes: In this assignment some classes and a partial folder structure have been

supplied for you. You must be meticulous with your naming, to ensure that you spell and

character case check every class package, name and method. Any deviation could cost you

marks, as the automatic testing will fail. This represents the real life expectation when interfacing with ready made code-bases. Take extra care to avoid the critical mistakes described

in Appendix A. Ensure that each of your 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 inspect

the supplied folders, and create packages and empty classes, which are named precisely as they are

described.

Javadoc

Code specifications are an important tool for developing code in collaboration with other people. 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 document.

The Javadoc can be viewed by:

1. Navigate to the relevant assignment folder under Assessment on Blackboard and you will be

able to download the Javadoc .zip file containing HTML documentation for the version of the

course you are enrolled in. Unzip the bundle somewhere, and open doc/allclasses-index.

html with your web browser.

Tasks

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

(a) Three Exception classes in the exceptions package

(b) Item and Path in the logistics package

(c) GameGrid in the grid package

4Detailed in the Submission section

3

(d) GameLoader in the io package

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

• Path

(in a class called PathTest)

• GameGrid

(in a class called GameGridTest)

Note that these classes each have a pre-provided method. You are not required to test that

method in your JUnit tests.

Marking

Your grade for the assignment will be determined based on your achievement in a number of

categories, as shown in Tables 1 and 2.

Table 1: Marking schema components

Symbol Marked Description

F T Electronically Functionality according to the specification

CF Electronically Conformance to the specification

CS : SL Electronically Code style: Structure and layout

CS : CR By course staff Code style: Style Guide Compliance

JU Electronically Whether JUnit tests identify and distinguish between correct and

incorrect implementations

4

Table 2: Marking Schema

Level of

Achievement

FT CF CS:SL CS:CR JU Overall

Exceptional (7) At least 85% of tests

are successful across all

classes

Expert conformance (no more

than 2 violations)

Mastery of style (no

more than 4 violations)

Variable naming is masterful.

Comments are significantly numerous, meaningful, detailed

and useful. Code design follows

best practice. Programming follows best practices.

At least 85%

of faulty

solutions are

identified

FT 7; CF 6+;

CS 6+; JU 6+

Advanced (6) At least 75% of tests

are successful across all

classes

Extensive conformance (no more

than 3 violations)

Extensive compliance with style

(no more than 6

violations)

Variable naming is substantially

appropriate. Comments are extensively numerous, meaningful,

detailed and useful. Code design

is substantially approaching best

practice. Programming substantially approaches best practice.

At least 75%

of faulty

solutions are

identified

FT 6+; CF 5+;

CS 5+; JU 5+

Proficient (5) At least 65% of tests

are successful across all

classes

Good conformance

(no more than 4 violations)

Good compliance

with style (no more

than 8 violations)

Variable naming is good. Comments are generally meaningful,

detailed and useful. Code design

is good. Programming practices

are good.

At least 65%

of faulty

solutions are

identified

FT 5+; CF 4+;

CS 4+; JU 4+

Functional (4) At least 50% of tests

are successful across all

classes

Adequate conformance (no more

than 5 violations)

Adequate compliance with style

(no more than 10

violations)

Variable naming is adequate.

Comments are adequate. Code

design is adequate. Programming practices are adequate.

At least 50%

of faulty

solutions are

identified

FT 4+; JU 3+

or JU 4+; FT

3+

Developing (3) At least 30% of tests

are successful across all

classes

Superficial conformance (no more

than 6 violations)

Superficial compliance with style (no

more than 12 violations)

Variable naming is adequate.

Commenting is superficial. Code

design is adequate. Programming practices are adequate.

At least 30%

of faulty

solutions are

identified

(FT 3+ or JU

3+; FT 2+)

and CS:SL 2+

Minimal

achievement

(2)

At least 20% of tests

are successful across all

classes

Deficient conformance (no more

than 7 violations)

Deficient compliance with style

(no more than 14

violations)

Variable naming is deficient.

Commenting is deficient. Code

design is deficient. Programming

practices are deficient.

At least 20%

of faulty

solutions are

identified

(FT 2+ or JU

2+) and CS:SL

1+

Absence of

achievement

(1)

No demonstrated evidence of ability to apply concepts in the field of study.

5

Please note that Code Style grades are capped at the level of your Functionality grade. 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

Functionality evaluates if you have correctly implemented classes, properties, and methods according to the specification.

Conformance

Conformance is marked by identifying conformance violations in your code. Note that multiple

conformance violations of the same type will each be counted as separate violations.

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 described 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 by identifying violations of the style guide in

your code. Style violations in your solution will be detected and counted by CheckStyle using the

course-provided configuration5

. Note that multiple style violations of the same type will each be

counted as separate violations.

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 Blackboard (Learning Resources → Guides). If you correctly use the plugin and follow the style requirements, it should be relatively straightforward to get high marks for this section. IntelliJ will also

give you hints in the correct direction. Ensure you know the difference between a checkstyle and

IntelliJ hint.

Code Review

Your assignment will be style marked with respect to the course style guide, located under Learning

Resources → Guides. Common mistakes are listed in Table 3.

Note that style marking does involve some aesthetic judgement (and the marker’s aesthetic judgement 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 manually

check your code against the style guide.

5The latest version of the course CheckStyle configuration can be found at http://csse2002.uqcloud.net/

checkstyle.xml. See the Style Guide for instructions.

6

Table 3: Common errors in Style Guide Compliance

Metric How it is marked

Naming Misnamed variables

e.g.

→ Non-meaningful or one-letter names

• String temp; // bad naming

• char a; // bad naming

• int myVar, var, myVariable; // all bad naming

→ Variable names using Hungarian notation

• int roomInteger; // bad naming

• List<Gate> gateList; // bad naming (‘gates’ is better)

Commenting Javadoc comments lacking sufficient detail

e.g.

→ Insufficient detail or non-meaningful Javadoc comments on (any) classes

→ Insufficient detail or non-meaningful Javadoc comments on (any) methods

→ Insufficient detail or non-meaningful Javadoc comments on (any) constructors

→ Insufficient detail or non-meaningful Javadoc comments on (any) class variables

→ etc.

Lack of inline comments, or comments not meaningful

e.g.

→ There needs to be sufficient comments which explain your code so that

someone else can readily understand what is going. Someone should not need

to guess or make assumptions.

→ Lack of inline comments, or comments not meaningful in methods

→ Lack of inline comments, or comments not meaningful in constructors

→ Lack of inline comments, or comments not meaningful for variables

→ etc.

Code Design Code design issues

e.g.

→ Using class member variables where local variables could be used

→ Duplicating sections of code instead of extracting into a private helper

method

→ Having functions that exceed 100 lines in length

→ Class content is laid out in a way which is not straightforward to follow

→ Methods are laid out in Classes or Interfaces in a way which is not straightforward to follow

→ Method content is laid out in a way which is not straightforward to follow

→ Variables are not placed in logical locations

Programming

Practices

Programming Best Practices issues

e.g.

→ Using class member variables where local variables could be used

→ Incorrect use of inheritance by duplicating code

→ Incorrect exception handling

→ Using magic numbers without explanatory comments

• object.someMethod(50); // what does 50 mean? What is the

unit/metric?

7

JUnit Test Marking

See Appendix B for more details.

The JUnit tests that you provide in PathTest and GameGridTest will be used to test both correct

and incorrect implementations of the Path and GameGrid classes. Marks will be awarded for test

sets which distinguish between correct and incorrect implementations6

. A test class which passes

every implementation (or fails every implementation) will likely get a low mark. Marks will be

rewarded for tests which pass or fail correctly.

There will be some limitations on your tests:

1. If your tests take more than 20 seconds to run, or

2. If your tests consume more memory than is reasonable or are otherwise malicious,

then your tests will be stopped and a mark of zero given. These limits are very generous (e.g. your

tests should not take anywhere near 20 seconds to run).

Electronic Marking

The electronic aspects of the marking will be carried out in a Linux environment. The environment

will not be running Windows, and neither IntelliJ nor Eclipse (or any other IDE) will be involved.

OpenJDK 17will be used to compile and execute your code and tests.

It is critical that your code compiles.

If your submission does not compile, you will receive zero for Functionality (FT).

Submission

How/Where to Submit

Submission is via Gradescope.

Instructions for submitting to Gradescope will be made available on Blackboard. You will not be

able to submit your assignment before then.

You must ensure that you have submitted your code to Gradescope before the submission deadline.

Code that is submitted after the deadline will attract a late penalty (1 nanosecond late is still late).

You may submit your assignment to Gradescope as many times as you wish before the due date,

however only your last submission made before the due date will be marked.

What to Submit

Your submission should have the following internal structure:

src/ folders (packages) and .java files for classes described in the Javadoc

test/ folders (packages) and .java files for the JUnit test classes

A complete submission would look like:

6And get them the right way around

8

src/lms/io/GameLoader.java

src/lms/logistics/Path.java

src/lms/logistics/Item.java

src/lms/logistics/Transport.java

src/lms/logistics/belts/Belt.java

src/lms/logistics/belts/Splitter.java (for CSSE7023 students only)

src/lms/logistics/container/Container.java

src/lms/logistics/container/Reciever.java

src/lms/logistics/container/Producer.java

src/lms/grid/Coordinate.java

src/lms/grid/GameGrid.java

src/lms/grid/GridComponent.java

src/lms/grid/Orientation.java

src/lms/utility/Tickable.java

src/lms/exceptions/UnsupportedActionException.java

src/lms/exceptions/BadStateException.java

src/lms/exceptions/FileFormatException.java

src/lms/gui/Controller.java

src/lms/gui/GraphicsCanvas.java

src/lms/gui/MainApplication.java

src/lms/gui/ViewModel.java

test/lms/logistics/PathTest.java

test/lms/grid/GameGridTest.java

Ensure that your classes and interfaces correctly declare the package they are within. For example,

GameGrid.java should declare package lms.grid;.

Do not submit any other files (e.g. no .class files).

Note that PathTest and GameGridTest will be compiled individually against a sample solution

without the rest of your test files.

Provided set of unit tests

A small number of the unit tests (about 10-20%) used for assessing Functionality (FT) (not conformance, style, or JUnit tests) will be provided in Gradescope prior to the submission deadline,

which you will be able to test your submission against. In addition, a small number of the JUnit

faulty solutions used for assessing JUnit will be provided in Gradescope prior to the submission

deadline.

The purpose of this is to provide you with an opportunity to receive feedback on whether the basic

functionality of your classes and tests is correct or not. Passing all the provided unit tests does

not guarantee that you will pass all of the full set of unit tests used for functionality marking.

9

Late Submission

Assignments submitted after the submission deadline of 16:00 on 19th May 2023 (by any amount

of time), will attract a late penalty unless an extension is granted as outlined in the Electronic

Course Profile — see the Electronic Course Profile for details.

Do not wait until the last minute to submit the final version of your assignment. A submission

that starts before 16:00 but finishes after 16:00 will not be marked. Exceptions cannot be made

for individual students, as this would not be fair to all other students.

Assignment Extensions

All requests for extensions must be made via my.UQ as outlined in section 5.3 of the respective

Electronic Course Profile. Please not directly email the course coordinator seeking an extension

(you will be redirected to my.UQ).

Remark Requests

To submit a remark of this assignment please follow the information presented here:

https://my.uq.edu.au/information-and-services/manage-my-program/exams-and-assessment/

querying-result.

Revisions

If it becomes necessary to correct or clarify the task sheet or Javadoc, a new version will be issued

and an announcement will be made on the Blackboard course site.

Appendix A:

Critical Mistakes which can cause loss in marks.

THINGS YOU NEED TO AVOID

This is being heavily emphasised here because these are critical mistakes which must be avoided.

The way assignments are marked has been heavily revised this semester to address many of these

issues where possible, but there are still issues which can only be avoided by making sure the

specification is followed correctly.

Code may run fine locally on your own computer in IntelliJ, but it is required that it also builds

and runs correctly when it is marked with the electronic marking tool in Gradescope. Your solution

needs to conform to the specification for this to occur.

Correctly reading specification requirements is a key objective for the course. Ensure that you

read all components including headings and footers.

• Files must be in the correct directories (exactly) as specified by the Javadoc. If files are in

incorrect directories (even slightly wrong), you may lose marks for functionality in these files

because the implementation does not conform to the specification.

• Files must have the exact correct package declaration at the top of the file. If files have

incorrect package declarations (even slightly wrong), you may lose marks for functionality in

these files because the implementation does not conform to the specification.

10

• You must implement the public and protected members exactly as described in the supplied

documentation (no extra public/protected members or classes). Creating public or protected

data members in a class when it is not required will result in loss of marks, because the

implementation does not conform to the specification.

– Private members may be added at your own discretion.

• Never import the org.junit.jupiter.api package. This is from JUnit 5. This will automatically cause the marks for the JUnit section to be 0 because JUnit 5 functionality is not

supported.

• Do NOT use any version of Java newer than 17 when writing your solution! If you accidentally

use Java features which are only present in a version newer than 17, then your submission

may fail to compile when marked. This will automatically cause the marks for associated

files with this functionality to be 0.

Appendix B:

How your JUnit unit tests are marked.

The JUnit tests you write for a class (e.g. PathTest.java) are evaluated by checking whether

they can distinguish between a:

correct implementation of the respective class

e.g. Path.java, made by the teaching staff, and

incorrect implementations of the respective class

“deliberately made (sabotaged) by the teaching staff ”.

First, we run your unit tests (e.g. PathTest.java) against the correct implementation of the respective classes (e.g. Path.java).

We look at how many unit tests you have, and how many have passed. Let us imagine that you

have 7 unit tests in PathTest.java and 4 unit tests in GameGridTest.java, and they all pass (i.e.

none result in Assert.fail() in JUnit4).

We will then run your unit tests in both classes (PathTest.java, GameGridTest.java) against an

incorrect implementation of the respective class (e.g. Path.java). For example, the foo() method

in the Path.java file is incorrect.

We then look at how many of your unit tests pass.

GameGridTest.java should still pass 4 unit tests.

However, we would expect that PathTest.java would pass fewer than 7 unit tests.

If this is the case, we know that your unit tests can identify that there is a problem with this

specific implementation of Path.java.

This would get you one identified faulty implementation towards your JUnit mark.

The total marks you receive for JUnit are the correct number of identified faulty implementations,

out of the total number of faulty implementations which the teaching staff create.

For example, if your unit tests identified 60% of the faulty implementations, you would receive a

mark of 60% of 20 → 12.00012/20.

11

Start early, work hard and good luck.

12