Coursework II: The Magic Bakery

version 1.41

Typos/errors? Email [email protected] and I'll get them fixed.

Table of Contents

Coursework II: The Magic Bakery

Table of Contents
1. Instructions
2. Submission and Feedback

2.1 Submitting to Gradescope

3. Specification
4. Getting Started
5. Marking

5.1 Automated Testing

5.2 Assessment of the GUI
5.3 Marking Disputes / Queries

6. Academic Malpractice

1. Instructions

In this coursework we'll be asking you to implement a card game, Kim-Joy's Magic Bakery.
Your solution must meet the provided specification, so you should take time to carefully read
all instructions and UML class diagrams.

2. Submission and Feedback

The submission deadline is April 24th (Wednesday of week 10) at 12 pm (noon). You must
use Gitlab to submit this coursework and should follow department guidelines on how to do
this.

You will be provided with a repository named comp16412-bakery_<username> (where

 <username> is replaced with your own username, e.g.
comp16412-bakery___mbasssc4 -- you must use the provided repository for
submission. The final submission must be on the main branch and you will upload
your work from there to GradeScope.

This is a summative assessment exercise. This means that:

The work will be marked

The resulting mark forms a part of the overall course unit mark

In addition to the overall grade, you will receive ongoing (formative) and final (summative)
feedback in the form of JUnit test outcomes and associated error text. Summative feedback
on the user interface will also be provided where applicable (see 5. Marking).

You can get further (formative) feedback/guidance prior to submission by asking questions in
the labs or online forums.

2.1 Submitting to Gradescope

The link to Gradescope is in the Blackboard menu.

Gradescope will run the same JUnit tests provided in your repository and give you your result
and feedback. The feedback is the output that you see when you run the tests on your own
computer, but this time, the output for each test will appear in its own box on the webpage.

You can submit your code to Gradescope whenever you want before the deadline, and you
can do so multiple times.

We recommend that you upload your work directly from Gitlab using the Gitlab button on the
upload dialogue box in Gradescope.

If you have any difficulties connecting to GitLab, you can zip up your work and upload the zip
file to Gradescope. If you do this, make sure not to zip up the
comp16412-coursework-2_<username> directory, but to instead zip its contents.

3. Specification

This coursework implements all the basic rules of the card game Kim-Joy's Magic Bakery
(but not the scenarios). We've provided those rules, the UML diagram, and a more detailed
specification in a separate document.

You can choose whether to implement a purely console-based game, or a game with a
JavaFX GUI. The appearance of either the console game or GUI is completely up to
you. For reference, here's a screenshot of the game I built:
Note that we provide helper methods to get the above layout in the StringUtils
class -- we suggest that you use these rather than spend valuable time inventing new ways
to print cards out next to each other. We've also given you the ASCII art that I used in my
sample solution in io/art.txt .

4. Getting Started

Knowing where to start a game like this can be tricky. We've provided a separate guide
with some more detailed advice on where to start, but here are some highlights:

In order to get the tests to pass, you're going to need to (a) figure out how to run the
tests, and (b) get to grips with packaging. We suggest doing these two tasks early so
that you're getting continuous feedback from the tests.
We've provided a driver program. It's essentially empty, but make sure that you can
compile and run it OK.
Consider writing outline class and (empty) method signatures. This will allow the
 functional tests to compile.
Begin with the things you already know. There's plenty that you can be getting on with
(superclass/subclass relationships, command-line IO, file IO, error handling) before you
need to tackle newer topics (data structures, JavaFX).
Get some basic structures in place first. You can have a "working" game that doesn't
follow any of the rules but allows implementation of many of the classes (e.g. a game
that cycles through rounds/turns).

Still struggling? You can get help prior to submission by asking questions in the labs or
online forums.

5. Marking

This coursework is marked out of 100 and is principally marked through automated tests (80
marks) that check if the classes listed in the UML diagram perform according to the
specification.

The remaining 20 marks assess an optional graphical user interface (GUI).

5.1 Automated Testing

There are 817 automated tests. The automated tests will check that your implementation
meets the specification in three different ways:

Structural tests compare the signatures of your Classes, variables, methods etc. to
ensure that they match those of the UML.

For example, these tests will check whether there is a class called MagicBakery in
the bakery package and if that class has a three-parameter constructor with
public visibility.

There are 422 Structural tests for a total of 10 marks (i.e. approximately 42 passing
Structural tests = 1 mark).
 File Number of Tests

StructuralMagicBakeryTest.java 94

StructuralCustomerOrderTest.java 56

StructuralCustomersTest.java 56

StructuralConsoleUtilsTest.java 37

StructuralPlayerTest.java 30

StructuralActionTypeTest.java 29

StructuralCustomerOrderStatusTest.java 29

StructuralIngredientTest.java 27

StructuralCardUtilsTest.java 27

StructuralLayerTest.java 22

StructuralEmptyPantryExceptionTest.java 5

StructuralTooManyActionsExceptionTest.java 5

StructuralWrongIngredientsExceptionTest.java 5

Functional tests compare the behaviour of your Classes, methods etc. to ensure that
they behave as described in the rules and specification.

There are 285 Functional tests for a total of 55 marks (i.e. approximately 5 passing
Functional tests = 1 mark).
 File Number of Tests

MagicBakeryTest.java 65

CustomersTest.java 65

ExceptionTest.java 41

CustomerOrderTest.java 38

CardUtilsTest.java 28

PlayerTest.java 22

LayerTest.java 15

IngredientTest.java 11

Javadoc tests assess whether or not your code is appropriately documented with
Javadoc. You should document all public/protected classes and methods.

There are 110 Javadoc tests for a total of 15 marks (i.e. approximately 7 passing
Javadoc tests = 1 mark).

File Number of Tests

JavadocMagicBakeryTest.java 26

JavadocCustomerOrderTest.java 16

JavadocCustomersTest.java 15

JavadocConsoleUtilsTest.java 13

JavadocPlayerTest.java 10

JavadocIngredientTest.java 9

JavadocLayerTest.java 7

JavadocCardUtilsTest.java 5

JavadocEmptyPantryExceptionTest.java 3

JavadocTooManyActionsExceptionTest.java 3

JavadocWrongIngredientsExceptionTest.java 3

5.2 Assessment of the GUI

Providing a user interface (GUI) is optional, and will only be marked if all automated tests
have passed. If you do provide a GUI, it must be written using JavaFX.

There are no UML specifications for the GUI, nor do we mandate use of any particular
JavaFX components/layout.

You have the freedom to design the JavaFX graphical application in whatever way seems
most appropriate. To interact with the game state, you should try to use public classes and
methods defined in the UML -- in theory, your user interface could then be plugged into any
other successful implementation of the UML specification.

Take into consideration the reading week assignments on accessibility.

In addition to the code, you should submit a screencast recording (about 3 minutes) to
demonstrate your user interface. You may not edit the video (no captions, transitions nor
animations), except cuts if needed to show different phases of the game. You do not need to
provide a voice-over. There are no marks assigned to the visual or audio aspects of the
screencast, the purpose is simply to show off your GUI.

A simple way to record a screencast is using Teams and select the window of your GUI.

Marks will be allocated for:

Display of game state (players, customers, ingredients, layers etc.) [6 marks]

Interactivity [4 marks]
Accessibility [3 marks]
Use of public classes and methods [3 marks]
Implementation of the rules [4 marks]

5.3 Marking Disputes / Queries

We appreciate that some students may have questions about their marks.

Any questions about the 80 automated test marks (and associated feedback) must be
made within one week of your submission deadline.
Any questions about the 20 GUI marks (and associated feedback) must be made within
one week of the mark being released.

Queries received after this time can not be accommodated.

6. Academic Malpractice

This is an individual coursework exercise. You should not allow others to copy aspects of
your solution, nor should you source aspects of your solution from other sources (be they
people or resources).
All submissions will be checked using academic malpractice detection software. We
manually evaluate the results of this software to identify a set of submissions that we believe
to be problematic. These problematic submissions are dealt with in accordance with
University policy.