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
- The customers should actually follow the waiters in their own square.
- 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:
- Waiter seats customer and “leaves.”
- Customer tells waiter he is ready to order.
- Waiter asks customer what he wants.
- Customer tells him.
- 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:
- Some waiters and the cook will NOT exchange any messages.
- Instead, those waiters will put orders in one of those “revolving stands”.
- The cooks will inform those waiters just like they always do when an order is ready.
- Some waiters will work the same as they did in V3.
You will do this with shared data via a Producer-Consumer model. Here are the key issues to keep in mind:
- Which waiters will be like in V3 and which will be shared-data waiters?
- Who should create the shared data?
- How are cooks and waiters made aware of the shared data?
- The cook must have a way to wake up and look at the shared data.
.
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:
- 50% for the overall v3.1 application in tags and the overall wiki. This is a team grade.
- 40% for the branch code with the unit testing and the other requirements. This is an individual grade.
- 10% for the individual’s contribution to the wiki. This is an individual grade.