SOFT3202 / COMP9202 

Design Pattern Assignment - Source Code

Background

It’s been a few decades since your last work with Brawndo (you have been in cryosleep), and the SPFEA/ERP system you helped them with has not been treated well. Many consultants have come and gone on the system, and there have been several “rush” jobs that focused on shipping code that worked and not on code that worked (or was designed) well.

 The end result is a system that works… sort of. All of the functional tests pass, and the system mostly delivers what the customers want. However, it is very slow in some places (causing non-functional tests to fail), and any time Brawndo asks someone to add a new feature or fix the lag issues they run away in terror.

Brawndo have now asked you to come in and fix one of their key components, but since money is rather tight they have placed restrictions on your work:

· Several ‘module borders’ in the system exist – you may not change anything beyond the module border. These modules are pretend abstractions of legacy software the organisation has lost the source code for and does not have the time or money to redevelop.

· Brawndo has the existing API for these modules and has given you a 'pretend' version of each module for each to test with.

· Your solution will be run through a test suite (provided to you as well) to ensure the module interactivity remains intact at the end, and to ensure your delivered code still responds in precisely the same functional way as before.

Thankfully, the module you will be redeveloping was behind a façade just like your original design – so besides a few public interfaces you can change anything you like about its internal workings without worrying about the view not being able to handle the changes.

You should be very careful when refactoring this code. The code currently passes function-based testing and should continue to do so the entire time - no breaking changes!

Work Required

You must dig into and correct the design and implementation of the SPFEAModule package along with all involved classes. Brawndo has observed the following key issues they would like you to investigate and solve:

· RAM Issue: the system uses a LOT of RAM. Analysis has indicated this is due to the Product class, which stores a lot of data. Brawndo would like you to solve this RAM issue somehow, without breaking the existing use of the Product interface. ProductImpl has been included in your module scope to assist with this, but ProductDatabase is a fake façade on a remote database that you cannot change.

· Too Many Orders: There are several types of Orders. The current solution for these orders is to create a new class for each type (based on discounting method, whether the order is a personal or business order, and whether the order is a one off or subscription). The full system has 66 * 2 * 2 of these classes (264 order classes!), with 8 of these (2*2*2) provided to you as an example – Brawndo would like you to find a way to reduce this class load without breaking the existing Order interface.

· Bulky Contact Method: The current method of handling customer contact methods is quite bulky (ie ContactHandler.sendInvoice() is hard to maintain and is getting quite long) – Brawndo would like you to streamline this somehow.

· System Lag: Any time Customers are loaded from the database, the system loads for a long time – even if only 1 field of 1 customer is needed (like id). The database issues themselves have been deemed too expensive to fix, but perhaps you can partially mitigate this with the software somehow?

· Hard to Compare Products: Because the Product object captures data without any consistent primary key, and because people have duplicated object names and versions, any time products need to be compared for equality we have to check many fields (in code). Brawndo would like you to make this process simpler.

· Slow Order Creation: The Order creation process involves a lot of slow database operations. Brawndo would like you to simplify this process (especially the database lag) without breaking the Order interface. The users are particularly annoyed that they have to experience system load between every change made to the order (before the order is finalised)

As well as these they would like you to clean up the code (only within au.edu.sydney.brawndo.erp.spfea as described in the scope section) and document (java docs and inline comments for more complex blocks) where you believe it is necessary (for both the existing code and your changes). We recommend the Google Style GuideLinks to an external site., if you choose another guide you will need to note that in the "Notes About the Submission" section of the readme.

Detailed Allowed Scope

· The ONLY packages you are allowed to modify is au.edu.sydney.brawndo.erp.spfea contents (all classes in spfea.ordering and spfea.products (except for ProductDatabase) and all other exiting classes in spfea, SPFEAFacade has limitations as can be seen below).

· You may not modify spfea.products.ProductDatabase (it's not the real database and modifying this won't help Brawndo).

· You may not replace the uses of auth, contact, database, ordering, or view packages - the test suite will enforce this

· You may add, remove, merge, change, etc any of the in-scope classes, so long as the public api of the spfea package remains the same - i.e. SPFEAFacade must still exist in the same way so view can call its public methods, so the method signature needs to remain the same. You can, however, add private fields and methods to the facade as needed and you can modify the code in the public-facing methods to facilitate your improved design.

· You may not change the provided test suite, you can write additional tests to ensure the quality of your work, clearly separate any tests from the provided suite (ie. different module or/and test files).

· You may not change the provided build.gradle file.

Assessment Notes

· You will be assessed on your code quality, your use of design patterns, and keeping to the requirements of the client.

· The most important thing to remember is DON'T BREAK THE PRODUCTION CODE - If your code submission does not pass the test suite provided the maximum mark will be 0% EVEN IF all other requirements are perfect. Run the tests after each small change you make (that's what they're there for) and use version control to ensure you are able to roll back any breaking changes you can't fix.

· You should not make sweeping changes to existing code without checking it passes tests as you go.

· There are many ways to solve the given problems – for best marks you should prioritise methods that use the design patterns you have been taught in this unit.

· Marking will be focused on your ability to solve these problems with good, clean, patterned code, over and above solving ‘all’ of the problems. You will get much better marks for solving 50% of the problems completely and with good solutions than you will for solving 100% of the problems with poor quality code. Ensure you focus your efforts!

o There will be times when the modules you can’t change force you to do things that break OOP design principles – this is perfectly normal. Make sure it is actually required, then document where and why you have done so. Patterns may help you limit the negative effects this has on the rest of your code.

· It is strongly recommended that you use versioning software so you can roll-back any changes that break tests when it comes time to submit, however this is not a requirement of the assessment.

Resources

· BrawndoCodebase.zip (V3)Download BrawndoCodebase.zip (V3)

· readme.md Download readme.md(this is also a part of the codebase)

· Please check this Ed FAQ postLinks to an external site. for any updates and answers to common questions before you make a submission.

Submission Requirements

· You must submit a zip folder containing your complete spfea application as a Gradle Project: zip [src, build.gradle, readme.md]

· To achieve the compilation & run marks your project MUST compile and test properly with 'gradle build' without requiring any modification

o This means any locally stored dependencies you decide to add must be included in the zip folder and given a relative reference in your build.gradle - in general avoid this as work the libraries do for you will not earn you marks

· When running your code through the test suite for marking the 'out of scope' classes such as TestDatabase or the test suite itself will be swapped out with known original sources - be careful not to edit these accidentally as your edits will NOT carry over and this may cause your code to fail testing.

The readme.md template and how to use it:

· 

o You must include a readme.md file listing what Brawndo issues you have solved and where in the code you did so. In particular, you must follow the template readme.md provided with the codebase. If you fail to use that format your submission might not get marked. There are two main sections to the readme: "Solutions to the Key Issues" and "Notes About the Submission".

o The solutions section will have a subsection to every problem you need to fix, they names of the section correspond to the problems. For each issues you solve you must fill in the design pattern you used or describe an alternative solution.

§ For design patterns: replace "design pattern name" with the name of the design pattern you used and list every participant involved in the design pattern in the same format as the template (eg "- concrete observer: SillyObserver.java"). Do that for every participant involved in your code.

§ For alternative solutions: if you have solved a problem without a use of a design pattern then you need to follow this format for the solution. In the "Solution Summary" you need to 

describe what changes you have made to the codebase, be specific to the classes and methods you changed and how. And for "Solution Benefit" you need to describe how your solution was helped the problem. Please note (as mentioned in the "Assignment Notes") that for best marks you should prioritise methods that use the design patterns you have been taught in this unit. This section has a word limit of 400 words.

o If you have made any assumptions in your work you should list them in the "Notes About the Submission" section.

Final Notes

· This is a new codebase with some complexity. As with any such code, there is a high chance of functional bugs existing in the codebase or test suite. If you do notice a functional bug, please post this on Ed - either a fix will be given and the code updated, or you will be allowed to ignore it (non-functional bugs are intended and you should fix these yourself).

· The test suite is there to guide you, not guarantee correctness. It is entirely possible to code something that directly hits the limited test cases specified but would fail if those test cases were changed to anything else - this will not yield a good result. Treat the combination of the test suite, the existing code, and the (sparse) comments as the specification for this code - if anything is unclear you should ask on Ed before changing any behaviours you might notice through the facade.

Marking Guide Clarifications

The Rubric below totals to 10 Points which then will be scaled to 20% of your grade.

The following is the breakdown of marking for each of the 6 issues to be solved, the total mark for a single issue solved "correctly" is 1 Point:

View Rubric