Project 2: Restaurant Simulation

Due: Thursday, October 9, 11:59 PM

Quick Links

API Specification | Skeleton Eclipse project (or get the Skeleton code only)

Project Overview

You will write a simulation for a restaurant. The simulation has four parameters: the number of eaters (diners) that wish to enter the restaurant; the number of tables in the restaurant (there can only be as many eaters as there are tables at a time; other eaters must wait for a free table before placing their order); the number of cooks in the kitchen that fill orders; and the capacity of machines in the kitchen used for producing food.

The simulation will take place as follows. Eaters will attempt to enter the restaurant, but will only be allowed in if there are free tables; otherwise they must wait until a table is free. Once an eater has entered he will place an order, which is a list of food items. Each placed order will be handled by an available cook, who will prepare all the food in the order, using various machines. Each machine has a capacity, and can produce food items in parallel (perhaps for different orders), up to its capacity. There will be one machine for each kind of food item. A cook handles an order by submitting each item to a relevant machine (there is a different machine for each kind of food) that is not at full capacity; the cook may have to wait for machines that are full. Items can be cooked in parallel. Once all of the items have been cooked, the order is complete, and delivered to the eater, who then leaves the restaurant. Then the cook can retrieve the next order. Once all of the eaters who want to enter the restaurant and eat have done so, the simulation ends.

Our particular restaurant will only have three food items (and thus three machines): a burger, made by machine Grill, which takes 500 ms to make; fries, made by machine Frier, which take 250ms to make; and a coke, made by machine Soda Fountain, which takes 100 ms to make. All three machines have the same capacity, as specified by the capacity parameter.

General Requirements

Much of the design of the simulation will be up to you. However, we do have some requirements.

First, you must not use the monitor pattern for synchronizing any part of your simulation. To be starkly precise: the keyword synchronized and calls to wait, notify, and notifyAll must not appear anywhere in your code. Any synchronization you use must be higher-level abstractions provided by the concurrency libraries, such as CountDownLatches, BlockingQueues, etc.

Second, you must implement a method to validate the output of the simulation. This will be run immediately after your simulation completes, to validate its output. (In point of fact, when testing your project, we will use our own validation method. The one you implement will help you with getting the simulation right. We will also grade that you have implemented it correctly.)

Third, you must implement (or use) the following classes, in particular the listed methods. All of these are available in the skeleton code. You may implement any other methods you need for these classes, as you wish. You can also implement additional classes as needed:

* The starred classes are provided for you, and should not be changed; the remaining classes can be changed within the bounds given below.

Particulars

Getting Started

Begin by downloading the project zip file here: Skeleton Eclipse project (or just the code). The directory structure of the zipped folder should allow the existing code to be directly imported into the Eclipse IDE. Note that all code is part of the cmsc433.p2 package, and you should preserve this package structure even if not using an IDE. After downloading the source, familiarize yourself with the above requirements while looking at the skeleton code, and the javadocs found here (and also in the zip file): API Specification. You will need to implement addiitonal methods and/or classes for your simulation; this is just the starting point.

Testing Your Code

We have allowed a great deal of freedom in the design of your classes for this project. Because of this freedom, constructing generic unit-level or system-level tests poses a problem. In particular, we've allowed you to modify the constructors of many objects (such as Machine and Eater), and unit tests would not be repeatable on modified objects. Therefore, you are responsible for your own tests for this project. We will test your code with our own validator, which will check many additional simulation characteristics.

We have provided a class SamplePublicTests as a starting point for testing your simulation, which assumes your Validate class is correct. If not, all bets are off. As such, you will also want to write tests to test your validator (e.g., by generating bogus simulations and making sure it flags them). As a suggestion: you should running your own simulation tests involving different parameters for the simulation. The public tests only try 1x1x1x1, 2x1x1x1 etc. As you become convinced your validation method is correct, make sure it works with different variations of these parameters. Or, to help debug your validation, try these other parameters to see if they help reveal whether the issue is.

What to Turn In

Every file you submit should have your name and UID. To enforce academic integrity, Code WILL BE CHECKED for similarity to other submissions. Each student should make his or her own individual submission.

Submit your code on the Department's Submit Server. Contact the TA if you have any troubles submitting.

You are also required to submit a short "design document" describing the design choices you made in your simulation. Argue how your design satisfies the validation criteria, particularly in its use of synchronization. Feel free to draw pictures to better make your points. Due to the non-deterministic nature of multi-threaded code, a significant portion of your project grade will come from manual inspection of your code, AS GUIDED BY THIS ACCOMPANYING DOCUMENT. Therefore, it is in your best interest to provide a sufficient amount of detail in order to reduce the chance for misinterpretation. Include this document as a PDF file in the top directory of what you submit.

For this project, due to the freedom we've given you with design, your design document should also include a comprehensive test plan. The test plan should describe how you tested each piece of functionality in your code. You may also include any tests that you've written and instructions on how to run these tests.

Web Accessibility