Assignments


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

1.      (30 points) Interaction Diagrams, Cook and Waiter Design

a.       Interaction diagram for the normative cycle. Don’t worry about the waiter on break scenario.

b.      Full Design document for the Cook and Waiter 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. 

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.

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.       Full GUI is required (how else will you check out your code?) ; 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 – Team Project with csci200 – See lecture/lab for due dates.   

You will be teamed with students from csci200. There will be some requirements that will affect only csci201 student; the rest will affect the whole team.

·         All your notes, plans, and so forth will be on the wiki. The csci201 people have experience with the wiki and can help the csci200 students.

·         All your code will be keep on a subversion repository. We will talk about the repository in our next class.

 

Here are the joint things and the requirements for them:

GUI control Panel – The current control panel is to be redesigned

1.      Creating customers and waiters is mostly the same. One difference is that v3.1 waiters may be shared data waiters (see PART 2 below) or v3.0 type waiters.

2.      Rather than only seeing and being able to control only one customer or waiter at a time, the GUI should allow all to be accessible.

3.      The “status” of each agent should be shown.

4.      A trace window should be show the message traffic. The window should be able to show all the message traffic, or be able to focus on just one agent.

Animation Changes

  1. The customers should actually follow the waiters in their own square.
  2. The cook should be animated. The cook must move to put the food on the grill and the cook move to place the cooked food on the counter.

 

The following is only for the csci201 Teams:

 

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 – 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 3 - Unit Test all the agents.

                                                                                                                                        

You will unit test some aspects of all the Agents of your v3.1 delivery You are to design the tests and document them as shown below. You will implement some number of the tests. Do at least 3 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
Description: Testing the main interaction diagram for v3.0, everything from the assignment of a customer to his leaving.
Preconditions: No assigned customers, one customer.
Key issue Tested: Startup from empty state.

I want you to do several tests. Make sure each test is fully commented as to why it’s there (be concise).

 

Setting up your unit test environment

 

Your directory structure should look something like this:

 

 

The directories of interest to the unit testing are [interfaces, mock, and test]

 

Please see UnitTestExample for a running example. After you unzip it, look in the doc directory for instructions.

 

Setting up your Subversion repository

 

I strongly recommend that you download a pc or mac based front end to the repository. I use TortoiseSVN, available from http://tortoisesvn.net/

The IDE’s like Eclipse usually have front-ends to Subversion built in. Whichever you choose, it is much easier to manipulate the repository from a graphics style gui than from a Unix command line.

 

In the following discussion, remember you will be using the repository for two projects, v3.1 and the Factory project. So you should set up subdirectories appropriately. This semester we have 200 teams front-ending for several 201 times. For example Team 1 (from csci200) is producing the front-end for Team 1a and Team 1b (both are csci201 teams). Using them as an example, here’s what I expect:

 

Team 1 works alone producing their code in their part of the repository. I assume they will start with one of the "chosen" v3.0 system supplied to them by Team1a and Team1b.  Before they start developing new code, the 201 and 200 teams had better agree on an api for v3.1, otherwise how will you develop your new code?

Individuals of Teams 1a and Team 1b (the 201 teams) work alone in their branch repositories developing their individual code, unit testing, etc. When integration happens, Team 1's work is imported into Team 1a's trunk, each 201 team member will move his code into the trunk, and then you integrate. (Obviously, the same scenario for Team 1 and Team 1b.) Once the Team 1a and Team 1b trunk code works as desired, it is copied into the associated tags directory from which it will be graded.

 

Grading will be as follows:

   


Group Project #2 – 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