Assignments


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

1.       (30 points) Interaction Diagrams and Cook Design

a.       Interaction diagram for the normative cycle.

b.       Interaction diagram for the waiter on break scenario.

c.       Full Design document for the Cook only. 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. 

·         Use the pseudo-code conventions showed in class.

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

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, etc.

2.       (30 points) Skeleton Implementation

a.       All agents present, running main cycle;

b.       Design documents for each agent. If you have the design on paper, turn them in to me on in class before the due date or in my box.

c.       GUI not necessary; Waiter on break not necessary.

d.       Make sure your skeleton does at least the following:

·         1 customer, 1 waiter, 1 host, 1 cook, 2 tables (should produce a trace like the interaction diagram)

·         3 customers, 2 waiters, 1 host, 1 cook, 2 tables. (make sure the behavior of the waiters shows interleaving. This might be easier to show with more tables and more customers.)

See skeletonSubmittal.txt for submittal instructions.

3.      (60 points) Final V3.0 delivery

a.       All Cycles working including waiter on break.

b.      GUI allows waiters to be created just like customers. The waiter needs a “Want To Go On Break” button. The entire application must be runnable from the GUI.

c.       All design documents.

d.      Make sure your Javadocs are complete.

See v3Submittal.txt for submittal instructions.              


V3.1 Project –Multi-Step Actions and Unit testing – See lecture/lab for due dates.

PART 1 - 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 2 - Unit Test the Waiter Agent.

 

You will unit test the Waiter Agent of your v3.0 delivery (including the multi-step actions above). You are to design all the tests and document them as shown below. You will implement some number of the tests. We’ll discuss the details in class.

 

The deliverable should include a design document that describes concisely every test you should/will be programming and give an outline of how the test will work. Here’s an example for the Waiter:

Name of Suite: Testing Empty Waiter                                            

Preconditions: No assigned customers, one customer.

Description: Testing the main interaction diagram for v3.0, everything from the assignment of a customer to his leaving.

Key issue Tested: Startup from empty state.

Naturally, there should be tests where there are already assigned customer, handing off the last customer, etc., etc. There should be tests for the waiter-on-break code. Make sure each test is fully commented as to why it’s there (be concise).

 

·         See v3-1Submittal.txt for submittal instructions.      


Group Project – Please see  TheFAAProject.htm


Tasks cards are here: TaskCard.doc or TaskCard.txt

 

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