Advanced Software Engineering (F21AS) Coursework 2022
This coursework contributes 60% of your mark for the course and involves the design and implementation of an application. The application has been chosen to be complex enough to enable you to try out various software engineering features, whilst small enough to fit in the time available. The scenario is based around a flight monitoring system.
You should work in groups of 4-5, with the group collaborating over the design and implementation of the application. Larger groups will be expected to achieve proportionally more.
All group members are required to contribute to design, implementation and report writing. To ensure fairness, each group member will be asked to assess the contribution of other members. Given differences in educational and vocational backgrounds, some variance is expected in the level of contribution. However, if the contribution of a group member is significantly below what is expected, then the marks for each student in the group will be adjusted, considering each member’s contribution.
The application is developed in two stages:
• Stage 1 follows on from materials you will be taught in Part 1 of the course, and concentrates
on planning, iterations, data structures, exceptions, and unit testing.
• Stage 2 follows on from materials you will be taught in Part 2 of the course, and focuses on
threads, design patterns and agile methods.
The requirements of the application are outlined in the following sections of this coursework specification. Each stage has two sets of requirements:
• Functional requirements, which describe what the application should do.
• Software engineering requirements, describing how you should develop the application.
The following deliverables are required:
• A group development plan, handed in before your group begins implementation work.
• Two group reports, describing your group’s work, to be written by the whole group.
The following table shows when each of these deliverables is due, and how much they are worth:
Stage Deliverable Weight Deadline
* The development plan will be assessed alongside the Stage 1 group report, so you will not receive separate feedback on this. All deadlines are strict and late submission penalties apply.
Group development plan*
Friday 11th February (Week 5)
Group report
Friday 4th March (Week 8)
Group report
Friday 1st April (Week 12)
Stage 1 is designed to assess your understanding of planned iterative development and your knowledge of data structures, exception handling and unit testing, which are all taught in the first half of the course. You are required to develop a simulation of a flight tracking system. This first stage develops the basic functionality, which you will then extend in Stage 2.
Functional requirements
We consider a fleet of planes from different airlines flying in the sky. The initial data about the flights is provided in a file. The objective of the applications is to track the position of the flights. The application also estimates the CO2 emission depending on the type of plane and distance travelled. We consider that a fixed amount of CO2 is emitted per litre of kerosene. The application involves managing various entities depicted in the following class diagram:
Figure 1. Class diagram of the application entities
1. The application initially reads data from four files. Sample files are given for illustration, but you should add to these as necessary. The files are:
a. a list of airports. Each airport is described by a name (e.g. Heathrow), a code (e.g. LHR), a GPS position with latitude and longitude (e.g. in DMS format, 51° 28′ 12.0720” N and 0° 27′ 15.4620” W)1. Each airport has a control tower. We consider that control towers are located only at airports.
File format: code; name; Latitude; Longitude
b. a list of aviation companies, each with a name (e.g. British Airways), and a code (e.g. BA).
File format: code; name
c. a list of plane types, with name (e.g. Boing 777), the cruise speed in kilometres per hour, and the average fuel consumption in litres per 100 kilometre.
File format: model; manufacturer; speed; consumption
d. a list of flights; each flight has a unique identifier in the form of the code of the manufacturer followed by a serial number (e.g. BA664), the type of aeroplane (e.g. B777), departure airport and destination airport, departure date and time in
1 A standard GPS data parser can be used for reading, such as
https://github.com/gbif/parsers/blob/master/src/main/java/org/gbif/common/parsers/geospatial/Coordinate ParseUtils.java
CET, and a flight plan with the list of one or more control towers to be crossed.
File format: flight code; plane code; departure airport code; destination airport code; departure date dd:mm:yyyy; departure time hh:mm; tower 1; tower 2; … tower n
2. When the application is running, the user should be provided with a simple GUI where they can add new flights (see Figure 2 for an example of what this might look like). When adding a flight, the user should be able to select an airline, add a unique code, select the type of airplane, and the departure and destination, enter the date and time of departure, and select a list of control towers to be crossed. The application should display the average distance and time travelled, the average fuel consumption in addition to the estimated CO2 emission. We consider a fixed speed and direct line between control towers. The appendix shows sample pseudo code on how to calculate the distance between two GPS locations.
3. Before the application exits, it should generate a report with the number of flights per company and the total number of kilometres travelled by its flights. The report should also include the average total fuel consumption, and the estimated CO2 emission. The report should be written to a text file.
Figure 2. Sample GUI for stage 1 (colours are not required)
When editing the flight plan, we consider that there is a maximum number of towers that can be crossed (for example, 20). The user can be given a table that they can fill in by selecting the successive towers from a drop-down list. You can add extra functionalities to your GUI, such as sorting flights by different criteria, searching a flight etc.
Non-functional requirements
These are the software engineering requirements for Stage 1:
1. Your application should be implemented using Java.
2. Develop your program using planned iterative development. In this stage you
should do all the design before writing the code. Decide on all the classes for this stage, their instance attributes, and methods. Try using a design method and diagrams where appropriate. Make a plan to divide the work between you, in such a way each person can work independently where possible. How will you test your code? Decide when and how often you need to meet or be in contact. How will you integrate your work?
3. Base all your decisions just on the requirements for this stage. Do not use agile development at this stage, and do not plan ahead to Stage 2. However, do take notes about the development process and your experiences, since you will be asked to summarise this in your report.
4. Your program should read the data from the files at the start and store it into appropriate data structures. When reading the files, you do not need to think ahead to the GUI or reports; just store the data so that it can be accessed easily (e.g. is a list suitable? would a map be useful?). Then, write methods to analyse the data, which is likely to involve using more data structures. When making your decisions, imagine that you have many flights, with variable number of control towers that can be crossed.
5. Use version control. Your group should set up a repository, and a link to this repository should be included in your report. Note that we will check the commit history, so make sure this reflects your individual contributions.
6. Use exceptions to catch errors in the data. Each group should decide what makes valid data (e.g., length, range, number of characters, etc.) If an error is found, just continue without that line of data. Provide suitable data to check that your program is working correctly, e.g. input files with some errors.
7. You should throw exceptions in the constructor of at least one class, to ensure that the objects of that class that you create are valid (e.g. flight unique identifier), and you should write at least one of your own exception classes.
8. Use JUnit to test some of your constructors and/or methods, particularly ones involving calculations, e.g. the method that estimates the CO2 emission from the travelled distance. You could try test-driven development for these methods. If you create a JUnit test for a method, you should test all the paths in the method, not just one.
Development Plan
One person in the group should submit this document, which gives details of your class diagram, chosen data structures and work plan, before you start coding. This should be done by 3:30pm Friday in Week 5. Submission is mandatory and your group will be penalised if it is not submitted on time. This document should be a maximum of 3 pages in length.
Group Report
The report will consist of several sections:
Names of group members and a summary (no more than one page) explaining who did which parts of the application and which parts of the report.
A link to your repository.
Does your program meet the specification, or are there some bits missing or bugs outstanding? Either provide a single sentence “This program meets the specification” or provide details of problems that you know about.
Suitable UML class diagram(s) showing the associations between the classes, and the contents of each class.
Explain which data structures you used, which classes they are used in, and why you chose them. (Some tools for creating UML diagrams hide the data structure of associated classes. Ensure the reader knows what these are.)
What decisions has your group made about the functionality of the program? (This is just information, not a technical report). Include the format of any identifiers and details about how discounts are applied.
Testing: What did you test using JUnit? Give details of which JUnit tests relate to which methods. (No need to print all the code, the marker will look at this electronically). Which types of exception did you use, in which method, and for what purpose?
development plan, group report and application for Stage 1 will be marked according to the following criteria:
keep the writing concise. Your report should be no longer than 12 pages. Your
A (70-100%)
B (60-69%)
C (50-59%)
D (40-49%)
E/F (<40%)
Development plan and design decisions
Clear, well thought out, well justified, and submitted by the deadline
Mostly clear, thought out and justified, submitted by the deadline
Some issues with clarity, planning or justification, but submitted by the deadline
Significant issues with planning or justification, or not submitted on time
No real indication of planning or thinking, or not submitted
Functionality
Functional requirements have been met
Some requirements not fully met
A number of requirements are incomplete
Significant limitations in functionality
Very little achieved
Implementation and coding
Good OOP design, clear modular well-commented code, clear class diagrams, a well- designed GUI, appropriate use of version control
Generally good OOP design and coding with readable class diagrams, a functional GUI, appropriate use of version control
Some issues with OOP design or coding, class diagrams lack clarity, a limited GUI, limited use of version control
Significant issues with OOP design and coding, class diagrams poorly presented or absent, GUI incomplete or not working, poor use of version control
Poor OOP design and coding, incomprehensible class diagrams, no GUI, no use of version control
Exception handling and testing
Effective use of exceptions, thorough unit testing and test data
Generally good use of exceptions and unit testing with sensible test data
Some issues with the use of exceptions, unit testing and test data
Significant limitations with exception handling and testing
No useful exception handling and testing
Submission
All reports and code should be submitted through Canvas using the links provided in the Assessment section of the course page. Late submissions will be marked according to the university's late submissions policy, i.e. a 30% deduction if submitted within 5 working days of the deadline and no mark after that. If you have mitigating circumstances, please submit the form available at: https://www.hw.ac.uk/students/studies/examinations/mitigating-
circumstances.htm.
Note that all submissions will be checked for plagiarism. If you use other people’s code, then this should be explicitly indicated.
Stage 2 is designed to assess your ability to use thread-based programming and design patterns, and your understanding of agile development, which are all taught in the second half of the course. In this stage, your application will be extended to simulate flights evolving over time and communicating their information to control towers. This will involve the addition of threads and design patterns, and the development of a suitable GUI to show the state of the simulation.
Core Functional Requirements
These are the core functional requirements for Stage 2.
1. As for Stage 1, the application will read in details of existing flights when it starts up. Then the flights evolve according to a simple law:
distance = speed * duration
The orientation of each flight will be towards the next control tower as defined by its flight plan. The calculated distance should be transformed to a GPS location in the direction of the next control tower.
2. Flights communicate their information at a fixed period (to be chosen by the developer) to the closest control tower.
3. We assume that the GUI cannot communicate directly with the flights. It regularly updates the position of each flight by getting the latest information from the control towers. The travelled distance, time and corresponding fuel consumption and CO2 emission are calculated and displayed in the GUI (see Figure 3 for how the modified GUI might look like).
4. The GUI also displays the list of control towers crossed so far by the flight.
5. When the flight reaches its destination, it will be moved to an arrival state, and its
information should not be updated any more.
6. The simulation stops when the user decides.
7. A log should be kept which records events as they happen, e.g. a flight is added to
the airspace, a control tower starts communicating with a flight, a flight has landed. This log should be written to a file when the application exits.
Figure 3. Example of GUI for stage 2 (layout and display format are to be adapted)
Software Engineering Requirements
These are the software engineering requirements for Stage 2:
1. You should experiment with agile methods. For your initial overall plan, simply decide how many iterations you will have, and which features will be developed in each iteration. Then plan each iteration when you start work on it. Plan, design, develop and test each iteration without considering features in the future iterations. You may need to refactor your code at the end of each iteration, before continuing.
2. Spend some of the time trying out agile techniques such as pair programming, stand- up meetings and time-boxing, and decide whether they are practical for you to use in your project or not. Note down your observations.
3. Use threads and ensure that they are synchronized where necessary and do not interfere with one another (see the learning materials in Part 2 of the course). For the core functional requirements, you should have at least one thread for each flight, and one thread for each control tower. You are encouraged to add more threads to the application when you develop extensions and also consider more advanced scenarios like the producer-consumer model.
In your simulation, the flights and the towers should be threads. You are expected to implement synchronisation between the flights and the towers, as multiple flights can communicate simultaneously with one tower. Flights notify the crossed tower about their new positions. They can do this by storing their information in a queue. The tower processes the information by retrieving it from the queue and storing it. The towers act as mediator between the GUI and the flights. A thread communication mechanism must be implemented to allow the GUI to get flights information from the towers and display it (Figure 4 illustrates the communication between threads).
4. Java provides thread-safe versions of some of its collection classes. However, you should not use these, since this will limit your ability to demonstrate your knowledge of threading.
5. Your design should include design patterns. As a minimum, you should use the Singleton pattern to implement your log class, and the observer and MVC patterns in your GUI (see the learning materials in Part 2 of the course). You are free to use other design patterns.
6. Use packages appropriately.
7. Continue to use version control.
8. The final application should be exported to a JAR file, from which the program can
be run. Resource files (e.g. text files) should be included in the jar file. See the lecture on JAR files for information about how to do this.
Figure 4. Illustration of the communication between threads
Extended Functional Requirements
You are also asked to extend the core requirements. Marks will be awarded based on the complexity of your extension(s) and the knowledge and understanding required to implement them. The following are some suggestions. You are free to come up with your own, though you may want to check with your lecturer before starting work on them:
1. The user can select a control tower, the application shows the flights that are currently crossing its zone (i.e. communicating with it).
2. Similarly, when the user selects an airport, the application displays all on-going flight whose destination is the selected airport.
3. The user could be able to change the flight simulation time and the frequency at which flights communicate their position top towers. Similarly, they can modify the display frequency (the frequency at which the GUI refreshes the flights information).
4. We assume that the flight plan will always be respected. However, students can introduce a change in the plan by altering the sequence of air traffic control towers (e.g. to take into consideration atmospheric conditions such as wind...).
Group Report
The group report for stage 2 should include the following:
1. A brief description of the functionality that your system provides and what it does not do, i.e. does it meet the specification, are there some bits missing or bugs outstanding. How did you extend the core requirements?
2. UML class diagram(s) showing the associations between the classes, and the contents of each class – possibly not both in the one diagram.
3. Details about how you developed your program using agile processes. What features did you include in each iteration? Which agile techniques did your group use?
4. An explanation of how and where threads are used in your application.
5. An explanation of how and where design patterns are used in your application.
6. Sample screen shots.
7. A brief comparison of your development experiences in Stage 1 and Stage 2. Did
plan-driven or agile development work better for your group? What problems did you en