Assignments


v4 Project – New requirement to add to V3.0 in two versions, v4.1 and v4.2.

Here are the v4.1 requirements

Part 1 - Adding a Cashier to the restaurant

·         Prices of the food are on the menu.

·         Customers can still order only one item from the menu. The customer better have enough money to pay for his item.

·         The waiter will … what?  How do bills get to cashier? [We’ll talk about design in class].

·         The customer will … what? How do customers pay. [We’ll talk about design in class].

Here’s what we decided in class:

a.       Waiter gives cashier and customer a bill.

b.      Customer goes to cashier and pays the bill.

Part 2 – The Cook may run out of food. Here are some requirement details:

·         The Cook has a source for food called Market. [Treat the Market as an agent.]

·         When inventory for items is low, they should be ordered from the Market (the order might take hours to be fulfilled).

·         Customers should be given a chance to reorder for an item that has run out.

·         The Market will then … what? [We’ll talk about design in class.]

Here’s what we decided in class:

a.       Cook sends market  HereIsOrder(List<item,howMany>)

b.      Market sends OrderFulfilled(List<item,howMany>, bill)

c.       Cook has multiple markets

d.      Cook and market will use same inventory class, which we designed roughly in class.

In non-normative scenario, Market may be unable to fulfill an order and needs to send a message stating state. Cook has multiple markets.

 

Part 3 – The Waiter can go on break.

·         The waiter has a GUI button for going on a break.

·         When the button is pushed, the waiter does ... what? [We'll talk about the design in class.]

·         What role does the host play? [We'll talk about the design in class.]

Here’s what we decided in class:

a.       Going on break button is pushed. [Change the name of that button and its associated variable in the WaiterAgent.]

b.      Waiter tell host.

c.       Host acknowledges if it ok to go on break. Host sends this waiter no more customers.

d.      Waiter finishes servicing his current customers.

e.       Waiter goes on break.

Part 4 – Some more Customer scenarios.

·         If all the tables are full, the host tells the customer who may decide to leave.

·         The customer can change his mind about what he has ordered if the order is not yet cooking or ready to deliver. [This is tough.]

You’ll have to add events and change the customer's state machine scheduler. And, of course, a lot of code to the waiter and cook.

 

Here are the cases your code should run:

Simple Normative Scenarios

- 1 of every type of agent, no market interactions, customer orders, pays, and leaves

- No customers,  cook orders low items from market, when food arrives, customers arrive

- Multiple customers, multiple waiters, cashier operating normally, no running out of food.

- Waiter wants to go on break, he's told it's ok, goes on break when he finished all his current customers; goes on break, then goes off break.

 

Some non-normative scenarios:

- Customer orders, food has run out, cook has obviously ordered but food hasn't arrived, Customer makes new choice.

- Cook orders from favorite Market, but is told they can't fulfill his order; must order from one of his backup markets.

- Customer changes his order; (1) waiter says it's ok to change if it is ok, or (2) waiter tells him it's too late if it is too late.

- Customer doesn't have enough money to order anything and leaves.

- Customer has only enough money to order the cheapest item.

- Customer orders, eats, but hasn't enough money to pay.

- Waiter wants to go on break, he's told it's NOT OK and must keep working.

- Customer comes to restaurant and restaurant is full, customer is told (1) and waits (2) customer leaves.

Here are the v4.2 requirements:

Part 4 – Make sure your agents are thread-safe. This means:

 

  1. Synchronizing your lists using Collections.synchronizedList (), e.g.
                             private List<CustomerAgent> waitList =

                                      Collections.synchronizedList(new ArrayList<CustomerAgent>());

  1. Putting synchronized blocks around list searches: e.g.

synchronized(waitList){

                                  tellWaiterToSitCustomerAtTable(waiters.get(nextWaiter), waitList.get(0), i);

                              }

 

Both of the above examples are from the HostAgent.

 

Part 5 - Implement multi-step actions.                                                                                                                          

Use this Waiter-Customer ordering scenario as in the original v3 interaction diagram:

  1. Waiter seats customer and “leaves.”
  2. Customer tells waiter he is ready to order.
  3. Waiter asks customer what he wants.
  4. Customer tells him.
  5. Waiter gives the cook the order (as before).

 

Steps 2-5 should be carried out via one action in the customer and one action in the waiter.

 

Part 6 - Incorporate Shared Data between Cook and Waiter.

                                   

In v3.0, the cook receives orders directly from waiters. We are going to change that interaction. Here are the new requirements:

 

You will do this with shared data via a Producer-Consumer model. Here are the key issues to keep in mind:

                               

Part 7 - Unit Test your Cashier.

                                                                                                                                        

Each student will unit test their own v4.2 Cashier. You are to design the tests and document them as shown below. You will implement some number of the tests so that you are confident that it really works. Of course, this is in preparation for the major team project.

 

Please see http://www-scf.usc.edu/~csci201/lab/LabforSettingupUnitTesting.pdf for instructions.

3 Deliveries – Worth 120 points total.  See lecture/lab for due dates.

1.      (30 points) Full Design of all 6 agents (Cook, Waiter, Host, Customer, Cashier, and Market)

a.       Interaction diagram for all the scenarios.

b.      Full Design document for all the agents (reverse engineer the design from the code we didn't go over.). The document must include:

·         The agent’s messages and what will happen on reception;

·         The scheduling algorithm, i.e., the rules.

·         The agent’s actions and what they do;

·         Data it manages. 

c.       In the diagrams we are looking for message number, parameters, good message naming;

d.      Use the pseudo-code conventions showed in class.

e.       In the design pseudo-code, we are looking for the proper complexity, consistency with the interaction diagrams, good use of variables, limited variables, maps for the timing functions in cook, consistency with the interaction diagram, etc.

      See v4DesignDocSubmittal.txt for submittal instructions.

2.      (30 points) v4.1 Implementation includes the incorporation of the Cashier, Market, and waiter on break.
Don't forget a readme.doc in your doc subdirectory telling us how to run all the cases stated in the 4.1 requirements.

      See v4.1Submittal.txt for submittal instructions.

3.      (30 points) v4.2 Implementation includes:

a.       Thread-safe agents

b.      the multi-step actions;

c.       shared data;

d.      unit testing of your cashier

      See v4.2Submittal.txt for submittal instructions.              

                                                                                


Group Project with csci200 – Please see  TheFactoryProject.htm


 

The University of Southern California does not screen or control the content on this website and thus does not guarantee the accuracy, integrity, or quality of such content. All content on this website is provided by and is the sole responsibility of the person from which such content originated, and such content does not necessarily reflect the opinions of the University administration or the Board of Trustees