INFR09051 Informatics Large Practical - Coursework: PizzaDronz delivery service
Informatics Large Practical
Michael Glienecke and Stephen Gilmore School of Informatics, University of Edinburgh
Document version 2.3.0
About
The Informatics Large Practical is a 20 point Level 9 course which is available for Year 3 undergraduate students on Informatics degrees. It is not available to visiting undergraduate students or students in Year 4 or Year 5 of their undergraduate studies. It is not available to postgraduate students. Year 4, Year 5 and postgraduate students have other practical courses which are provided for them.
Scope
The Informatics Large Practical is an individual practical exercise which consists of one large design and implementation project, with two coursework submissions. Coursework 1 involves creating a new project and implementing some fundamental components of the project. Coursework 2 is the implementation of the entire project together with a report on the implementation. Please note that the two coursework are not equally weighted. There is no exam paper for the Informatics Large Practical so to calculate your final mark out of 100 for the practical just add together your marks for the coursework.
These deadlines are interpreted strictly and penalties are applied automatically to any work which is sub- mitted late. You are advised to submit at least 30 minutes before the deadline in order to avoid problems with uploading your work.
Chapter 0
The Coursework Specification
0.1 Introduction
Have you ever been involved in an all-night hackathon or have been pulling an all-nighter to get super- tough practicals like this one finished on time? If so you will know that there comes a time late at night when nothing else but a pizza will keep you going to get all your work done! Well, not to worry, the School of Informatics is considering creating a service called PizzaDronz where students can order a pizza by an app and have it delivered directly by drone to the top of the Appleton Tower where they can collect it and eat it while taking a break from the keyboard. Your midnight feast worries should be a thing of the past when the service launches on 1st January 2023! Of course, pizzas make a great lunchtime snack to share with friends so the service will operate all day, not just during the hours of darkness.
Having pizzas delivered by drone will minimise the time that busy Informatics students need to spend queueing to buy lunch or dinner and will also speed delivery, because, unlike delivery by car or bike, drones do not need to follow the road layout, stop at red traffic lights, and so forth. The idea is also good for the en- vironment. Fewer deliveries by car means less exhaust pollution generated, and cleaner air for Edinburgh. In addition, the service could be helpful to new students who have just joined the School and have not yet got their bearings and do not know the great pizza restaurants near the University’s Central
The idea for a drone-based food delivery service has some issues, especially when delivering hot food. We will assume that the drone will fly high enough that it will not crash into even very tall buildings such as The David Hume Tower. However, Edinburgh’s many seagulls might think that someone has kindly sent them a delicious meal and attack the drone in order to be able to get at the contents inside. In addition, software and hardware errors do happen so we must route the drone as much as possible away from populated areas such as George Square Gardens and Bristo Square, among others. Ideally, the drone should usually be flying over the roofs of buildings. This is for the safety reason just mentioned (we don’t want to drop hot food or metal drones onto unsuspecting students studying in the sunshine in George Square Gardens). An additional issue is privacy. Many drones are fitted with cameras and some students
You should think that your software is being created with the intention of passing it on to a team of software developers and student volunteers in the School of Informatics who will maintain and develop it in the months and years ahead when the PizzaDronz delivery service is operational. For this reason, the clarity and readability of your code is important; you need to produce code which can be read and
0.1.9 Files to be used during testing
In addition to the dynamic data returned from the various JSON requests while your application is running, you can retrieve some GeoJSON files9 which have been prepared for you to use when you are testing your application.
—⋄—
When the PizzaDronz service is operational the server content will be kept up-to-date but the GeoJSON files prepared for testing purposes will not; they only relate to the synthetic data that you are given to test your application, not the lunch orders received each day when the service is operational. This means that your application should not read these GeoJSON files, you should only load them on the http://geojson.io/ website when checking the flightpath that you have generated for the airborne drone.
Figure 6: The contents of the file all.geojson rendered by the website http://geojson.io/. This file contains all of the features that we have seen in Figure 5 plus the initial location of the drone (the yellow placemarker, on top of Appleton Tower), and the four pizza restaurants which are participating in the scheme according to the website content restaurants.geojson (the blue placemarkers, with a building symbol). The semi- transparent red polygons are the no-fly zones.
0.1.10 An illegal flight path
Once back inside the Central Area, the drone must not leave again until it has delivered the pizzas to the roof of Appleton Tower. The flightpath shown in Figure 7 from Sora Lella restaurant to Appleton Tower is completely illegal, as well as being sub-optimal in taking more moves than necessary.
0.2 Files to be created in CW 2
As the main part of this practical exercise, you are to develop a Java 18 application which when given a date (passed in as a runtime argument to the application) calculates a flightpath for the drone which delivers the pizza orders placed for that date as best it can before it returns close to its initial starting location. As previously stated, the number of moves made by the drone12 should be 2000 or fewer.
The date format YYYY-MM-DD (which is actually the ISO 8061 format) has to be used in every file which is generated .
So e.g. flightpath-2023-04-13.json or drone-2023-04-13.geojson or deliveries-2023-04-13.json.
The format is always xxxx-YYYY-MM-DD where xxxx is the relevant file (drone, flightpath or deliveries)
Note: Please use hyphens, not underscores, in the filenames and use only lowercase letters. A filename
of drone-2023-04-15.geojson is acceptable; a filename like Drone_2023-04-15.GEOJSON is not. Please note that your filename must use two digits for the day and the month; a filename of drone-15-9-2023.geojson is not acceptable because it does not match the pattern for the filename of drone-YYYY-MM-DD.geojson.
Your application should record the drone’s behaviour by creating three local files in JSON-format to record information on the day’s deliveries, which have to have the .json extension and have to be submitted with the application.
- The first file (deliveries-YYYY-MM-DD.json) records both the deliveries and non-deliveries made by the drone
- Thesecondfile(flightpath-YYYY-MM-DD.json)recordstheflightpathofthedronemove-by-move
- Thethirdfile(drone-YYYY-MM-DD.geojson)isthedrone’sflightpathinGeoJSON-format
Assuming that your project is named PizzaDronz then when compiled with the Maven build system your Java application will produce an über JAR file in the target folder of your project which will be named PizzaDronz-1.0-SNAPSHOT.jar. If you run this JAR file with the command
java -jar target/PizzaDronz-1.0-SNAPSHOT.jar 2023-04-15 https://ilp-rest.azurewebsites.net cabbage
it should read the lunch orders for the date 2023-04-15 from the REST service, together with the restaurants and menus, which is located at the provided base address. It should use the hashcode of the final word on the command line (the example here is "cabbage") as the seed to initialise the random-number generator (if used). Your application should check that the command line parameters are valid (in the sense of being a valid date and URL1314).
The outfile deliveries-YYYY-MM-DD.json In this file you have an array of JSON records, each with at- tributes for:
- orderNo — the eight-character hexadecimal string assigned to this order in the orders REST service endpoint;
- outcome—theOrderOutcomevalueforthisorder,asastring; and
- costInPence — the total cost of the order as an integer, including the standard £1 delivery charge.
· this file and that you write an array [] of JSON records, one entry for each processed order.
When the contents of the testing file all.geojson and your drone-YYYY-MM-DD.geojson file is ren- dered by the website http://geojson.io, it should produce a visualisation, which overlays the base map with the drone’s flightpath.
As an example from a previous year, this could look like Figure 8 with a grey line showing the flight- path of the drone. The shape of this line will depend on the date being plotted and on the drone control
0.5 Project management
The build system to be used for your project is Apache Maven, a Java-based build system which manages all of the project dependencies in terms of Java libraries which you use, and enables you to build your system into a single self-contained JAR file (the über JAR) for deployment. This JAR file has all of your code and all of the libraries that you use together in one place. IntelliJ IDEA CE comes with Maven installed so you do not need to download Maven separately.
0.5.1 Using third-party software and libraries
This practical exercise allows you to use free software, but not commercial software which you must pay for or license. One free software development kit (SDK) which you should find useful is the Mapbox Java SDK which provides classes and methods for parsing and generating GeoJSON maps. Instructions for adding the Mapbox Java SDK to your project are available at https://docs.mapbox.com/android/java/overview/.
Chapter 1
Informatics Large Practical: Coursework One
Michael Glienecke and Stephen Gilmore School of Informatics, University of Edinburgh
1.1 Introduction
This coursework and the second coursework of the ILP are for credit; weighted 25%:75% respectively. Please now read Appendix A for information on good scholarly practice and the School’s late submission policy.
In this project you are creating a Java application which is built using the Maven build system. We will begin by using IntelliJ IDEA to create the project structure.
1.2 Getting started
1.3 Setting up a source code repository
(This part of the practical is not for credit, but it strongly recommended to help to protect you against loss of work caused by a hard disk crash or other laptop fault.)
1.4 The implementation task
For this coursework we will implement some fundamental Java classes and methods which will be useful also for Coursework 2. The functions which we will implement are concerned with the movement of the drone and with the delivery cost for items. Your implementation will be judged on three criteria: correctness, documentation, and code readability.
(a) YourimplementationmusthaveaJavapackagenameduk.ac.ed.infwithaclassnamedLngLatfor representing a point (you can use a record in Java as well, which would actually be more suitable1). The constructor for this class should accept two double-precision numbers, the first of which is a longitude and the second of which is a latitude. The class should have two public double fields named lng and lat. (This part is a freebie; see above.)
(b) TheLngLatrecordshouldhaveano-parametermethodcalledinCentralAreawhichreturnstrueif the point is within the Central area and false if it is not.
Chapter 2
Informatics Large Practical: Coursework Two
2.1 Introduction
As noted above, Coursework 1 and Coursework 2 of the ILP are for credit; weighted 25%:75% respectively. Information on good scholarly practice and the School’s late submission policy is provided in Appendix A.
You are now to extend your project from Coursework 1 into a complete implementation of the drone delivery service as described in this document. You can re-use any code which you produced for Coursework 1 including the code in the Maven XML document named pom.xml. You are free to edit, refactor, or delete any code from Coursework 1, keeping only the code that you find useful.
This coursework consists of the report, the implementation, and a collection of output files written by your implementation. The code which you submit for assessment should be readable, well-structured, and thor- oughly tested.
2.2 Report on your implementation
You are to submit a report documenting your project containing the following. Your report should have two sections as described below.
1. Software architecture description. This section provides a description of the software architecture of your application. Your application is made up of a collection of Java classes; explain why you identi- fied these classes as being the right ones for your application.
2. Drone control algorithm This section explains the algorithm which is used by your drone to control their flight around the locations of interest and back to the start location of their flight, while avoiding
2.3 Source code of your application
You are submitting your source code for review where your Java code will be read by a person, not a script. You should tidy up and clean up your code before submission. This is the time to remove commented- out blocks of code, tighten up visibility modifiers (e.g. turn public into private where possible), fix and remove TODOs, rename variables which have cryptic identifiers, remove unused methods or unused class fields, fix the static analysis problems which generate warnings from IntelliJ1, and refactor your code as necessary. The code which you submit for assessment should be well-structured, readable and clear.
