CSSE2002 Programming in the Large

Programming in the Large (CSSE2002)

Assignment 2 — Semester 2, 2024

Overview This assignment provides experience working with an existing software project. You are provided with a small extension to the Farming game application. The extension has intro- duced errors and is poorly written. Fortunately, a suite of JUnit tests accompanies the extension.

Additionally, you must write JUnit tests for a subset of previous classes.

You will be assessed on your ability to:

• find and fix errors in provided code,

•  meaningfully refactor provided code to improve its quality,

• extend the functionality of provided code, and

• write JUnit tests to a given specification.

Task Your program, Farm MVP, was a massive success! However, some users felt it was a bit boring, and needed more farming. You decide to make the product more exciting by introducing a new game to the Farm program.

The course staff have attempted to add a farming mini-game, in FarmGrid, but have made a real mess of it. Your task is to fix their mistakes and also refactor the code to improve its quality. Additionally you are expected to write JUnit tests for previous classes and extend the functionality of the new FarmGrid by adding saving and loading.

Plagiarism All work on this assignment is to be your own individual work. Code supplied by course staff  (from this semester) is acceptable, but must be clearly acknowledged. CCode generated by third-party tools is acceptable but must be clearly acknowledged. See Generative Artificial Intelligence below. You must be familiar with the school policy on plagiarism:

https://uq.mu/rl553

Generative Artificial Intelligence You are strongly discouraged from using generative arti- ficial intelligence (AI) tools to develop your assignment. This is a learning exercise and you will harm your learning if you use AI tools inappropriately. Remember, you will be required to write code, justifications by hand, in the final exam. If you do use AI tools, you must clearly acknowledge this in your submission. See Appendix C from A1 for details on how to acknowledge the use of generative AI tools.  Even if acknowledged, you will need to be able to explain any part of your submission.

Interviews In order to maintain assessment integrity and in accordance with section 5.4 of the course profile, you may be asked by the course coordinator via email to attend an interview to evaluate genuine authorship your assignment. Please refer to the course profile for further details.

Software Design In contrast to A1, you will not be given specification at the method  level. Instead, you are given a broad specification of component(s) and how they must be integrated with the existing 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.

Additional Features/Changes from A1

Grid An interface describing the methods and interactions on the farming grid. Contains the ability to:

• Interact with elements of the grid, such as feeding animals.

•  Place things onto the Grid, such as crops to grow.

•  Harvest things from the Grid

•  Display the Grid’s visual text representation of items.

•  Get the stat information about each position on the Grid.

•  Get the row and column number of the Grid.

This Grid interface is the key component of this new feature as it outlines how the FarmManager will interact with the new mini-games features. As such you cannot modify this interface in any way.

FarmGrid Represents the state of an animal or plant farm using a grid structure. It implements the Grid interface, providing methods for displaying and interacting with the grid.

The current responsibilities of the Farm Grid include:

•  Storing farm information:  FarmGrid stores the data representing the farm  (e.g. plants, animals and empty spaces).

•  Providing a visual representation:  the farmDisplay() method from FarmGrid generates a string-based, visual representation of the farm.

•  Manipulating farm information:  Methods like place() from FarmGrid provide a way to in- teract with and change the farm information stored inside FarmGrid.

When it comes to refactoring FarmGrid you are free to make any modification you would like, including refactoring the entire class out if you so chose, as long as FarmManager still correctly stores some instance that implements Grid.  Please note that if you rename FarmGrid or create new classes provided code may need to be updated to ensure everything is correctly instantiated. Make sure you are still passing all the tests for your class, not the original FarmGrid.

Farm Manager The behaviour of the FarmManager class is nearly identical to A1 apart from an additional farming mode.   In  the new farming mode,  FarmManager will be responsible for coordinating interactions between the user and the farm model. It serves as the interface through which the user can view and modify the farm’s state. By interpreting user input, the FarmManager allows the user to perform. various actions that affect the farm, such as viewing the current layout and making changes to the farm’s configuration.

The responsibilities of Farm Manager is nearly identical to A1 except for the following additions:

•  Handling user input:  FarmManager processes commands entered by the user,  interpreting them and determining the appropriate actions to take based on the input.

•  Displaying information: FarmManager provides the user with a way to see the current state of the farm by requesting and showing relevant data from the farm model.

•  Updating the farm model: FarmManager ensures that the farm model is updated according to the user’s actions, allowing for changes such as placing new items or modifying existing ones.

•  Add products to inventory: FarmManager now allows items grown or collected from the farm to be added to the inventory to sell to customers as per the A1 functionality.

You are free to extend FarmManager as you wish as long as you leave the original logic flow and functionality intact. Make sure you are running the tests after you modify FarmManager to ensure they can still correctly access your Grid.

Components

This assignment has five components.

1.  JUnit component: You are asked to write JUnit tests for a subset of previous classes.

2.  Bug Fixing component: You need to debug FarmGrid.java to find and then fix bugs.

3.  Refactoring component: Refactor the implementation of the Farm  Grid to improve the design while maintaining its functionality.

4. Implementation component: You are required to implement the appropriate components that satisfies the specification on saving and loading.

5.  Justification component: Write your justification design document.

Component #1:  JUnit Tests

Write JUnit 4 (Do not use JUnit 5 for the assignment) tests for all the public behaviour of the following classes:

• BasicInventory

(in a class called BasicInventoryTest)

• FancyInventory

(in a class called FancyInventoryTest)

The JUnit tests you write for a class are evaluated by checking whether they can distinguish be- tween a correct implementation of the respective class (made by the teaching staff) and incorrect implementations of the respective class (deliberately made (sabotaged) by the teaching staff).

Never import the org.junit.jupiter.api package. This is from JUnit 5.  This will cause the JUnit tests to fail, resulting in no marks for the JUnit component.

See the Marking section and Appendix A for more details.

Component #2:  Debugging

The provided code comes with an implementation of FarmGrid. The new introduction of Farm Grid is not working as expected. Many tests of the given test suite will fail initially and this may be overwhelming. Find the smallest failing test  — do not start with a complex test case as there are multiple bugs that may intersect.  Create some theories about what may be wrong with the software; play testing the software may be helpful. You may find it helpful to construct some smaller test scenarios.

There are between 8 and 12 bugs, all of which are straightforward to fix with minimal changes to FarmGrid.java. You will need to have a clear understanding about what the bug is before attempting to fix it. You may find manually writing the test cases out helpful.

Note: It would be useful to detail the bugs in your justification document as you go!

You must complete the debugging before you begin the refactoring component.  Not only will this make your life easier but you are required to copy the debugged version of FarmGrid into a new package before refactoring so we can easily identify your bug fixes without having to review the entire refactored code.

When the debugging is done copy FarmGrid from the package farm .core .farmgrid into a newly created package farm.debugged.farmgrid. The name of the class must remain as FarmGrid after copying. This should be a copy not a move, there should be two FarmGrid in your project as per below. See the submission section for more information.

farm/core/farmgrid/FarmGrid.java

farm/debugged/farmgrid/FarmGrid.java

Component #3:  Refactoring

The current implementation of FarmGrid does not adhere to SOLID design principles.  This makes the code difficult to maintain and extend.

In this component, your task is to refactor the FarmGrid class so that it aligns with SOLID prin- ciples as much as possible. This is primarily a design activity, and you are free to make sound design decisions that improve the code’s cohesion, reduce coupling, and promote better information hiding. The refactor should distribute responsibilities appropriately across new or existing classes, making the system more modular and scalable.

You are free to modify FarmGrid as much as you like including renaming it, as long as your new Grid/s implement the Grid interface and are correctly accessible through the FarmManager and are passing the tests.  Re-read the Additional Features/Changes from A1 section for more information.

Note: You should be modifying the FarmGrid class in the core package, not the one you copied over after debugging.

The design of your classes is part of the assessment.  Please be mindful that:

1.  Discussing the design of your classes in detail  代 写CSSE2002 Programming in the Large with your peers may constitute collusion. You may discuss general design principles (cohesion, coupling, etc.) but avoid discussing your specific approach to this assignment.

2.  Course staff will provide minimal assistance with design questions to avoid influencing your approach. You are encouraged to ask general software design questions.

You must preserve the existing functionality after bug fixing. 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 modification that may cause tests to fail.

Component #4:  File Load & Saving

You must create two new features, one for saving a farm to a file and one to load a farm from a file. The file format is not specified. You must design a suitable file format that can store the state of a farm.

Saving and loading do not need to take into account the state of other areas of the game, such as the inventory, only the Grid. Loading is performed when the FarmManager is run, and saving can only be performed at the start of a new day, before any actions have taken place.

1.  The saving and loading features must be compatible, i.e. saving a farm and then starting a new game and loading that farm should return the farm to that same state.

2. You must not utilize Java Serialization.

3. You must implement Saving and Loading inside the provided stub classes.  You may add additional methods and add to existing ones, but do not change the signature of the provided method stubs.

To  get you  started the  FileSaver  and  FileLoader  classes  have  been  created  for you  in the farm.files package with the minimum required stub methods.

Component #5:  Justification Document

After completing the above 4 components, you need to compile a justifications document detailing your design decisions for refactoring the FarmGrid. It should also list all the bugs you identi- fied and your fixes. You are free to use your own format for the document; however, it should clearly explain how your refactor complies with each of the SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion). Ensure that your document highlights how your changes improve the structure and maintainability of the Far- mGrid component. You may use diagrams/code snippets as needed. All your justifications MUST refer to your codebase (i.e package → class → method ...)  and it should not be generic descriptions.

In the assignment, you should ensure your justifications document is concise, clearly explaining the thinking behind your design decisions.  We’ve intentionally not set a word count to give you the space to express your ideas freely.  However, avoid unnecessary length, and focus on the clarity of your explanations

Your document should include the following sections. However, you are free to add any additional sections if required.

1.  Justifications for Refactoring (preferably organized according to each SOLID principle). Make sure to refer to your codebase to provide evidence and support your justifications.

2.  Bugs

3.  Fixes

4.  Appendix (You must include your uses of GenAI here)

Note that the provided tests are not a good demonstration of unit testing. As we want you to have a high degree of flexibility in how you implement your design, the tests are not granular and may be considered closer to integration tests.

Tasks

1.  Download the assignment  .zip archive from Blackboard.

• Import the project into IntelliJ.

•  Ensure that the project compiles and runs (including running JUnit tests).

2. Identify and fix the errors/bugs in the provided code.

•  The FarmGrid component contains several bugs, causing the provided JUnit tests to fail.

• You must fix all errors in the code to implement the specification and pass all the tests.

• You must not change the provided tests in any way.

•  Copy your fixed FarmGrid.java class into the correct package once completed before refactoring.

3.  Refactor the provided code.

•  The provided FarmGrid 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.

4.  Complete the implementation of the provided code.

•  The components to be developed are for file saving and loading that have not been implemented.

• You must implement these according to the specification above in the provided stub classes.

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

5. Write a justification document on the design decisions.

•  Provide justifications on design decisions you made in refactoring the FarmGrid.

•  Clearly explain how your refactor complies with each of the SOLID principles

•  List down the bugs you identified and your fixes to them. You not need to explain the bug/fix, just what they were and how you resolved them.

• MUST be a PDF file for submission.

Marking

The assignment is marked out of 100.  The marks are divided into five categories:  bug fixes (B), extension functionality (F), JUnit tests (T), code quality (Q), and style. (S).

The overall assignment mark is defined as

A2  = (10 × B) + (10 × F) + (30 × T) + (40 × Q) + (10 × 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 fix.  The number of bugs you fix is determined by the number of unit tests you pass.  For example, assume that the project has 40 unit tests and when given to you, 10 pass. After you have fixed the bugs, 25 tests pass. Then you have fixed 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 differently 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.

JUnit Tests The JUnit tests that you provide in BasicInventoryTest and FancyInventoryTest will be used to test both correct and incorrect (faulty) implementations of the BasicInventory and  FancyInventory  classes. Marks will be awarded for distinguishing between correct and incorrect implementations. A test class which passes every implementation (or fails every implementation) will likely get a low mark.

Your tests will be run against a number of faulty implementations of the classes you are testing. Your mark for each faulty solution is binary based on whether at least one of your unit tests fails on the faulty solution, compared against the correct solution.  For example, if you write  14 unit tests for a class, and 12 of those tests pass on the correct solution and 11 pass on a faulty solution, then your mark for that faulty solution is 1 (a pass). In general, if bi  of your unit tests pass on a correct implementation of class i and ti  pass on a faulty implementation, then your mark for that faulty solution is

where n is the number of faulty solutions. See Appendix A for more details.

Code Quality The code quality of new features and refactored existing features will be manually marked by course staff.

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. The submitted code will be checked against the justification report when marking

An implementation with high code quality is one that is readable, understandable, maintainable, and extensible. The rubric on the following page details the criteria your implementation will be marked against. Ensure that you read the criteria prior to starting your implementation and read it again close to submission to ensure you meet the criteria.