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. Requirements 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 unrelated. Design 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 simulation. 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 chooses. 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 myLog. 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. Testing 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 reasons.) 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. Deployment 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: Vehicle.java Car.java Truck.java EZPass.java Highway.java TollBooth.java Log.java Simulator.java