© Computing Science and Mathematics
University of Stirling Page 1 of 11
University of Stirling
Computing Science and Mathematics
CSCU9P6 — Software Engineering II
Group project Spring 2020

For the purpose of this project each of you is required to operate as a member of a team. The
task of the team is to implement a working system in Java satisfying the object oriented design
described later in this document on page 7.
Lists of team members and monitoring officers, this description and project materials are on
Canvas and the Courses file server K:\CSCU9P6
The organization of the work is largely up to each team. However, for each team we will
appoint a project monitoring officer, and the team must meet with this officer at one project
meeting each of two separate weeks. The monitoring officer will attend for up to half an hour
(the group meeting might well continue for longer), and we appreciate that once the
implementation gets properly under way, shorter meetings may be appropriate with the
agreement of the monitoring officer. Attendance at these meetings is compulsory, and
non-attendance may result in No Mark being awarded for the course. You should give your
monitoring officer a brief, informal, progress report at the start of each meeting. Their normal
role will be to observe silently, in the background — they are not there to solve design
problems for you. If you wish to ask your monitoring officer for clarification of the problem,
then they may need to consult “higher authorities” for the expansion of details in the
requirements — a response will be provided as soon as possible, and, if appropriate, will be
disseminated publicly for the attention of all teams.
Sommerville’s and Pressman’s texts on software engineering provide guidance on organizing
teamwork. We recommend that each team appoints one of its members as project manager,
but this is up to you, and that you plan your work schedule using a Gantt chart. We also
recommend that, wherever possible, you think about and define very clearly the interfaces of
each Java class (the public operations offered) and work as individuals on separate classes (or
groups of classes).
Each group has been allocated a communal, shared folder on a Computing Science file server. If
your group number is nn ( 01, 02, etc) then your shared folder is in \\wsv\Groups\P6\nn.
Each member of the group has full access to all files created there; you might like to create a
subfolder per group member as a place to keep work but which is also accessible to other
members of the group if necessary (e.g. in case of illness).
Each group has also been allocated a Subversion repository on our server:
svn://svn.cs.stir.ac.uk/p6-nn where we recommend that you manage your central
versions of your project files. Each member of the group can checkout a copy of the project into
their own file space, or into personal sub-directories of the shared directory, regularly
committing any changes that they make, and synchronizing to fetch updates committed by other
members of the group.
Note: The best way for Eclipse/Together to access a project in the shared folder, is to Map a
Network Drive letter to the shared folder .
Remember: You should never have the same project folder open with Together
or Eclipse on more than one computer simultaneously, and there should be no
need for this! [But several copies separately checked out from Subversion by different
programmers is fine!]
© Computing Science and Mathematics
University of Stirling Page 2 of 11
I recommend that you use the Together project only for reference to the documentation, and
that for development you use the Java already extracted from the Together project, and work in
Eclipse (or an equivalent IDE) for the Java development, with the the most up to date project
files held in the Subversion repository. Please note that the versions of Together and Eclipse in
the labs are not compatible with each other, and you should not open one’s projects with the
other!
While you are working, it will be important to synchronize your work with the repository on a
regular basis, and in particular at the start and end of each session of work.
The Library has a collection of bookable meeting rooms — see http://stir.ac.uk/1wz
Further, you can now book free teaching rooms through the ResourceBooker at
https://resourcebooker.stir.ac.uk/ : log in with your Portal username and
password, choose Book a Teaching Room, and then look at Cottrell Central. Also, remember the
University’s "Empty space = study space" policy: "If you find a teaching room or computing lab
lying empty, you are welcome to make use of it."
Assessment arrangements
Each group will make a joint software development submission, and a single agreed
statement of individual contributions. Each student will submit an individual report.
Group software development submission
Each group will produce the following assessable output:
1. The final Java files, emailed as one Zip file to [email protected] named
Group-nn-Java.zip
2. You are not required to make any substantial alterations to the design/architecture of
the system. However, if you do, then you should submit a brief but clear description of
the alterations and the rationale for them, with relevant parts of the new class diagram.
3. Hard-copy documentation of the JUnit testing that you would carry out to demonstrate
the correctness of an implementation of the GateInfoDatabase class — for
simplicity assume that the classes that it depends on are themselves all correct and so
may be used in the testing. The documentation must include the full code of the JUnit
tests, and a description of the rationale for the test cases chosen (well written
comments in the JUnit test code would be fine). You should also provide print-outs of
the results of applying the unit testing.
Of course, you should not restrict your own testing to just these cases! In the
demonstration later on, all use cases will be exercised.
4. A demonstration by the group of the working system.
Each group should hand in to the labelled box outside 4B89, or directly to Dr Jones, one
hard-copy of items 2 and 3 described above, on or before 17.00 on 27 March 2020. The cover
of the document should clearly identify the number of the group, but should not give the
names of the members.
The demonstrations will be arranged in due course.
Statement of individual contributions
This section is subject to change, pending the outcome of the Doodle poll.
When assessing group projects, care is taken to ensure that the marks awarded fairly reflect
individual contribution and effort. The marks awarded for this assignment will take into account
© Computing Science and Mathematics
University of Stirling Page 3 of 11
the individual reports, the individual contributions and effort as well as the group results. The
individual contributions will be used to give each student an adjusted mark based on the group
software development submission mark.
The group must submit one printed copy of the table provided attached to this document
(page 4), completed to show the relative contribution of each team member: Please distribute
100 points between the group members according to what the group agrees their contribution
to have been. Please double check that the sum of the row is 100.
Note that each member of the group must sign the form to indicate that it has been
discussed and agreed.
The group must attach to the form a brief statement listing the contributions of each
member. For this purpose the group will need to keep a record of who does what.
The statement of individual contributions should be posted into the assignment box by the
same deadline as the group submission, 17.00 on 27 March 2020.
Individual report
In addition, each individual group member must submit a short report (maximum two sides of
A4) discussing the management of the project:
• Describing how their group organized its collaborative work, with reference to the project
management topics studied in CSCU9P5,
• assessing how effectively the group worked towards achieving its goals,
• and discussing, with hindsight, whether and how the collaborative work organization
could have been different to give a better outcome or, if you think that no improvement
was possible, then why the particular organization was so effective.
Note: This short reflective report will be assessed on the quality of the analysis, discussion, and
writing, rather than than on whether an “approved” and effective organization was adopted.
The individual report must be submitted via Turnitin on Canvas by the same deadline as the
group submission, 17.00 on 27 March 20209. The report should have a title page giving the
module code, the title of the assignment “Group project individual report", your group
number and student number, but not your name. Pay attention to the layout and clarity of
your work.
Independent work as regards the individual report
Work which is submitted for assessment must be your own work. All students should note
that the University has a formal policy on plagiarism which can be found at
http://stir.ac.uk/1x0

© Computing Science and Mathematics
University of Stirling Page 4 of 11

Late submission
The standard University procedures dealing with non-submission and with late submission
apply. Assessed coursework submitted late will be accepted up to seven days after the
submission date (or expiry of any agreed extension) but the mark will be lowered by three
marks per day or part thereof. After seven days the piece of work will be deemed a
non-submission, and will result in the award of No Mark. This rule may be relaxed for students
who can show good cause for failure to submit. Good cause may include illness (for which a
medical certificate or other evidence will be required).
Assignment assessment
Although this is a group project, you will be given an individual mark for this assignment based
upon the following 3 factors:
1. The Group Submission
2. The Individual Contributions Form
3. The Individual Report
This assignment is worth 35% of the overall mark for CSCU9P6.
The Group Submission mark adjusted according to the Individual Contributions will account for
80% of your mark.
The Individual Report provides the remaining 20% of your mark.

© Computing Science and Mathematics
University of Stirling Page 5 of 11
Group number:
CSCU9P6 Group project Spring 2020
Individual Contributions
Please quantify the contribution that each member of your team has given to the group
work. Write the names of the members of the group in the first row below. Then, distribute
100 points between them, according to what the group agrees the contribution of each
member was to the development of the project.
For instance, in a four person group, if all the members have contributed equally, then each
member will receive 25.
Ensure that
1. the group number is include in the box above,
2. the names and contributions of your group members are given in the table below,
3. each member signs the form where indicated,
4. a brief statement of the contributions of each member is attached.

Contribution
Member 1 Member 2 Member 3 Member 4 Member 5
Name
Distribute 100
points



Signatures
1.

2.

3.

4.

5.


© Computing Science and Mathematics
University of Stirling Page 6 of 11
(This page deliberately left blank)


© Computing Science and Mathematics
University of Stirling Page 7 of 11
SAAMS project specification
Introduction
In this assignment you will be implementing an information system for the management of
aircraft during their arrival, unloading, loading and departure from Stirling Airport: the Stirling
Airport Aircraft Management System, SAAMS. Note that SAAMS is a support system for the
people associated with the airport and aircraft: it provides information for the staff, passengers
and non-travelling public about the status of aircraft, and regulates the progress of the aircraft
through the various stages of its visit. SAAMS does not directly control the aircraft, nor any
physical systems — though it does have a minimal interface with each visiting aircraft’s
on-board computer for the automatic transfer of flight details. SAAMS’ principal interfaces with
the real world are through screens, most of which are touch sensitive or are equipped with a
mouse and keyboard: airport staff view information, receive instructions, and enter status
updates and other information via the screens. All “real actions” are carried out by “real
people”; in particular, all actions “required of an aircraft”, such as taxiing to a certain passenger
gate to unload passengers, are notified to the aircraft’s crew by airport staff via radio.
Fortunately, Stirling Airport has a perfect, but simple existence: there is no freight nor baggage
to worry about, aircraft never break down seriously (and never while taxiing/landing/taking
off), there is no in-flight catering, there are no “transit” passengers, passengers “check in” only
at the departure gate (like a bus), all aircraft arrive with a pre-planned and immutable onward
flight plan, the airport never closes, and SAAMS never crashes and is not started and stopped
(and so does not have to preserve its state between runs) — and there are probably all manner
of other gross simplifications, but never mind.
The system is to be implemented on a computer system with the various interface devices
distributed around the airport, and connected via special purpose networking. Of course, this is
just an exercise, so the devices will be “only a simulation” and all the interface devices will
appear as separate windows on a single PC screen — but this is actually very close to a real
implementation where the separate windows actually appear on separate PCs (or maybe
simpler devices) distributed around the airport.
You will be provided with a Together design model at an intermediate/late stage in the design
process: use cases, a class diagram, a large state diagram encoding the “life line” of each
aircraft as it visits the airport (that is, the states that instances of the ManagementRecord
class held by SAAMS pass through), a small state diagram encoding the lifecycle of each
passenger gate, and some sequence diagrams.
• The Together model can be found in K:\CSCU9P6\GroupProject\SAAMS. You should
copy this folder to your group working folder. Remove the Read-only attributes.
To make use of this model, you should launch Together, switch to the Modelling perspective
and use File menu / Import. In the Import dialogue box choose “Existing projects into
workspace” and then Next. Click Browse to Select root directory, and browse to locate your
copied SAAMS folder. Then click Finish. This folder also contains the outline Java code
generated by Together, plus a skeleton Main class in Main.java.
It is probably best if individuals take private copies for initial exploration of the project
contents.
• More information/suggestions are given in the SAAMSREADME.txt file — read it.
© Computing Science and Mathematics
University of Stirling Page 8 of 11
• Remember to survey the Descriptions in the Properties Pane when you click on use cases,
classes, methods, attributes... A lot of information/design decisions are described there. A
good way to view the Descriptions is to select the Description line in the Properties pane
and then click on the "..." that appears in the selected line — a separate window with the
description will pop up.
• You need to decide on an architectural framework for the application. MVC was in the
designer’s mind, so that is recommended — look carefully at the stereotype annotations on
the classes (e.g.<> on the class diagram).
[Caveat: It is sometimes more trouble than it’s worth splitting boundary classes into
separate controller and view classes — this is the case when part of the “view” is used for
the input of a “control” action, such as when the user can choose from a list of displayed
items. However, the MVC scheme can still be followed. You will see that the boundary
classes have the stereotype <> to hint at this!]
• You will need to check on, and refine, the implementations that Together has implemented
for the associations.
• You may need to introduce new classes — but not necessarily. You may decide to split
some classes up/merge classes. However, probably no significant changes to the class
structure will be required, and none are expected.
• Other refinements of the object model will certainly be necessary: in particular new
attributes and methods.
• Whatever changes you make, make sure that they are rational revisions of the structure
that you have been given, and not arbitrary replacements of large chunks of design.
• Various resources are available to help with the low level design and implementation:
o On-line documentation of the Java class libraries, eg at URL
https://docs.oracle.com/javase/8/docs/api/
o The MVC example (from practicals) in K:\CSCU9P6\Practicals
o A demonstration of how a Java Swing JList of selectable items could be used to
implement an interactive graphical user interface in
K:\CSCU9P6\Using-JList-example (“select an item from a displayed list,
then click a button to take an action”)
• The actual user interfaces do not need to be beautiful, nor too clever — just lists, buttons
and text fields/areas, will be fine.
• You should not use threads or concurrency.
The “life line” of visiting aircraft
The key to understanding what SAAMS is all about is an understanding of how an individual
aircraft’s visit to Stirling Airport is managed. Of course, SAAMS must be able to handle a
number of aircraft at once, and not just one! Here is the story of an aircraft A’s visit, to be read
in conjunction with the ManagementRecord (abbrev. MR) state diagram and Gate state
diagram:
© Computing Science and Mathematics
University of Stirling Page 9 of 11
1. A enters Stirling Airport’s local airspace, is noticed by the radar/transceiver system, has
its flight descriptor downloaded from the on-board computer into SAAMS automatically
(a free MR is configured), and is assigned either the state “in transit” (if it doesn’t want
to land at Stirling), or “wanting to land”. A then appears on the Local Air Traffic
Controller’s (LATC’s) screen, with its status shown, and also on the Ground Operations
Controller’s (GOC’s) screen if it wants to land. [Note: In this exercise the radar and flight
descriptor download (and, later on, upload) will have to be a screen interface through
which we can enter events and data, although in the real system they would be
automatic devices, albeit with equivalent interfaces to SAAMS.]
2. If A is simply in transit, then at some later point the radar notifies that it has lost contact
with A, and A’s MR is cleared, that is becomes free again (in a future extension perhaps
it could be archived, but that is not required here).
3. The GOC starts the permission to land sequence by verifying the availability of space on
the ground (from other information displayed on the GOC screen, a glance out the
window, etc). Once this is done A’s status is changed to “ground clearance granted”.
This is seen by the LATC on the LATC screen, and when the LATC decides that the
air-space is clear and that A is clear to approach and land, the LATC radios this to the
pilot and changes A’s status to “landing”, and later to “landed” when A is safely on the
ground (a binocular check out of the window?). A may disappear from the LATC screen
at this point (because it is no longer in or needing airspace), but remains on the GOC
screen until it has finally departed again.
4. A must wait on the tarmac for notification by the GOC (by radio) of which gate to taxi
to. The gate must have been “free”, and becomes “reserved” for A by the GOC. A enters
“taxiing” status, and should appear on a console display at the gate. [Note: NONE of
these decisions is taken by SAAMS — it simply provides information to the human
operators, who make decisions and enter changes.]
5. When A arrives at the gate, the gate staff press a button to indicate that it has
“docked”, and A’s status changes to “unloading” (and the gate becomes “occupied”).
When all the passengers have disembarked, gate staff press a button to indicate that
unloading is complete, and A’s status changes to “clean and maintain” (for cleaning and
a routine maintenance check — no bird damage to the engines, tyres OK, etc).
6. At this point, A will appear on the Cleaning Supervisor’s screen, and the Maintenance
Inspector’s screen, requesting them to send teams. When the cleaning and
maintenance checks are finished, the Cleaning Supervisor and the Maintenance
Inspector update A’s status via their screens. Cleaning is always successful, but the
maintenance check may reveal faults. If so, the aircraft must await repairs and is then
re-cleaned (in case the repairs made a mess) and re-checked (just to be sure). A variety
of states capture this process, the principal ones being “awaiting repair” (whose
successor is “clean and maintain” again) and “ready for refuelling” (which is only
sensible once A has a clean bill of health). While A is “awaiting repair”, its MR will
contain a (short) text description of the problem — this is entered by the Maintenance
Supervisor when indicating that the maintenance check failed.
7. When A enters enters the “ready for refuelling” state it appears on the Refuelling
Supervisor’s screen requesting a fuel tanker to be sent to the gate. The fuel tanker
operator informs the Refuelling Supervisor when refuelling is complete and the
Refuelling Supervisor updates A’s status. A enters the state “ready for passenger
boarding”, which is displayed on the gate console.
© Computing Science and Mathematics
University of Stirling Page 10 of 11
8. A then accepts passengers on board while it is not full: each passenger enters details (at
least name), which are recorded in A’s MR. When boarding is complete, or the gate staff
decide that no more passengers are presenting themselves, the gate staff “close the
flight” by pressing a button on the gate console. The passenger list is uploaded from A’s
MR to A’s on-board computer by the radar/transceiver system, and A becomes “ready
to depart”.
9. Since A is now “ready to depart” it now appears once again on the LATC screen
requesting a departure air slot. When the LATC is able to allocate a slot (determined
from national air traffic control information, not dealt with by SAAMS), the LATC
updates A’s status to “waiting to taxi”, and A’s presence on the GOC screen indicates
that it is requesting permission to taxi across the tarmac.
10. When there is space on the tarmac for taxiing, the GOC grants taxiing permission, A’s
status is updated to “waiting for permission to take off” (during which it taxis to the
runway). Take-off permission is granted by the LATC once the local airspace is clear, and
A’s status changes to “departing through local airspace”. The radar eventually detects
that A has left the local airspace and A’s MR is cleared, that is becomes free again (in a
future extension perhaps it could be archived, but that is not required here).
About the interfaces
The “life line” description above gives a lot of information about the information displayed on,
and about the interactions via, each interface screen.
SAAMS has the following seven “real” interfaces:
• The LATC screen shows all aircraft “in transit” through local airspace, “wanting to land”,
“ground clearance granted”, “landing”, “ready to depart”, “waiting to taxi”, “waiting for
permission to take off”, and “departing through local airspace”. The LATC can only alter the
status of aircraft with “ground clearance granted”, “landing”, “ready to depart” and
“waiting for permission to take off” — these aircraft should be selectable on the screen,
with the means to action the relevant changes of status. In the other states, the aircraft are
visible on the screen for information and for continuity while the LATC has any concern
about them, and it should not be possible for the LATC to change their status. A suitable
display will be one or more textual lists (see the ListInterface demo), with buttons
for actions. Dynamic switching of views is not necessary — and probably not appropriate
for a high pressure activity like ATC. The LATC screen should also have an area where the
flight details (flight code, origin, destination, number of passengers, etc) can be displayed
on request (select an aircraft, and click a button). (Again, see the List interface demo.)
• The GOC screen is similar in principle to the LATC screen (details can be deduced from the
“life line”). In addition the GOC will need to see the status of each passenger gate in the
airport.
• The Cleaning Supervisor’s, Maintenance Inspector’s, and Refuelling Supervisor’s screens are
all rather similar: they show aircraft currently needing the appropriate attention (with gate
location), and allow indication of completion of the relevant activity. The maintenance
screen is fractionally more complex as aircraft may also be “awaiting repair”, and a textual
description of the required repair must be entered as an aircraft enters this state.
• The gate consoles have a simple display for information about the approaching or docked
aircraft and any relevant flight details (flight code, destination, number of passengers, etc),
with control buttons for various status changes (see the “life line”).
© Computing Science and Mathematics
University of Stirling Page 11 of 11
• There may be many information screens in public areas of the airport. They accept no input
(although they may be scrollable text), and simply display brief status information about
(some of) the aircraft currently managed by SAAMS (e.g. they might not show aircraft while
being cleaned or repaired, and they might not distinguish between all states: for example
“wanting to land”, “ground clearance granted”, and “landing” could be abstracted into
“landing”).
In the demonstrated system it will be sufficient to provide one LATC screen, one GOC screen,
one Cleaning Supervisor’s screen, one Maintenance Inspector’s screen, one Refuelling
Supervisor’s screen, three gate consoles, and two public information screens (although it
should be easy, in principle, to have more of any of these if required).
In addition to these “real” interfaces, there is one simulated device required: the
radar/transceiver. This can be implemented as a screen with:
1. The means to provide flight descriptor information for an arriving aircraft, with a button
to click for the state transition “enters local airspace and downloads flight descriptor”
(step 1. of the lifeline), which causes the data to be sent to the aircraft management
database,
2. the means to display an uploaded passenger list, and
3. a list of selectable aircraft currently either “in transit” or “departing through
localairspace” with another button for the state transition “leaves local airspace” (in
practice the radar would track all relevant aircraft automatically and report their
departure via a “virtual click”!).

Good luck!

Simon Jones 18/02/2020