F21AS COURSEWORK: STAGE 1
2
Stage 1
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 simple airport check-in
system. This first stage develops the basic functionality, which you will then extend in Stage 2.
Functional Requirements
For stage 1, your application will load in details of existing passenger bookings, show a simple
check-in interface, and generate a summary report.
1. At the start of the application, all passengers have bought a ticket. A text file should be
provided which gives the list of all bookings, containing, for each passenger, details of the
unique booking reference code, the name of the passenger, their flight code, and whether
they have checked in or not.
2. Another text file should be provided that shows the details of each flight, including the
destination airport, the carrier, and the capacity of the flight tgiving the maximum number
of passengers, the maximum baggage weight, and the maximum baggage volume).
3. These text files are read at the start of the application, and you can assume that they are
correctly formatted e.g. the right number of commas in a csv file. You should check that the
booking reference code is correct according to your rules.
4. Passengers will need to check in when they reach the airport. To provide a facility for this,
after the list of bookings has been loaded, your application should display a simple GUI
representing an electronic check-in kiosk.
5. In addition to allowing the passenger to enter their last name and booking reference, this
GUI should ask for the dimensions and weight of the passenger’s baggage and indicate any
excess baggage fee that needs to be paid. Your group should come up with their own rules
for this. You can assume that each customer has only a single piece of baggage.
6. The last name and booking reference which are entered into the GUI should be checked
against the entries on the flight booking list. If the details do not correspond, the passenger
cannot be checked in, and will have to re-enter their details.
7. When the application exits, it should generate a report. This should indicate, for each flight,
the number of passengers checked-in, the total weight of their baggage, the total volume of
their baggage, and the total excess baggage fees collected. It should also indicate whether
the capacity of the flight is exceeded in any way.
Software Engineering 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
variables and methods. Try using CRC cards to help with class design, and use other diagrams
where appropriate. Make a plan to divide the work between you, in such a way each person
F21AS COURSEWORK: STAGE 1

3
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, and may be asked to discuss it in the examination.
4. Your program should read the data from the files at the start, and store it into appropriate
data structures. When reading the files, don’t 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 a large number of
passengers and flights.
5. Use version control. Your group should set up a repository, a link to this repository should
be included in your report, and your lecturer(s) should be given access. 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. booking reference codes), 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. to test methods in a Baggage class which includes checks for weights and
dimension limits. 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 submitted by
3:30pm on Thursday 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:
1. 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.
2. A link to your repository.
3. 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.
F21AS COURSEWORK: STAGE 1

4
4. Suitable UML class diagram(s) showing the associations between the classes, and the
contents of each class.
5. 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.)
6. What decisions has your group made about the functionality of the program? (This is just
information, not a technical report). Include the format of the booking reference codes and
details about how excess baggage fees are calculated.
7. 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?
Try to keep the writing concise. Your report should be no longer than 12 pages. Your
development plan, group report and application for Stage 1 will be marked according to the
following criteria:

Submission
All reports and code should be submitted through Canvas using the links provided in the
Assignments section of the course. 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 are using code that was not
written by one of your group members, including code generated by a large language model
such as ChatGPT, then this must clearly be indicated, making clear which parts were not written
by you and clearly stating where it came from. See university guidance on academic misconduct.
Criteria Weight A (70-100%) B (60-69%) C (50-59%) D (40-49%) E/F (<40%)
Development
plan and design
decisions
25% 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 30% 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
25% Good OOP
design, clear
modular well-
commented
code, clear class
diagrams,
appropriate use
of version control
Generally good
OOP design and
coding with
readable class
diagrams,
appropriate use
of version control
Some issues with
OOP design or
coding, class
diagrams lack
clarity, limited
use of version
control
Significant issues
with OOP design
and coding, class
diagrams poorly
presented or
absent, poor use
of version control
Poor OOP design
and coding,
incomprehensible
class diagrams,
no use of versionl
control
Exception
handling and
testing
20% 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
F21AS COURSEWORK: STAGE 2
5
Stage 2
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 passengers queuing at check-in desks
and being assigned to waiting planes. 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. Also see the extended requirements section below.
1. The simulation consists of multiple check-in desks, a single queue of passengers, and a group of
flights waiting to depart. When passengers arrive at the airport, they join the back of the queue.
When they reach the front of the queue, they will be processed by the next available check-in
desk, and then assigned to the appropriate flight.
2. As for Stage 1, the application will read in details of passengers and flights when it starts up.
Your application should simulate the arrival of passengers at the airport. This can be done by
randomly selecting passengers who have not yet checked in. Each passenger has up to one
piece of baggage, and the dimensions and weight of the baggage can be chosen randomly when
the customer joins the queue.
3. After a certain period of time has elapsed, the check-in desks close and the planes depart. Any
passengers remaining in the queue will not be able to board their flights.
4. The GUI should show the list of passengers waiting in the queue, details of what each check-in
desk is currently doing (e.g. processing a particular passenger, charging for excess baggage),
and the status of each flight (e.g. number of passengers checked-in, weight of baggage etc.)
throughout the simulation. One possible example is shown below. Make the timing slow
enough that you can watch the displays changing. There’s no need to keep the check-in GUI
from Stage 1.
5. A log should be kept which records events as they happen, e.g. passengers joining the queue,
passengers checking in, passengers boarding flights. This log should be written to a file when
the application exits.

Software Engineering Requirements
These are the software engineering requirements for Stage 2:
F21AS COURSEWORK: STAGE 2
6
1. Experiment with agile methods. For your initial 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.
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. For the core functional requirements, you should have one thread for each of the
check-in desks, and one thread to add passengers to the queue. 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.
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.
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. Allow the user to alter the speed of simulation using runtime controls.
2. Allow the user to open or close individual desks as the simulation proceeds, or the simulation
could automatically open new desks (up to a limit) when the queue gets to a certain length.
3. Your simulation could have more than one queue, with each queue feeding passengers to more
than one check-in desk. You could limit the size of queues. You might introduce different cabin
classes (e.g. economy, business) and have queues with different priorities for these.
4. Rather than the check-in desks closing at a particular time, each flight could have a specified
departure time, and check-in desks will only accept passengers who arrive before their flight
departs. You could show flights departing by removing them from the GUI.
5. If you’re feeling even more ambitious, you could simulate more details of the airport
experience, e.g. queuing for security. However, bear in mind that a small number of good
quality extensions are better than lots of rushed extensions.
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 and tools did your group use?
F21AS COURSEWORK: STAGE 2
7
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 encounter, and what
might you do differently next time?
The technical sections of your report should be written for someone who has studied the material
on this course but is not familiar with the coursework. You should include diagrams (including UML
diagrams where appropriate) and snippets of code where relevant. Try to keep the writing concise.
Your report should be no longer than 15 pages. Your group report and application for Stage 2 will
be marked according to the following assessment criteria:

Submission
See instructions for Stage 1 submission.
Criteria Weight A (70-100%) B (60-69%) C (50-59%) D (40-49%) E/F (<40%)
Design
(including use of
threads and
patterns)
30% Well designed
with appropriate
use of design
patterns and
ambitious use of
threads
A generally good
design with
appropriate use
of design
patterns and
threads
A reasonable
design, but
limited or
incomplete use
of threads or
patterns
Significant
design issues,
limited use of
threads or
patterns
Poor design,
little indication
that threads and
patterns were
understood
and/or used
Functionality
(including core
requirements,
extensions, user
interface, and
demo)
30% Core
requirements
complete, an
effective user
interface, one or
more complex
extensions, all
features working
in application
Core
requirements
complete, a
usable interface,
one or more non-
trivial
extensions, a
generally
working
application
Some missing
requirements, or
limited
extensions, or
significant
usability issues,
or significant
features not
working
Limited
functionality
with missing
core
requirements or
no extensions or
major usability
issues, major
issues with the
application
Poor
functionality,
very little
achieved,
application not
working
Implementation
(including code
quality,
readability and
comments)
20% Clear modular
well-commented
code, threads
and patterns
correctly
implemented
Generally good
coding, threads
and patterns
correctly
implemented
Some issues
with coding or
with how
threads and
patterns are
implemented
Significant
issues with
coding or with
how threads and
patterns are
implemented
Poor coding,
poor or absent
thread and
pattern
implementations
Software
documentation
(including
technical
writing, UML
diagrams)
10% Precise, concise
technical writing
and UML
diagrams that
give a clear
presentation of
the developed
software
Generally good
technical writing
with readable
UML diagrams
that gives a
fairly clear
overview of the
developed
software
Technical writing
lacks clarity or
conciseness,
UML diagrams
lack clarity, it is
not clear how
some aspects
work
Significant
issues with
technical
writing, poor or
absent UML
diagrams, it is
unclear how the
software works
Poor writing,
incomprehensible
UML diagrams,
it is very unclear
how the
software works
Development
report (including
iterations, agile
techniques,
Stage 1/2
comparison)
10% A clear, concise
and complete
report of the
application's
development
and the tools
and techniques
used
An accurate
report of the
application's
development
and the tools
and techniques
that were used
A reasonable
report of the
application's
development,
with some lack
of clarity, details
or conciseness
A poor or limited
report of the
application's
development
Little or no
reporting of the
application's
development