-          Timer Utilities. This release includes some timer utilities found in java.util.Timer. We need the ability to set a timer for some length of time and then execute a routine when it expires. Of course, the timer runs in its own thread (make sure you understand this). We’ll explain this mechanism in class. We’ll also how to implement an anonymous inner class in Java.

-          How does the agent get hungry? The customer agent represents a very simplified person that gets hungry and goes to a restaurant to get fed. How does the agent get hungry? The agent has a setHungry() method that does this. Think of it as a message. Perhaps it might look like the following:

public void setHungry() {

event = gotHungry;

print(“I’m hungry”);

fsm(); //invoke the finite state machine, which is the schedule

}          

Here’s how we use setHungry():

In the Main.java main routine, described in the next section, the  setHungry()  method is called directly. That gets the customer going. Once he’s hungry, he goes to the restaurant, etc.

After the customer leaves the restaurant, how does he get hungry again? There are three approaches: (1) The main routine in Main.java could somehow do it, but that wouldn’t be too elegant; 2) We could wait for some time to expire and automatically get hungry again. That’s what happens in the prototype. We call the timer routine, which will then call setHungry() again. 3) We could have a user interface with a button that let’s us set the agent to be hungry. You’ll see that in the GUI.

·         How long does agent eat?  We use the same timer method to simulate eating. In other words, once the agent is seated, we simulate the eating period by setting a timer. When the timer expires, the eating is done. You will find many applications for using timers.

3.2.5  Running the v1.0 Prototype via  Main.java

The main routine in Main.java creates the agents in the prototype application, sets the maitre’d for the customers, and then sets the customers hungry. Take a look.

public class Main {

public static void main(String argv[]) {

/*

The following four lines create our four agents.

Each agent instance has a thread in which it runs.

The thread is created and started by the constructor.

*/

MaitreDAgent maitreD = new MaitreDAgent();

CustomerAgent c1 = new CustomerAgent(“Fred”);

CustomerAgent c2 = new CustomerAgent(“Ethel”);

CustomerAgent c3 = new CustomerAgent(“Ginger”);

/*

The next three lines tell the customer instances who

the maitreD is. The maitrD learns of the customers by

the first message the customer sends to the maitreD.

*/

c1.setMaitreD(maitreD);

c2.setMaitreD(maitreD);

c3.setMaitreD(maitreD);

maitreD.startAgentThread();

c1.startThread();

c2.startThread();

c3.startThread();

  /*

At this point the agents are started, but are not

doing anything, because nothing has happened to make

them do things. So, we (artificially) make each

customer hungry. c2 is made especially hungry (that

will make him eat longer.)

  */

c1.setHungry();

c2.setHungerLevel(7);

c2.setHungry();

c3.setHungry();

  /*

This main thread ends leaving the agents to “fend for

themselves.” You will see that after a customer is fed

and not hungry, it will set a timer to set it hungry

again later. That’s why this prototype runs forever.

  */

  }

}

To run this code, connect to the release directory and type:  ant run

You should see output like this:

     [java] Fred: I'm hungry

     [java] Ethel: I'm hungry

     [java] Ginger: I'm hungry

     [java] Ethel: Going to restaurant

     [java] Fred: Going to restaurant

     [java] Ginger: Going to restaurant

     [java] MaitreD: Seating customer Ethel at table 1

     [java] Ethel: Received msgSitAtTable

     [java] MaitreD: Seating customer Fred at table 2

     [java] Fred: Received msgSitAtTable

     [java] Fred: Being seated.

     [java] Fred: Eating for 5000 milliseconds.

     [java] Ethel: Being seated.

     [java] Ethel: Eating for 7000 milliseconds.

     [java] Fred: Done eating, cookie=1

     [java] Fred: Leaving.

     [java] MaitreD: customer Fred leaving table 2

     [java] MaitreD: Seating customer Ginger at table 2

     [java] Ginger: Received msgSitAtTable

     [java] Ginger: Being seated.

     [java] Ginger: Eating for 5000 milliseconds.

     [java] Ethel: Done eating, cookie=1

     [java] Ethel: Leaving.

…

3.2.6    Running the v1.0 Prototype with the GUI

The restaurant application as run in the first deliverable is obviously simplified. It was just a quick stop along the development of our restaurant. This is the right time to REPLACE the functionality of the old main() routine of Main.java with a GUI.

As a replacement for the old main() routine, we can think of the GUI as a configurator for the restaurant. That is, it has “buttons” to control the activities and objects in the restaurant. It can also show us status and object information for the application. For this release we want it to be able to do everything that Main.java  could do, except with GUI flexibility. The requirements will give the details.

Here are the minimum requirements for the gui.

·         GUI can create the MaitreD agent.

·         Customers can be added.

·         Customers can be set to hungry. (The timing hack in the customer agent that makes him hungry after some amount of time should be removed.)

To run the gui, connect to the release directory and type:  ant run.gui

This gui was designed by a student in one of the previous classes.

3.3    v3.0 - A specification of a restaurant

v3.0 is an implementation of a restaurant. Of all the requirements specified in the section above, some have been selected for design. This is typical during early system specification. First a system is fully specified, then for each implementation (or prototype) some subset of the requirements is selected for design and implementation. Succeeding iterations might add (or change) requirements.

3.3.1    Customer Requirements

Requirement 1: Getting Hungry:

Normal Scenario: When he gets hungry, he goes to restaurant and tells the Host he wants to eat.

Requirement 2: Eating at a restaurant:

Normal Scenario: Present himself to the host. When he is seated by his waiter, he will be presented with a menu. Tell the waiter when you are ready to order, and then tell him your choice. When you get your food, eat it. Tell the waiter when you are done and leaving the restaurant.

There can be many customers.

3.3.2    Host Requirements

Requirement 1: Greets Customer

Normal Scenario: When he becomes aware of customer entry into restaurant, he puts customer on waiting list. If table is available, then he tells a working waiter to seat the customer at the free table.

Requirement 2: In charge of tables.

Knows about the tables in the restaurant. Assigns customers to tables. When customer leaves, the waiter will inform the Host that the table is free.          

There will be only one host.

3.3.3    Waiter Requirements

Requirement 1: Services Customer

Normal Scenario: Host tells waiter to seat the customer at a table. Once seated the waiter gives the customer a menu. When the customer is ready to order, the waiter takes the customer’s choice. He gives the order to the cook. When the order is ready, the waiter serves the customer. When the customer is done, he tells the waiter that he is leaving. [No check or money collection in v3.0]

There can be many waiters. See section 11.3 about menus.

3.3.4    Cook Requirements

Requirement 1: Cooks orders       

Normal Scenario: Receives orders from the waiter. Cooks them. When an order is ready, the appropriate waiter is notified.

There will be only one cook.

3.3.5    Interaction Diagram

An interaction diagram shows the EXTERNAL behavior of object oriented systems. In agent systems the interaction diagram shows the messaging behavior over an instance of the running system. In general, there is one interaction diagram for each scenario. A system is normally described by many such diagrams.

Each diagram should be simple. There is no branching or alternatives. You can make comments on the diagram. See section 3.1 for an example of an interaction diagram. We will do the v3.0 diagram in class.

3.3.6    GUI and Animation

The v3.0 application comes with a GUI and animation. From the GUI:

• Customers and Waiters can be created.
• Customers can be set to Hungry.
• Waiters can be set to go on and off breaks [you will implement it later.]

I will do the cook and customer agents in class. You will reverse engineer the host and waiter for homework.

3.3.7    The v3.0 Implementation deliverable

The starting point system is on the lecture lab page. There is a java and C++ version. Details of downloading and using them will be discussed in class and be the focus of your first lab.

4      Agent Design and Implementation

Now that we have the high-level requirements for our agent application, we can consider how the Agent is designed and implemented. Let's review some of agent basics:

·         Agents are autonomous.

·         Agents communicate by messaging.

·         Agents have three logical parts, which can act concurrently.

·         Agents will not share data with one another.

·         Agents have actions that are independently schedulable for as long as the agent is active.

Let's review a few software-engineering ideas:

There are other possible requirements that would influence our design. For example, we might want to be able to run each agent on a separate computer. Should we anticipate this requirement and consider it in our design? It certainly seems natural. The answer is not yet; we won’t let this requirement influence our design.

In early releases of the software, we may decide to 1) implement a simplified version that does not fulfill all of its requirements, or 2) compromises some of the requirements slightly. That’s acceptable as long as the client agrees. The client is usually the customer stakeholder of the software, the person paying for it. In our class, I am the client. Any deviation from the requirement must be explained to me.

Early releases are often called prototypes. A prototype can help us learn about the system, uncover new requirements while giving the customer insight into what he has specified. We have learned that early quick releases can be more important than waiting for a delivery that exactly fulfills all the requirements. The early v1.0 system described above is such a prototype.

4.1    The Design of v3.0

An agent design must specify four things:

·         The agent data;

·         The agent messages;

·         The scheduling rules;

·         The agent actions

4.2    A Concrete Agent

The abstract base class, Agent.java, will be described later. For now, all that we have to know is that the above four things must appear in a concrete (derived) agent. For example, the waiter agent might have the following signature:

public class WaiterAgent extends Agent {...}

Let’s see what goes inside this concrete agent.

4.2.1    The Agent (Messaging) Interface

In section 2.1 formal messaging was described. I have made a design decision in the prototype that we do not need formal messaging. Our agents will simulate formal messaging as follows:

·         An agent’s external interface will be all the message-handling calls. That way no parsing is required; we'll go over this in a future class.

·         Message-handling calls return VOID. Its execution must act on the message as it sees fit: store information into its state; put requests on an internal queue; whatever is appropriate. It must not return a value; that is not in the spirit of messaging. And it must return quickly; handlers generally do not do “semantic” processing; they just add information to the state of the agent. The scheduler will call actions to do the actual work.

Here’s pseudo-code to show how this works:

//Sender Code found in an action of the waiter

Prepare(me,2,“Hamburger”); //Call message-handler directly.

... //continue on with other work.   

//Recipient Message-Handler for Prepare (in the cook Interface)

Void Prepare(sender, table, item){

/*This code does EXACTLY the same thing as it did

in the dispatch code in the messaging example of section 2.1*/

...

}

All we are doing is having the sender call the message-handler method directly. No marshalling of the message, no external message queues are used, no persistence of messages. That simplifies some things, but complicates others.

Notice also that execution of the handler code is happening within the sender’s thread of control (make sure you understand this). Of course, that’s not real messaging, but it is a logical simplification. Doing messaging this way depends on three key points:

·         The method call must return VOID or we aren’t doing messaging.

·         There must be no shared data between code in the sender and code in the recipient. Even though they may in the same address space, they MUST NOT share data. Any structures passed as parameter need to be copied by the recipient since Java passes pointers (make sure you understand this). Otherwise a fundamental agent principle is being violated.

·         The message-handling call must return quickly. It should set some state or queue something up for the scheduler to look at. If it tries to do a significant amount of processing, then it isn’t behaving like an agent. Remember that the message-handling method is acting in the sender’s thread of control. In the case of Prepare(sender, table, item) the handler would put this on the cook’s queue of things to do and when its scheduler picked this item, a Cooking action would actually prepare the food and send a message to sender when the item was finished. [Can you figure out why the table number is part of the message?]

So, with this simulation of messaging we have another design decision that violates two requirements.

Requirement: An agent has three parts, each with its own thread of control.
Violation: Here the message reception part DOES NOT have its own thread—it is in the sender’s thread.
Accommodation: Since the sender and receiver’s scheduler have different threads of control, the effect we are looking for, i.e., scheduler and message reception happen concurrently, is still satisfied.

Requirement: Agents must not share data.
Violation: By having the sender call the recipient’s dispatch routine directly, the recipient has direct access to the sender’s structures.
Accommodation: If the recipient or the sender COPIES the structure, then no data is shared and we have the same effect as in real messaging. Which do you think should do the copying?

Is this acceptable? Yes, if we understand what we are doing, if we document it carefully, and if the client agrees. And since I am the client, anything that satisfies me is all right.

By the way:

·         Java does have a full messaging package. If your application requires it, use it. We just don’t need it for our current purposes.

·         If we want to implement the agents as separate processes, not just separate threads, Java has a package called RMI (Remote Method Invocation). Uusing RMI one process can invoke another even if it is executing on a different machine. RMI copies all data structures that are used in remote method calls.

4.2.2    The Agent Scheduler

The base agent, as we will see later, is mostly an infinite loop that invokes the scheduler. When you build a concrete agent, you must implement a scheduler. The scheduler holds the logic that decides what an agent can do. Here’s how it should look:

/** Scheduler.  Determine what action is called for, and do it. */

boolean pickAndExecuteAnAction () {

     //Rule 1:

     if (condition1) {action1(...); return true;}

     //Rule 2:

     if (condition2) {action2(...); return true;}

     return false; //we have tried all our rules and found nothing to do.

                    //So return false to main loop of abstract agent and wait.

}

Here is a scheduling rule that might exist for the cook:

if ($ o in orders ' o.isPending()) then  (prepareOrder(o); return true);
The above is read as follows: if there exists an o in orders such that o.isPending() then call prepareOrder(o) and return true.

There are many things to note here:

·         The conditions can be arbitrarily complex. The above rule is typical: look for the existence of an object that satisfies some predicate, then pass it to some action.

·         The rules are prioritized by the order in which they appear in the code. If the scheduler  picks an action, it returns true to the base agent, whose loop invokes the scheduler again, trying the rules from the top. This is a very simple scheme that has worked for me in all my agent implementations.

·         This scheduler invokes one action at a time. Could an agent have two actions active at the same time? In my experience, whenever I seem to have that need, I look closely and find that I need another agent. Having agents only executing one action at a time simplifies the agent design. This one-action-at-a-time is almost a requirement for me, but I let individual agent designers decide.

·         This scheduler is not concurrent with actions. That is, this schedule makes a synchronous call to an action and waits for it to complete before returning and trying to schedule another action. That’s a requirement violation. But since we have just decided to only schedule one action at a time, there seems to be no problem. Or is there? Take a moment to think of a problem that might arise with this design. Warning: an answer is coming…Suppose you are performing some action when a very high priority message comes in, say:
            PleaseSeat(“Prof. Wilczynski”);
Don’t you want to drop everything and give Prof. Wilczynski the best service you can? Yes, you do. Your scheduler needs to be able to suspend the active action, and schedule a new action involving the professor. The scheduler cannot do this if it is synchronously waiting for actions to complete. It must be in its own thread monitoring the messages and actions (make sure you understand this). However, suspending actions and scheduling new ones increases the complexity of the agent design too much—we may handle this case in a later version. So, for now, we will recognize the following violation:

        Requirement: An agent has three parts, each with its own thread of control.
Violation: Here the scheduler and actions work in the same thread.
Accommodation: Only one action can be carried out at a time and it always runs to conclusion, i.e., it cannot be interrupted, canceled, or restarted.

4.2.3    The Agent Actions

Finally it’s time to describe the actions the agent actually performs. Each action is encoded in a single method. For example, here is the host code that assigns a customer to a waiter:

private void tellWaiterToSitCustomerAtTable(

                             MyWaiter waiter, CustomerAgent customer, int tableNum){

      print("Telling " + waiter.wtr + " to sit " + customer +" at table "+(tableNum+1));

      waiter.wtr.msgSitCustomerAtTable(customer, tableNum);

      tables[tableNum].occupied = true;

      waitList.remove(customer);

      nextWaiter = (nextWaiter+1)%waiters.size(); //get next waiter ready

    }

As usual there are several things to note:

·         This is real Java code, not pseudo-code. Eventually, the implementation has to reach this level. But still, my pseudo-code is very much like Java. That's why I use Java.

·         tellWaiterToSitCustomerAtTable() returns void. All actions do.

·         tellWaiterToSitCustomerAtTable() is private. Only the scheduler can invoke an agent’s actions. The parameters are Java objects instantiated from Java classes.

·         The print() is for tracing only.

·         Then we send the waiter a message to seat the customer.

·         The next three lines update the agent’s data structures: 1) marking the table as being occupied; 2) removing the customer from the waiting list; 3) setting up the next waiter to be used.

4.3    The CustomerAgent - An example of a finite state machine

The general agent as described above has its intelligence encoded in its rule-based scheduler. Most agents will be designed this way. However, you may have an agent whose control structure can be more simply modeled as a finite state machine (fsm). Recall that a finite state machine is defined by a transition function that maps (state, event) ---> (state, output). That is, an fsm is a table of the form:

where the nextState is one of the s1, s2, ...sn, and the someOutput is an action of our agent. In our fsm agent, message reception sets the event (and other variables as needed), while the scheduler embodies the table. Here is the states and events from the v3 CustomerAgent.

    public enum AgentState

                {DoingNothing, WaitingInRestaurant, SeatedWithMenu, WaiterCalled, WaitingForFood, Eating};

    private AgentState state = AgentState.DoingNothing; //The start state

    public enum AgentEvent

                {gotHungry, beingSeated, decidedChoice, waiterToTakeOrder, foodDelivered, doneEating};

    private AgentEvent event; //Messages set the event

    List<AgentEvent> events = new ArrayList<AgentEvent>(); //events are added to list via messages

Here is the first message the customer receives:

    /** Sent from GUI to set the customer as hungry */

    public void setHungry() {

            events.add(AgentEvent.gotHungry);

            isHungry = true; // a hack

            print("I'm hungry");

            stateChanged();

    }

Here is the beginning of the fsm scheduler:

    protected boolean pickAndExecuteAnAction() {

            if (events.isEmpty()) return false;

            AgentEvent event = events.remove(0); //pop first element

            //Simple finite state machine

            if (state == AgentState.DoingNothing){

                if (event == AgentEvent.gotHungry)         {

                        goingToRestaurant(); //the output action

                        state = AgentState.WaitingInRestaurant;

                        return true;

                }

                // elseif (event == xxx) {} //if there were other events for this state

            }

            if (state == AgentState.WaitingInRestaurant) {

                if (event == AgentEvent.beingSeated)       {

                        makeMenuChoice();

                        state = AgentState.SeatedWithMenu;

                        return true;

                }

               // elseif (event == xxx) {} //if there were other events for this state

            }

            if (state ...

           ...

  }

You can see the actions in the code. We will talk more about this in class.

5      Agent Base Class Design

At this point of the software engineering cycle, an O-O design will follow—classes, methods, etc. At the base class level, we only know about the run cycle.

class Agent {

     run();//invokes the scheduler repeatedly

}

Since the base class agent has no application semantics, we can only specify the run cycle (to find and execute an action).

Remember, the idea of design is to describe HOW a system will work as abstractly as possible so as to make sense, be implementable, understandable. The programming details are filled in during the implementation phase. DO NOT CLUTTER UP A DESIGN WITH PROGRAMMING DETAILS. In the design we don't even have to specify the constructor, which is really an implementation detail.

In (very) pseudo-code here is one conception of the natural run-cycle of an agent:

run(){

 while agent is active {

pick an action;

if action is picked

  then perform the action;

  else sleep until state changes;

}

}

Some would want this tightened up a bit. Perhaps:

run(){

 while agent.IsActive() {

action = pickAnAction();

if action

  then perform(action);

  else sleep() until stateChanged;

}

}

Is this better? Now we have to add  AgentIsActive(), pickAnAction(), perform(), sleep()and stateChanged  to our base class specification. Notice also that the notion of an agent being "active" has been introduced. Perhaps we should add a routine to deactivate an agent, say deactivateAgent(). Let's do it without thinking too much about this decision. So, our Agent base class design now looks like:

class Agent {

     //variables

     Action action;

     bool stateChanged;

//methods

     run();//invokes the scheduler repeatedly

     deactivateAgent();

bool agentIsActive();

Action pickAnAction();

perform(Action);

}

This tightening up has added types to the method declarations. For years I have created designs without strong typing and survived. However, the trend is clearly toward typing in designs. Let's just do it. That being said, notice that the design is getting harder to read as more programming lingo is introduced.

In any case does the above specification really work? Don't actions take parameters? Yes, they do. This level of pseudo-code is missing them and there is no obvious way of putting them in. [Why?] Perhaps we should abstract the action out of this loop, something like:

run(){

 while agentIsActive() {

if ~ pickAndExecuteAnAction()

  then sleep() until stateChanged;

}

}

I like this. Now we would have the following design for the base class agent:

class Agent {

//variables

     bool stateChanged;

//methods

     run();//invokes the scheduler repeatedly

     deactivateAgent();

bool agentIsActive();

bool pickAndExecuteAnAction();

}

What about pseudo-code for the new methods? There isn't any, because at this level of abstraction there is nothing to specify; the intent of the routines is clear. That's all that is needed for design.

Notice how we made several passes to a satisfactory design for the run() method. That was no surprise.

5.1    Agent Base Class Implementation

5.1.1    The Abstract Base Class Agent

The abstract Agent class was designed to make coding of a concrete agent easy. The abstract class has the code for:

·         Managing the agent thread that runs the infinite loop that invokes the concrete scheduler.

·         Various utilities.

You should be looking at Agent.java while reading the rest of this section.

5.1.1.1  Agent Threading Model

The abstract Agent class contains a private class whose signature is:

private class AgentThread extends Thread {...}

And the Agent class has an instance variable to hold the newly created thread:

private AgentThread agentThread;

The agentThread variable will be initialized by the agentThread.start()  method:

agentThread = new AgentThread(getName());

agentThread.start() is the method that actually gets the thread running. Java will create the thread and give control to its run() method. agentThread.start() will be called by the code that constructs the agent.

What is going on? For one thing, an agent designed this way is not really autonomous. It’s going to be a thread within some other process’ address space. Our prototype has the entire application as one process with each agent in its own thread. So, here we have a typical software engineering occurrence, an implementation decision that violates a requirement.

Requirement: An agent is autonomous.
Violation: Here the agent is running as a thread in an address space with other agents. The possibility of sharing data is possible.
Accommodation: As we will see, we will be careful NOT to share data. Then, if each agent gets its own thread, then the concurrency is there by way of the operating system scheduler (illusion of concurrency).

Also, why doesn’t the Agent class extend Thread directly? What’s the purpose of making the thread an instance variable of the agent? Mostly, it is a design decision to make unit-testing easier. Code that wants to test a class usually does things like the following:

Instantiate the class, e.g.  ClassA a = new ClassA();

Then execute the methods of the class and see if they do the right thing, e.g.
if (a.sum(2,3) != 5) assertFailure();

Doing this kind of unit testing is difficult if the object is actually running in a separate thread (you will try this in your lab). So instead, we make the Agent a regular object and create an instance variable to hold the thread. It’s not as complicated as it looks and we will go over this in great detail in class.

5.1.1.2  The run Method (Main Loop)

In the Java threading model, a thread is started by invoking the start() method. That tells the operating system to create another thread of control in this address space, and start its execution at its run() method. In other words, run() performs the same function for a thread as main() does for a process.

Our run() routine is tricky. Its intention is to invoke the scheduler for as long as there is something to do. If the scheduler—implemented in pickAndExecuteAnAction()—has nothing to do, it returns false and the agent sleeps until its internal state changes (make sure you understand why this makes sense). The agent uses a classic synchronization mechanism called a binary semaphore to implement this logic. One of the private variables is:

Semaphore stateChange = new Semaphore(1, true); //start with one permit

Semaphore is a type in Java 1.5's new java.util.concurrent package. We will discuss semaphores in a lecture when we discuss concurrency.

Here is the run() method:

public void run() {

            goOn = true;

            while (goOn) {

                  try {

                     // The agent sleeps here until someone calls stateChanged(),

                     // which causes a call to stateChange.release(), which wakes up agent.

                     stateChange.acquire();

                     //The next while clause is the key to the control flow.

                     //When the agent wakes up it will call respondToStateChange()

                     //repeatedly until it returns FALSE.

                     //You will see that pickAndExecuteAnAction() is the agent scheduler.

                     while (pickAndExecuteAnAction());

                  } catch (InterruptedException e) {

                        // no action - expected when stopping or when deadline changed

                  } catch (Exception e) {

                        print("Unexpected exception caught in Agent thread:", e);

                  }

            }

}

goOn is a simple private variable that controls the main loop. As you can see goOn is set to true; a method called stopAgent() turns it off. For as long as goOn is true, the loop continues. The intention is for the agent to run forever until stopAgent() is called or the execution of the whole process is killed.

The loop executes two statements within a try-catch. The first invokes the method acquire() on the semaphore variable stateChange.  The call puts the thread to sleep until someone calls the semaphore method release(). The agent waits here until someone calls stateChanged(), which results in a call to stateChange.release(), which wakes up the agent. Who calls stateChanged()? There are two events that change the state of the agent:

·         message reception code;

·         action code.

We will see examples soon.

Back to the try clause within the while loop. The clause:
                    while (pickAndExecuteAnAction());
is the key to the control flow. When the agent wakes up it will call the scheduler via pickAndExecuteAnAction () repeatedly until it returns FALSE. You will see that pickAndExecuteAnAction () is the agent scheduler.

Notice that pickAndExecuteAnAction () is an abstract method in Agent. That means that any concrete class that extends Agent must implement pickAndExecuteAnAction (). The scheduler code must be abstract because details of the scheduler are application dependent.

5.1.1.3  Utilities in Abstract Agent Class

There are four utility routines:

Do(String msg);

print(String msg);

print(String msg, Throwable e);

getName();

Do() is for simulating the agent primitives. It will call print().

The print() routines are for our simulated output (or any output we want).

getName() returns the agent name.

These routines are simple. See the code for details.

6      More on Design and Pseudo-Code

There are a few design themes that have been uncovered even with this small amount of code we've specified.

·         Design is iterative; new layers being added as details are uncovered in the pseudo-code.

·         A good designer can "peek" forward to implementation to make sure his design is implementable. This is the reason that great designers are (or were) great implementers.

·         Designs must compile! Messages, variables, and actions must match

·         Designs must work! "Execute" the design and see if interaction diagrams are satisfied.

boolean add(E o)

boolean remove(Object o)

boolean contains(Object o)

boolean isEmpty()

int size()

void add(int index, E element)

int lastIndexOf(Object o)

int indexOf(Object o)

E get(int index)

public enum stateOfCustomer { seated, hasMenu, hasOrdered, servedFood, hasCheck };

stateOfCustomer soc; //declaring a variable of this type.

soc = hasMenu; //assigning to the variable