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.
Part 4 – Make sure your agents are thread-safe. This means:
Collections.synchronizedList(new ArrayList<CustomerAgent>());
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:
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.
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.