Project 2 Traffic Simulation

This assignment requires you to create a complete Java program consisting of multiple source
code files. We are providing much of the actual code. You must electronically submit your
source files by the due dates listed according to your section.
You must electronically submit your source files by the due date. Directions for using submit
are at the end of this page.
Anyone who has waited to pay a toll at the New Jersey Turnpike or the Tappan Zee Bridge
understands that traffic flow through toll gates is impacted by the amount of traffic and the
number and kind of open toll booths. For this assignment, you must simulate traffic at a toll
plaza. The input to the simulation will be the number of toll booths in the plaza and the
amount of traffic on the highway. Your simulation must estimate the average amount of time
vehicles wait in line and the average amount of time they require to pay the toll.
The problem domain
This simulation for this problem models a toll booth plaza with 3 to 9 toll booths. There are 3
kinds of vehicles: cars, cars with EZ-Pass cards, and trucks. The lane a vehicle chooses
depends on the kind of vehicle:
EZPass cars can enter any lane. They always choose the shortest lane. If two or more
lanes are shortest, then an EZPass car always chooses the lane closest to the left. (The
leftmost lane is reserved for EZPass holders only.)
Cars that are not EZPass holders can enter any lane except the leftmost (EZPass only)
lane. They always choose the shortest lane among the rest. If two or more of the
remaining lanes are shortest, then a car always chooses the one of those that is closest
to the left.
Trucks can enter only truck lanes, which are always at the right of the other lanes. The
number of truck lanes varies according to the number of toll booths. To compute the
number of truck lanes, take 25% of the number of toll booths and round up. For
example, if there are 6, 7, or 8 toll lanes, then the 2 rightmost are truck lanes; if there
are 9 toll lanes, then the 3 rightmost are truck lanes. A truck always choose the shortest
truck lane. If two or more of the truck lanes are shortest, then a truck always chooses
the one that is closest to the left.
Animating a simulation run
The picture below is a snapshot of an animation of a simulation run of 100 vehicles through 4
toll booths. We provide that animation front end for you. The Start button begins the
simulation run; the Quit button terminates program execution.
EZ Pass cars are magenta, cars are red, and trucks are black. (The green dots in the middle
of every other vehicle in a line help in visualizing the animation.) Note the EZPass only lane is
on the left and the truck lane is on the right. There are both cars and trucks in the truck lane.
The progress bar shows that this simulation run is more than half completed.
When the simulation run is completed, the bottom part of the screen shows the simulation
results of average wait-in-line time and average pay time.
Simulation events
Simulations are based on events that contribute to the underlying problem domain. Do not
confuse simulation events with events on graphical user interfaces -- the two concepts are

Your project must follow the stringent design guidelines laid out here. Keep in mind that the
primary purpose of this assignment is to teach you composition. inheritance, polymorphism,
abstract classes, and interfaces.
The major objects in the traffic simulation from the problem domain are the vehicles (cars,
cars with EZPass cards, and trucks), the highway, and the toll booths. Think of the toll booths
as queues, which are lists in which items are processed in the order in which they enter the
list. A toll booth queue is the line of vehicles waiting to pay their tolls. You should also think
of the highway as a queue -- the first vehicles on the highway are the first ones to reach the
toll booth plaza. (That's clearly not the way of ordinary traffic, but we do not care how
vehicles get down the road. It is simple and sufficient to first generate all the vehicles for the
highway, placing them in the highway queue as they are created.)
The other objects that are part of the simulation include a simulator and a log of toll booth
traffic. Ancillary objects are queues and a factory that generates the vehicles to feed the
Vehicle hierarchy
There are 3 kinds of vehicles: cars, cars with EZPass cards, and trucks. They choose their toll
booth lines by different algorithms. But they all can get in line, have a time of arrival, and
have a time to actually pay their tolls. This is a perfect situation to use inheritance. The
design calls for an abstract base class, Vehicle. It has two children, Car and Truck. The
Car class has a child, EZPass.

The child classes, Car and Truck, have two additional data members:
color. A static member used for display. You can pick any colors you want for your
classes (client code can change colors if needed). Static members are underlined in UML
class diagrams.
laneChosen. Index of the toll booth that the vehicle chooses. The value of this
attribute is set when the getInLine method executes. The hash mark in front of
laneChosen of the Car class means that this data member is protected (visible to
the descendants but nowhere else).
There are getters and both of the data members and a setter for color. The class EZPass
inherits all of the members of Car, but it overrides getInLine according to its own
algorithm for deciding which lane to choose.
The getInLine method for each class has a single parameter, which is an array of
TollBooths. In this method, the vehicle enters the back of the line for the toll booth lane it
The queues
A queue is a first-in first-out list, just like a line at a grocery store checkout or at a theater
ticket office. There are two distinct kinds of queues in the simulation design: the highway and
a toll booth line, which correspond to Highway and TollBooth in the design. These two
classes must implement the interface VehiclesInLine, which we provide.
VehicleQueue, which we also provide, maintains all the information on the queue. It has
the minimal required queue behaviors: add a vehicle to the end, remove one from the front,
show the front vehicle without removing it, and tell whether it is empty. Do not change this
class at all. It is a utility class that Highway and TollBooth can use without knowing
how it works!
The UML diagram to the right
shows the relationships among
the queues. Both Highway
and TollBooth have

Highway constructor. Has 2 arguments, the number of vehicles in the simulation and
the array of TollBooths.
size. Returns the number of vehicles still on the highway.
nextVehicle. Shows the next vehicle ready to leave the highway and enter a toll
booth lane.
processNextVehicle. Removes the front vehicle from the highway queue and
sends it a getInLine message.
departTimeNextVehicle. Tells when the vehicle a the front of the
oncomingVehicles queue will depart that queue (and subsequently enter a toll
booth line).
The TollBooth class has 3 data members and 6 methods.
waitingLine. The queue of vehicles in line.
myLog. The departing vehicle logs its information here. (Logging is explained below.
Since a TollBooth has-a Log, the final UML diagram will have an arrow from
TollBooth to Log to indicate the relationship.)
timeWhenAvailable. The time when this toll booth will finally clear out all the
vehicles currently in line.
TollBooth constructor. Has one parameter, which is of type Log. This initializes
size. The number of vehicles in line.
nextVehicle. Shows the front vehicle in line.
processNextVehicle. Removes the front vehicle from the queue, logging its
information in the process.
departTimeNextVehicle. Tells when the vehicle currently at the front of the line
(paying its toll) will finish paying its toll and leave the simulation.
addVehicle. Adds a vehicle to the end of the line, updating the vehicles time to wait
in the process.
The interface VehiclesInLine specifies the behaviors that lines of vehicles must provide
in order to be part of the event calendar. We have created this interface and documented it
for you. You are not allowed to change VehiclesInLine.
Simulation bookkeepers and recorders
The Simulator, EventCalendar, and Log classes control running the simulation and
keeping track of the results. EventCalendar, which we provide for you, determines when
events occur. Log keeps count of the statistics -- how long it took vehicles to pay their tolls
and how long they waited in line prior to paying. Simulator runs the simulation and
provides step-by-step information to any viewer that needs it.
The UML class diagram to the right
shows how those three classes are
related. It also shows two other
classes, SimulationViewer
and SimulationRunner,
which you can use to test your
code. We provide those classes
too. You are allowed but not
encouraged to change them.

Simulator runs the simulations
step-by-step. Steps correspond to
events -- there is a step whenever
a vehicle leaves the highway to
join a toll booth lane and there is a step whenever a vehicle leaves a toll booth lane.
Simulator can report on the results of each step as it goes along.
The public Simulator constructor has two parameters, the number of vehicles and the
number of toll lanes, which it uses to create a Highway and an array of TollBooths.

The step method works like this:
1. Find out which queue (highway or tollbooth line) has the vehicle for the next event.
2. Get the next vehicle from that queue.
3. What is the length of the vehicle's selected line?
4. Send a message to the line to process the vehicle.
5. Keep track of what's happening to that vehicle's tollbooth line -- did this event make it
shorter (did the vehicle leave the line)?.
This intermediate bookkeeping information is eventually used when the
SimulationViewer animates the simulation.
This project is difficult to test. Even unit testing is difficult because of the high coupling of the
classes. (High coupling, by the way, is considered undesirable. Now you know one of the

When the numbers are coming out right, try out the SimulationViewer. If you specify a
large number of vehicles (say more than 500), set the speed to Fast. Also, note that the
random number generator gives slightly different numbers for each simulation that is started
for a single execution of SimulationViewer. So the final results for two different
simulations with the same number of vehicles and toll booths will differ slightly.
For this class, deployment means submitting your work for grading. Before you submit your
work, make sure your program:
1. Satisfies the style guidelines.
2. Behaves as specified in this document. You should test your code thoroughly. Be sure to
know what messages should be displayed for each major scenario.
3. Satisfies the gradesheet for this assignment.
You must submit the Java source code files that you created:

Powered by