Programming in the Large (CSSE2002)
Assignment 2 — Semester 1, 2024
Due May 13th 13:00 AEST
Overview This assignment provides practice working with an existing software project. You are provided with a small extension to the SheeP spreadsheet program. The extension has introduced errors and is quite poorly written. Fortunately, the extension is accompanied by a suite of JUnit tests.
You will be assessed on your ability to:
❼ identify and ix errors in provided code,
❼ extend the functionality of provided code, and
❼ and meaningfully refactor supplied code to improve its quality.
Task Your prior program, SheeP, was a massive success. However, some users felt it was boring. You decide to make the product more exciting by introducing new games into the spreadsheet program. The course staf have attempted to add one mini-game, but have made a mess of it. Your task is to ix their bugs and complete the implementation according to the speciication. You must also refactor the code to improve its quality.
Plagiarism As per assignment one.
Generative Artiicial Intelligence As per assignment one.
Interviews As per assignment one.
Software Design In contrast to assignment 1, you will not be given speciication at the method level. Rather, you are given a broad speciication of each component and how the component must be integrated with the spreadsheet program. The rest of the implementation design is up to you. You should use the software design principles (such as coupling, cohesion, information hiding, SOLID, etc.) that are taught in class to help your design.
The design of your software is part of the assessment. Please be mindful that:
1. Discussing the design of your software in detail with your peers may constitute collusion. Please discuss general design principles (cohesion, coupling, etc.) but avoid discussing your speciic approach to this assignment.
2. Course staf will provide minimal assistance with design questions to avoid inluencing your approach. You are encouraged to ask general software design questions.
Bug Fixing Many tests fail initially, this may be overwhelming. Find the smallest failing test — do not start with a complex test as there are multiple bugs that may intersect. Create theories about what may be wrong with the software, play testing the software may be helpful. You may ind it helpful to construct some smaller test scenarios. There are 5 bugs, each can be ixed by modifying a single line in Tetros.java. You will need to have a clear understanding about what the bug is before attempting to ix it. You may ind manually writing the test cases out (i.e. drawing the tetros board) helpful.
Components
This assignment has four components. Each component should be styled well such that it is read- able and understandable and should be well designed such that it is extensible and maintainable.
❼ The irst three components are implementation components, that is, you are given a specii- cation and asked to develop an appropriate component that satisies the speciication.
❼ The last component is a refactoring component, you are given a poorly designed implemen- tation and must refactor the implementation to improve the design whilst maintaining its functionality.
Component #1: File Load & Saving
You must create two new features, one feature for saving a spreadsheet to a ile and one for loading a spreadsheet from a ile. The ile format is not speciied. You must design a suitable ile format that is capable of storing the state of a spreadsheet.
1. The saving and loading features must be compatible, i.e. saving a sheet to a ile then loading that ile should restore the sheet to its original state (even after closing the spreadsheet application or moving the ile).
2. You must not utilize Java Serialization.
3. You must modify the current Sheet instance, instead of constructing a new instance (Hint: see Sheet.updateDimensions(int, int)).
4. You must irst clear the sheet (See Sheet.clear()), then each cell must be updated starting from the top and populating each row from left to right (row by row).
The features.files.FileLoading and features.files.FileSaving classes must both imple- ment the supplied Feature interface. Both classes must have a constructor that accepts a Sheet instance.
1. Within the FileLoading.register(UI) method, a feature to load a spreadsheet from a ile must be bound to the identiier "load-file".
See UI.addFeature.
2. Within the FileSaving.register(UI) method, a feature to save a spreadsheet to a ile must be bound to the identiier "save-file".
See UI.addFeature.
When either feature is activated, the user must be prompted for a ile path relative to the current directory (See Prompt.ask(String)). If any unexpected exception occurs when saving or loading a ile (e.g. ile not found, ile cannot be read, ile is the wrong format, etc.), the user must be informed (See Prompt.message(String)).
Component #2: Game of Life
Conway’s game of life is a popular cellular automaton. The simulation occurs on a grid of tiles. Each tile may be either on or of. At each step a simple set of rules are applied to each tile to determine the state (on or of) of the tile in the next step.
The rules are as follows where a neighbour is any tile one step away horizontally, vertically, or diagonally (giving each tile not on a boundary 8 possible neighbours):
1. Any on cell with fewer than two on neighbours turns of.
2. Any on cell with two or three on neighbours stays on.
3. Any on cell with more than three on neighbours turns of.
4. Any of cell with exactly three on neighbours turns on, otherwise it stays of.
For example:
In the above example, moving from the irst state to the second state:
❼ (3, 0) has one on neighbour, so turns of by (1).
❼ (2, 1) has two on neighbours, so stays on by (2).
❼ (1, 2) has two on neighbours, so stays on by (2).
❼ (1, 1) has three on neighbours, so turns on by (4).
❼ (0, 2) has one on neighbours, so turns of by (1).
Moving from the second state to the third state, (2, 2) has three on neighbours, so turns on by (4).
The games.life.Life class must implement the provided Feature interface. Life must have a constructor that accepts an instance of Sheet. Within the Life.register(UI) method:
1. A feature to start the game of life simulation must be bound to the identiier "gol-start". See UI.addFeature.
2. A feature to stop the simulation must be bound to the identiier "gol-end". See UI.addFeature.
3. An appropriate tick callback must be registered such that when the simulation is running,
the sheet is updated according to the above rules.
See UI.onTick.
Within the spreadsheet, a cell that renders as "1" (without quotes) is considered to be in the on state. All other cells are considered to be in the of state. When turning a cell of , the sheet should be updated to insert "" (without quotes) at the cell.
Component #3: Snake
Snake is another classic game played on a grid. The snake is a chain of tiles. When the game begins the chain is just one tile. At each step (tick) the head of the snake moves one tile in the direction it is currently heading. The tail will also move to catch up to the head.
Initially, the snake should be heading south, i.e. increase the row. The spreadsheet user may use the shortcuts, w, a, s, and d to alter the direction of the snake such that at the next tick, it will move in the new direction.
w Change direction to up/north (decrease row).
a Change direction to left/west (decrease column).
s Change direction to down/south (increase row).
d Change direction to right/east (increase column).
If the snake collides with a wall (goes beyond the bounds of the grid) or hits itself, the game is over.
Example 1: Wall Crash
Example 2: Eating
The games.snake.Snake class must implement the Feature interface. Snake must have a construc- tor that accepts a Sheet instance and a RandomCell instance. Within the Snake.register(UI) method:
1. An action to start a game of snake must be bound to the identiier "snake". The snake must start at the position passed into the perform method.
2. An appropriate tick callback must be registered to move the snake at each tick.
3. A key binding must be registered for each direction (w, a, s, and d).
When the game ends, this must be indicated to the player via the Prompt.message(String) method of the instance passed into the tick callback. The message must say exactly "Game Over!" (without quotes).
You may assume that:
1. Every cell that renders as empty, i.e. "" (without quotes) is a cell the snake can safely move to.
2. Every cell that renders as "1" (without quotes) is the snake itself.
3. All other non-empty cells are food that the snake may eat.
In the tick that food is consumed, you must call the RandomCell.pick() method and place a new food item with value "2" at the returned location.
Component #4: Tetros
The provided software comes with an implementation of Tetris, called Tetros. This implementa- tion is not a faithful implementation, i.e. it diverges from real tetris in major ways, you might call these bugs. However, this is intentional. The course staf have decided that they prefer this variation of the classic game.
You must preserve the existing functionality, i.e. do not make a correct implementation of Tetris. To ensure that your implementation preserves the original functionality, JUnit tests have been developed. Your implementation should always pass these tests. To make this easy on yourself, ensure that you run the tests after each modiication that may cause tests to fail.
Note that the provided tests are not a good demonstration of unit testing. As we want you to have a high degree of lexibility in how you implement your design, the tests are not granular and may be considered closer to integration tests.
Hint A good refactoring of the Tetros program should make it easy to provide a correct imple- mentation of Tetris via dependency inversion. It should also aim to make it easy to change the behaviour of mechanisms such as the rotation system, piece spawning system, piece variations, etc.
Tasks
1. Download the assignment .zip archive from Blackboard.
❼ Import the project into IntelliJ or your preferred IDE.
❼ Ensure that the project compiles and runs (including running JUnit tests).
2. Identify and ix the errors in the provided code.
❼ The code contains several bugs, causing the provided JUnit tests to fail.
❼ You must ix all errors in the code to implement the speciication and pass all the tests.
❼ You must not change the provided tests in any way.
3. Complete the implementation of the provided code.
❼ There are three components (ile saving/loading, game of life, and snake) that have not been implemented.
❼ Create appropriate packages and classes for these components as speciied above.
❼ You must implement these components according to the speciication above.
❼ You are encouraged to create any additional classes that aid your implementation.
❼ You are encouraged to write additional JUnit tests to test your new features.
4. Refactor the provided code.
❼ The provided tetros implementation is poorly implemented.
❼ You must refactor the provided code to improve its quality.
❼ You must not modify the behaviour of the original game while refactoring.
Marking
The assignment is marked out of 100. The marks are divided into four categories: bug ixes (B), extension functionality (F), code quality (Q), and style (S).
The overall assignment mark is deined as
A2 = (10 X B) + (40 X F) + (40 X Q) + (10 X S)
Bug Fixes The provided code includes JUnit tests that fail, indicating an incorrect implementa- tion. You will be awarded marks for modifying the implementation such that the provided JUnit tests pass.
Your mark is based on the number of bugs you ix. The number of bugs you ix is determined by the number of unit tests you pass. For example, assume that the project has 40 unit tests, when given to you, 10 pass. After you have ixed the bugs, 25 tests pass. Then you have ixed 15 out of 30 bugs. Your mark is then
In general, let p0 and f0 be the number of unit tests that pass and fail in the provided code respectively. If p is the number of unit tests that pass when you submit, then your mark is
Functionality Each class has a number of unit tests associated with it. Your mark for function- ality is based on the percentage of unit tests you pass. Assume that you are provided with 10 unit tests for a class, if you pass 8 of these tests, then you earn 80% of the marks for that class. Classes may be weighted diferently depending on their complexity. Your mark for the functionality, F , is then the weighted average of the marks for each of the n classes,
where n is the number of classes, wi is the weight of class i, pi is the number of tests that pass on class i, and ti is the total number of tests for class i.
Code Quality The code quality of new features and refactored existing features will be manually marked by course staf.
To do well in this category of the marking criteria, you should consider the software design topics covered in this course. For example, consider the cohesion and coupling of your classes. Ensure that all classes appropriately document their invariants and pre/post-conditions. Consider whether SOLID principles can be applied to your software.