Assignment 3
COMPSCI 230 S2 2015
Submission deadline: 11.59p.m. Friday 23 Oct 2015
Total marks on this assignment: 20
This assignment counts 5% of total marks in COMPSCI 230.
Learning goals.
This assignment gives you an opportunity to experiment with high level con- currency and understand that some tasks lend themselves to implemention with concurrent models, rather than sequentially.
Asking for help.
If you are uncertain about what is required for this assignment, you should first review the lecture notes and consult the prescribed readings. You are welcome to seek assistance from others on “learning the concepts” after you have done your assigned readings for this course.
Working independently.
You are not allowed to have assistance from any other person when you are completing any part of this assignment. This must be your own work, done independently. You may gain design ideas or examples from the internet or a textbook. You should not assist another student with any part of this assign- ment. However you may help one another with setting up Eclipse projects or the JUnit environment.
English grammar and spelling.
You will not be marked down for grammatical or spelling errors in your submis- sion. However if your meaning is not readily apparent to the marker, then you will lose some marks.
Submission instructions.
Please submit electronically, using the Assignment Drop Box (https://adb.auckland.ac.nz/). Your submission will be:
• An Eclipse project with code files that executes straight away
• a .pdf document containing responses to questions in this assignment,
including application logs
Required resources.
• Eclipse or other IDE for Java development 1
Overview
Your task is to implement a simple simulation of a ski field, and visualize the simulation in a GUI window without risking thread contention in the GUI.
The ski field to be simulated has only 3 elements:
- A slope, where people run down at speeds that vary each time: The runtime may range from 2000 milliseconds to 12000 milliseconds for going from the top of the lift to the end of the waiting queue, where skiers wait to go another round – ad infinitum.
- A queue in front of the ski lift at the lower end of the slope, where people queue neatly in a single row which they do not jump.
- A ski lift with a fixed number of seats (ours has 10) that carries people, one per seat, at a constant speed (passengers are mounting and dismounting at a rate of 1 person per 1000 milliseconds). However, the lift may stop from time to time while carrying people. This happens with a probability of 0.05, and if so, it stops a random time up to 8000 milliseconds.
Passengers are carried from the front of the waiting queue, one by one, to the beginning of the slope, and never travel in the opposite direction (not down again).
Note that seats can be empty, and this may not only be the case at the beginning of the simulation. There will be empty seats if the waiting queue gets shorter as skiers arrive at an average rate lower than the capacity of the lift for an extended time.
Initially the ski waiting queue is filled with a predefined number of peo- ple. Start experimenting with 30, but you should also try the simulation with significantly more once you are confident your code is working properly.
Part 1 [10 marks]
The simulation should run in a self contained module and be implemented in a way that makes it easy to test it (for instance, without any dependency on GUI interaction). ASCII output as in the file provided is su cient. Instead of run- ning unit tests as previously (how would you do this, anyway?), you may prefer to inspect the behaviour of the simulation visually, e.g., by printing strings with IDs assigned to skiers so you can observe their location in the simulation over time.
The following design is suggested to keep things simple:
Use a queue of fixed size to model the seats in the lift. One thread of execution controls the ”lift queue” by appending elements at one end (the lower end of the lift) which are taken from another queue (the waiting queue) at a frequency of 1Hz. In the same step, the top element of the ”lift queue” is removed. The elements of the lift queue are ”skier objects” that are instantiated from a class that implements the runnable interface and have the ability to run down the slope themselves and append themselves to the end of the waiting
2
queue upon arriving at the lower end of the slope. To facilitate this, these skier objects should have a reference to the waiting queue – use a suitable thread constructor to pass it in. Also note that new threads should be instantiated for each run down the slope, as it is illegal to call the start() method more than once on the same object.
Think about which of the datastructures need to be thread safe and imple- ment accordingly.
If everything runs fine with a small number of skiers, run the simulation with a larger amount of skiers (try a few hundred, than a few thousand etc.) and speed up the lift.
Report when you run into trouble further increasing the number of skiers and what are the symptoms.
Part 2 [5 marks]
Implement a GUI that displays the simulation.
Remember that that the simulation should run inside a background task
to prevent freezing the GUI and from from this background tasks the GUI components should not be modified directly, so as to avoid unpredictable errors. In a first step, simply put through to the GUI ASCII output from above the simulation to a TextArea. Add buttons to start and stop the simulation, and to initialize the ski field. Also add Textfields for the following parameters and pass these to the SwingWorker which runs the ski field simulation in the
background:
- Number of seats on the lift.
- Speed of the lift (in passengers carried per second).
- Number of skiers on the skifield (e.g., the number intially waiting in the queue).
- Maximum time for the run down the slope.
- The probability with which the lift stops for a time of up to 8 seconds.
Run the simulation with di↵ernt parameters to make sure everything works well.
Part 3 [3 marks]
Use the data returned from the SwingWorker to visualize the simulation using graphic elements. A very simple visualization is fine: Just use points or circles or numbers to visualize skiers. The skifield can be displayed such that the paths skiers take lie on a triangle, where the base represents the waiting queue and the other two sides visualize the lift and slope respectively. You do not need to interpolate the positions to produce a smooth animation. Updates at the frequency of the ski lift uptake are su cient.
Part 4 [2 marks]
Describe (in as few words as possible) how the simulation (without the GUI interaction) could be implemented without threading.
3
Note:
You can choose an entirely di↵erent simulation approach if you think the design has material benefits over the proposed one. If you do, please let me know by email so I can liaise with the markers to avoid unfair marking of excellent, creative solutions.
4