This assignment will focus primarily on topics not otherwise covered in Assignment 1, but these build on earlier topics, and good practices assessed in Assignment 1 will continue to be assessed here.
Design and implement the system described below under Problem Description. Specifically:
Use either Java, C#, C++ or Python to implement the system described.
If using Java, you must also use PMD as in the practical worksheet code, and it’s thus highly recommended that you use Gradle.
If using Python, please use type hinting for all method/function parameters and return types.
In your design, use (a) the Observer Pattern, and (b) the State Pattern. Make sure that they both:
Help to create low coupling (and/or high extensibility).
Address the actual requirements of the system; i.e., they’re part of the solution to the problem description, not just added on.
Use dependency injection, good error handling, logging, a good breakdown of packages (or namespaces), and generally well thought out classes/interfaces.
Provide a UML class diagram and one or more UML state chart(s), accurately representing your design.
The class diagram must show the structure of your entire app.
The state chart(s) must show how states and state transitions occur in specific, relevant part(s) of the app.
Use a proper tool; e.g., Umlet, draw.io, PlantUML or others, but submit your diagrams in .pdf or .png format. (Avoid tools that have no explicit support for UML.)
Make the diagram layout as neat and logical as practical. Minimise crossing lines.
If in doubt as to whether or not to represent certain things on the diagram, err on the side of more detail.
Provide a response to each of the marking criteria. Record this in a file called criteria.txt (or criteria.md).
Submit all of the above, plus a signed declaration of originality, to the appropriate area on Blackboard. Include everything in a single .zip/.tar.gz file (please avoid .rar, .zipx or .7z). You do not need to include any compiled code.
You must verify that your submission is correct and not corrupted. Once you have submitted, please download your own submission and thoroughly check that it is intact. You may make multiple submissions. Only your last one will be marked.
You are principally being assessed on design. However, we also need to ensure you produce a working app, and running demos is an efficient way to do this. The logistics will vary between locations, but the following approaches are being considered:
Uploading a short video.
Scheduling a real-time online demo (e.g., over Blackboard Collaborate or other video conferencing tools).
Scheduling a face-to-face demo.
Further announcements will be made on which approach(es) will actually be used.
If your app does not work as expected, you should expect a mark penalty.
The assignment will be marked out of 45. There are six core marking criteria and an additional bonus:
6 marks – General code quality, including addressing PMD rules.
The code must be reasonably-well commented.
If using Java, you must also use PMD, and use the same PMD “ruleset” — “oose-pmd-rules.xml” — used in the practical worksheet code.
There should be no PMD rule violations.
You may suppress PMD rules, in specific places, if appropriate, as long as you include a comment justifying it. If you’re not certain what would be appropriate, ask in advance (in general terms).
If using another language, you must find and use another such “linting” tool in an equivalent manner.
[6 marks] — Clear and distinct package/class/interface/method responsibilities.
[6 marks] — Appropriate error handling and logging.
[6 marks] — Implementation of dependency injection.
[7 marks] — Use of the Observer Pattern.
[7 marks] — Use of the State Pattern.
[7 marks] — Clear and correct UML class diagram and state chart(s).
[6 bonus marks] — Meaningful use of generics, in the sense of creating your own class/interface with generic type parameter(s), such that it contributes to code reuse.
These bonus marks are not intended to be easy to get. Do not spend your time on them until you’re confident with the other criteria.
Your Responses to the Criteria
You must provide a response to each of criteria 2–6, as part of your submission. For each of those critera, write a paragraph or two justifying the choices you have made. Include this in criteria.txt.
This fulfils two purposes:
We want to know that you can articulate, in plain English, what you are doing. This is part of the task.
If you do something unusual/unorthodox, this is your opportunity to justify it.
One way to think about what you’re doing here is this: imagine that the marker is slightly sceptical about whether to award you the marks for a given criterion. What would you say to convince them?
Make your responses concise and to-the-point. Address each criterion separately.
Your task is to design and implement a system to simulate natural disasters, to help test emergency service responses.
Your particular part of the system will:
Generate pretend emergencies based on the contents of a file;
Receive updates from emergency responders;
Determine what actually happens (in the course of the simulation);
Send this information back to emergency responders.
This all happens “in real time”. Your simulation must maintain a loop that counts time in seconds, and at each iteration it must run through the above steps. Only at specific points in time will things actually happen, but you won’t know unless you check every second.