comp16412 Coursework II: The Magic Bakery

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.

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

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 thefunctional 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).

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).

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

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).

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.

5.3 Marking Disputes / Queries

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

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.