Background
It’s been a while since your last work with Permanent Assurance Company, and the FEAA/ERP system you helped them with has not been treated well. The company has taken over the Very Big Corporation of America, and in the process the system has seen significant change and growth. 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 requirements are met, and the system mostly delivers what the newly named Crimson Permanent Assurance (CPA) front-end operators need. However, it is very slow in some places (causing non-functional tests to fail), and any time CPA asks someone to add a new feature or fix the lag issues they run away in terror.
CPA 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.
• CPA 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 use proper red-green-refactor practices 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 FEAA package along with all involved classes. CPA has observed the following key issues they would like you to investigate and solve:
• The system uses a LOT of RAM. Analysis has indicated this is due to the Report class, which stores a lot of data. CPA would like you to solve this RAM issue somehow, without breaking the existing use of the Report interface. ReportImpl has been included in your module scope to assist with this, but ReportDatabase is a fake façade on a remote database that you cannot change.
• There are several types of accounting service Orders. The current solution for these orders is to create a new class for each type (based on work type e.g. audits or day-to-day work, whether the order is for priority client , and whether the order is a one off or regularly scheduled work). 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 – CPA would like you to find a way to reduce this class load without breaking the existing Order interface.
• The current method of handling client contact methods is quite bulky – CPA would like you to streamline this somehow.
• Any time Clients are loaded from the database, the system lags for a long time. The database issues themselves have been deemed too expensive to fix, but perhaps you can partially mitigate this with the software somehow?
• Because the Report object captures data without any consistent primary key, and because people have duplicated object names and versions, any time reports need to be compared for equality we have to remember to check many fields. CPA would like you to make this process simpler.
• The Order creation process involves a lot of slow database operations. CPA would like you to simplify this process (especially the database lag while the employee is entering data) without breaking the Order interface.
• The current system is mostly single-threaded. There has been some work on the database side to allow multithreading, but as yet the FEAA module does not have any threading besides the main one. CPA would like you to use multithreading to allow employees to use the system for other things while slow database processes happen in the background.
As well as these they would like you to clean up the code and document where you believe it is necessary (for both the existing code and your changes).
This is very important as it affects the whole mark for the assignment
Detailed Allowed Scope
• The ONLY package you are allowed to modify is au.edu.sydney.cpa.erp.feaa and contents (feaa.ordering and spfea.reports) – these are the ‘in-scope’ classes. No, it doesn’t make much sense for ordering and reports to be inside feaa – this is so it is easier for you to know what you are and aren’t allowed to change.
• You may not modify feaa.reports.ReportDatabase (it’s not the real database and modifying this won’t help CPA).
• You may not replace the uses of auth, contact, database, ordering, or view packages – the test suite will enforce some of this
• You may add, remove, merge, change, etc any of the in-scope classes, so long as the public api of the feaa package remains the same – e.g. FEAAFacade must still exist in the same way so the view can call its methods, etc.
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 production code – If your code submission does not pass the test suite provided the maximum mark will be 50% 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.
• There will be a first demo due at the end of Week 11 for you to show a minimum of 1 of the above problems having been solved, and the code still passing the provided test suite – remember Red-Green-Refactor, you should not make sweeping changes to existing code without checking it passes tests as you go.
• There will be a final demo in partway through Week 13 for you to show however many problems you have solved and again with your code passing the test suite – at this point you may not edit the code further and should focus on your written Report.
• 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!
• The multi-threading issue in particular you should not attempt until all other issues have been solved adequately
• 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.
• Ensure you use versioning software so you can roll-back any changes that break tests when it comes time to demo and submit.
Submission Requirements
• You must submit a zip folder containing your complete FEAA application as a Gradle Project.
• To achieve the compilation & run marks your project MUST compile and test properly with ‘gradle build’ without requiring any modification
• 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
• Code which does not compile and run is likely to be penalised in other areas as well (e.g. you haven’t used design patterns to solve issues well if your code does not compile).
• 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.
• You must include a readme file (a simple text file, either .txt or .md) listing what CPA issues you have solved and where in the code you did so. If you have made any assumptions in your work, or if your code requires anything in particular (like external dependencies/libraries) you should list them here also.
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.