Informatics 42 • Winter 2008 • David G. Kay • UC Irvine

Lab Assignment E

This assignment is due at 4:00 p.m. on Thursday, March 13. Please read the introductory instructions carefully.

For this lab, you will implement some more enhancements to the theme park simulator. There are eight parts to the assignment, each of which is independent. You don't have to do them in order, and you don't have to do all of them (we don't expect anyone to do all of them). More important than how many of the parts you implement is that what you do implement is thorough and correct. Partial but correct implementations (that state clearly what they do and don't include) will receive much more credit than attempts to do everything that contain bugs or other unexpected or undocumented behavior. It's your choice whether you make your enhancements cumulatively (e.g., implementing part (b) on top of the changes you made for part (a)) or independently (i.e., starting from the base simulator for each part).

There is ample opportunity in many of these parts for you to make design decisions in three different areas: the precise functionality and behavior of the enhancement, the user interface, and the design of the code you write. A thorough discussion of the design choices you made in each area will contribute to your score. In that way, a group that thought a lot about the user interface they designed for one of the parts, describing clearly the rationale for their design choices, may get as high a score as a group that implemented more features (correctly) but that followed a straightforward design approach without much analysis or description. We expect every group actually to implement some of these features, but thorough consideration and description of design choices can be as valuable as raw coding.

The simulator's home page is at http://www.ics.uci.edu/~kay/courses/i42/wildride/. The APGUI example code will be available there.

(a) Using the APGUI program as a basis, create a setup or preference panel for the simulator. The panel should display the default parameters, allow the user to change those values, and include a button for starting the actual simulation.

You should allow the user to set such values as opening time, closing time, park entrance, park exit, the name of the customers file, the name of the rides file, and (if you implement the timer code below) the simulation speed. If there are other constants in the code, consider adding them to your preference pane.

Think about the GUI components that make the most sense for entry of each kind of information. "Making sense" in this context means minimizing effort (both in terms of typing and in terms of thinking) for the user and taking advantage of conventions that other software follows. You might consider these components: JButton, JFileChooser, JCheckBox, JRadioButton, JTextField, JLabel, JSpinner, and JSlider.

You should make your display pleasing and legible, perhaps using a layout manager such as Gridbag or Box.

(b) Using your plan from Lab D (or your partner's plan, or a new plan), change the simulator's tick length from one per minute to one per second.

Then re-run your tests (rescaling the data, too, of course) and see whether the results are significantly different.

(c) Using the DrawingExample from the APGUI program as a starting point, implement a graphical display for the overview simulation statistics printed for the customers and for the attractions. (Bear in mind the general principle that every pixel should contribute to conveying information. Don't get carried away with fancy decoration.)

(d) Using code from the APGUI program, the time that is printed out when the simulator is running uses a TimerTask and a separate thread to tick through the simulation of a given day. Using that as a basis, create a real-time graphical display so that some aspect of the simulation can be viewed while the simulation is running. Here are some ideas:

• Display the queue length for each ride (or selected rides)
  
• Plot a map of the park showing the location of each customer
  
• Plot a map of the park showing the location of each ride, perhaps using a color to indicate the estimated wait

(e) Implement store-type rides as we mentioned in the problem description.

(f) Create a GUI for the customer-file generator you created in Lab D. You might integrate this with the simulator itself, perhaps having a pane or button in the setup panel that allows the user to generate the customer data. You might also implement a way for users to describe random numbers generated according to some distribution (other than randomly across the whole space of possible values).

If you'd like to generate ride data using a grammar-based approach and turn that into a GUI, too, go right ahead.

(g) Change the implementation of one or more of the data structures you identified in the Ninth Homework to make them more efficient. Be sure to describe your choices and their performance relative to the original.

(h) Create a GUI progress bar that shows how far a simulation has come (or has to go until completion). The current code produces longer (text-based) bars if the park is open longer, but a typical GUI progress bar has a fixed length, so it has to determine what proportion of the entire task is complete at each step.

The usual warnings, wisdom, and what-to-dos apply to this assignment:

• Get started early.


• Read and re-read the specifications.


• Do this with a partner you haven't worked with yet this quarter (or let Kristina know that you're doing this one alone as your single "pair programming holiday").


• Use Checkmate for your submissions as usual; each pair should submit just one solution.


• The usual grading criteria for lab assignments apply.


• Fill out a partner evaluation at EEE.

Written by David G. Kay and Jeff Ridenour, Winter 2005; modified Winter 2006 and Winter 2008.