School of ITEE
CSSE2002/7023 — Semester 1, 2020
Assignment 2 (20%)
Due: 22 May XXXXXXXXXX:00
Revision: 1.0.1
Abstract
The goal of this assignment is to implement a set of classes and interfaces1 to be used to create a
simulation of a traffic management system. You will implement precisely the public and protected
items described in the supplied documentation (no extra public/protected members or classes).
Private members may be added at your own discretion.
Language requirements: Java version 13, JUnit 4
Preamble
All work on this assignment is to be your own individual work. As detailed in Lecture 1, code
supplied by course staff (from this semester) is acceptable, but there are no other exceptions. You
are expected to be familiar with “What not to do” from Lecture 1 and https:
www.itee.uq.
edu.au/itee-student-misconduct-including-plagiarism. If you have questions about what
is acceptable, please ask course staff.
Introduction
In this assignment you will finish building a simple simulation of a traffic management system
(TMS). A traffic management system monitors traffic flow in a region and adjusts traffic signals
to optimise traffic flow. A TMS uses different types of sensors and signals to monitor and manage
traffic flow. In the first assignment you implemented the core model for the TMS. In the second
assignment you will implement some of the more advanced logic to provide a very simple simulation
for the TMS.
In addition to the pressure pads and speed cameras from assignment one, you willl add a vehicle
count sensor. It counts vehicles passing a location and reports the traffic flow as the number of
vehicles in a time period. You need to integrate this new type of sensor into the system. This is
an example of a common situation when building a large system. New features need to be added
to the system. A well designed system that uses interfaces to define an API means it should be
simple to add the new feature.
In assignment one, you implemented traffic lights and electronic speed signs and attached them
to a route. In assignment two you will provide logic to coordinate traffic lights at intersections.
The TMS monitors sensors along routes and manages signals on routes, and at intersections,
to optimise traffic flow. In assignment one, the network of routes was implicitly defined by you
test code and SimpleDisplay. In assignment two you will implement the logic for the TMS to
maintain a network of routes. This includes the ability to load a network from a data file and save
a modified network to a file.
Monitoring and managing congestion requires sophisticated logic in a real TMS. In assignment
one congestion was simply reported by each sensor. In assignment two you will implement logic
for congestion calculators. These take the congestion data from a set of sensors and determine
overall congestion for the route(s) covered by the sensors. The approach taken is to define a
1From now on, classes and interfaces will be shortened to simply “classes”
1
https:
www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism
https:
www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism
CongestionCalculator interface that provides an API. Different classes can implement this inter-
face to provide different options for the logic of determining congestion. This is another example
of a common approach to designing flexibility into the system’s structure.
When implementing the assignment you need to remember that it is implementing a simulation
of the TMS and not the real TMS. Interfaces are provided for the sensors to allow easy replacement
of sensor implementations in the program. You will not be collecting data from real sensors but
will be implementing classes that demonstrate the behaviour of sensors. They store a set of data
values that are used to simulate the sensors returning different values over time. Signals are simple
simulations of real signals, in that they only store the cu
ent state of the signal and allow the
oute to update the signal.
To manage simulation of time, there is a TimedItem interface and a TimedItemManager class,
which you implemented in assignment one. Sensors implement the TimedItem interface, as they
are items which need to react to timed events. TimedItemManager stores all the TimedItem ob-
jects in the application. The simulation’s GUI tracks time passing in MainView.run() and it
invokes MainViewModel.tick() once per second. The tick method calls the TimedItemManager’s
oneSecond method, which sends the oneSecond message to all TimedItems. This approach of
tracking the passage of time and invoking an action on all relevant objects once per second was
the reason that TimedItemManager is implemented as a singleton2.
A simple GUI has been provided to you as part of the provided code. It is in the tms.display
package. It will not work until you have implemented the other parts of the assignment that it uses.
The GUI has been implemented using JavaFX and consists of three classes and an enum. MainView
creates the main window for the TMS GUI. StructureView displays the structure of the traffic
network. MainViewModel represents the TMS model that is to be displayed. The TMS application
is initialised and started by the Launcher class in the tms package. It loads the traffic network
data and creates the GUI. Most of the GUI code has been provided to you. In MainViewModel you
need to implement some of the logic that is executed by events in the simulation and to handle
keyboard input for the main application’s window.
The functionality you need to implement in MainViewModel is to:
• Save the state of the network to a file in response to the user selecting the save command.
This is to be implemented in MainViewModel.save().
• Allow the simulation’s execution to be paused and unpaused. This is to be implemented in
MainViewModel.togglePaused().
• Process time passing in the simulation. This is to be implemented in MainViewModel.tick().
Keyboard input is handled by the accept method in the MainViewModel class. It needs to
process input from the user in the main window to perform actions in the simulation. Pressing the
‘P’ key will toggle whether the simulation is paused or not. The ‘Q’ key will quit the simulation.
The ‘S’ key will save the cu
ent network to a file called “DefaultSave.txt”. A shell for this method
has been provided because it is already hooked into the GUI.
Persistent Data
You need to implement loading a network from a data file. The JavaDoc for the loadNetwork
method in the NetworkInitialiser class describes the format of a network data file. Saving a
network is done by the save method in the MainViewModel class. A network data file is structured
as follows:
• The first line is the number of intersections (ni) in the file.
• The second line is the number of routes in the file.
• The third line is the duration of a yellow light.
2https:
efactoring.guru/design-patterns/singleton provides a reasonably detailed description of the sin-
gleton pattern.
2
https:
openjfx.io
https:
efactoring.guru/design-patterns/singleton
• The following ni lines are the intersection details.
– The first part of an intersection line is its id.
– This is optionally followed by a ‘:’, a duration, another ‘:’, and a sequence of intersection
ids which are separated by commas.
• The final set of lines are the route details, including any sensors on the routes.
– Each route is on a separate line. The sensors for a route are on the lines immediately
after the line for the route.
– A route is described by the id of the from intersection, followed by a ‘:’, then the id of
the to intersection, followed by a ‘:’, then the default speed for the route, followed by a
‘:’, then the number of sensors on the route, then optionally a ‘:’ and the speed of the
electronic speed sign on the route if it has one.
– If the route has any sensors, each sensor follows on separate lines.
– The first part of a sensor line is its type ‘PP’, ‘SC’ or ‘VC’. This is followed by a ‘:’,
then its threshold value, a ‘:’, and then a comma separated list of the data values used
to simulate the data returned by the sensor.
• Any line that starts with a semi-colon ‘;’ is a comment and is to be ignored when reading
the data from the file.
• Attempting to read an invalid network data file should throw an InvalidNetworkException.
An example data file, called demo.txt, is provided in your repository in the networks directory.
It co
esponds to the diagram below.
Supplied Material
• This task sheet.
• An example network data file.
• Code specification document (Javadoc).3
• A Subversion repositiory for submitting your assignment called ass2.4
• A simple graphical user interface for the simulation, which is in the display package.
• A sample solution for the first assignment. You are to use this as the base for your imple-
mentation of the second assignment. As the first step in the assignment you should create a
new project by checking out the ass2 repository from Subversion.
3Detailed in the Javadoc section
4Detailed in the Submission section
3
Javadoc
Code specifications are an important tool for developing code in collaboration with other people.
Although assignments in this course are individual, they still aim to prepare you for writing code
to a strict specification by providing a specification document (in Java, this is called Javadoc). You
will need to implement the specification precisely as it is described in the specification document.
The Javadoc can be viewed in either of the two following ways:
1. Open https:
csse2002.uqcloud.net/assignment/2/ in your web
owser. Note that this
will only be the most recent version of the Javadoc.
2. Navigate to the relevant assignments folder under Assessment on Blackboard and you will
e able to download the Javadoc .zip file containing html documentation. Unzip the bundle
somewhere, and open docs/index.html with your web
owser.
Tags in the Javadoc indicate what code has been implemented in assignment one and what code
you need to implement in assignment two. Some code from assignment one will need to be modified.
There are tags indicating places where you can expect to modify the assignment one code but these
are not guaranteed to be all of the places where you may end up modifying code from assignment
one.
Tasks
1. Implement the classes and methods described in the Javadoc as being requried for assignment
two.
2. Implement the indicated features of the user interface.
3. Write JUnit 4 tests for all the methods in the following classes:
• AveragingCongestionCalculator (in a class called AveragingCongestionCalculatorTest)
• IntersectionLights (in a class called IntersectionLightsTest)
• NetworkInitialiser (in a class called NetworkInitialiserTest)
Marking
The 100 marks available for the assignment will be divided as follows:
Symbol Marks Marked Description
F 45 Electronically Functionality according to the specification
R 35 Course staff Code review ( Style and Design )
J 20 Electronically Whether JUnit tests identify and distinguish between co
ect and
inco
ect implementations
The overall assignment mark will be A2 = F + R + J with the