GPGP2 Tutorial

I gave a tutorial on GPGP2 to the MASL group on Feburary 3rd, 1999. The content is based on the hand-made slides I used in that tutorial, plus some additional annotations. It is assumed that the audience is generally familiar with the Java Agent Framework, the MASS simulator, the FSMCC tool, and GPGP family of coordination mechanisms from the previous tutorials. Some changes were made to the system since, but the information here is still applicable.

Overview: How To Make Coordination Bean

• No (new) tools to learn! Everything here falls within the JAF framework.

• Just a programming model to follow! The purpose is to (1) make the software process simple and easy to understand to others (2) make the software modular and extensible.

  Nothing prevents you from diverging from this model (yep, it is all a matter of programming), but be aware that you risk the chance that people having difficult time following you. To follow the interfaces described here does incur some extra effort when you try to build your own bean, but once you are familiar to the process, you will feel the design natural to you. Of course, there are possible improvements to this design, and comments are welcome!

• Basic Steps: there are 4 steps:
  

1. Protocol Design

The first step -- protocol design -- involves no programming, but does require that you are familiar with the programming model describe here. Basically, you want to specify the types of messages, events you may send/receive; and how the states evolve based on the messages/events.

Protocol design is delicate work. Actually, this step should take most thinking. A graph representation of FSM may be intuitive to understand, but a table detailing all the combination of states and actions can force you to think rigorously and prevent you from missing details.

Example: the ContractNet protocol.

2. Writing The Scripts is Easy!

A script consists the following parts ... pretty much the same way you specify a FSM. The exact format is described in the FSMCC guide, here I gave a quick view of how to wirte the script.

The guideline here is that the script itself is quite symbolic --- which means that the FSM only specify the messages and events to be received or transmitted, while the analysis, or handling of the events and messages are not specified in the FSM scripts.

A script specifies:

• the set of states
• starting states: a non-empty subset of the states
• finishing states: a subset of states, could be empty set
• transition rules: a transition rule include the following parts
  • from state
  • firing condition -- typical conditions are (one or more of):
    (1) received an event (CoordinationEvent from the coordination bean)
    (2) received a message (KQMLMessage from a FSM in another agent)
    (3) timeout

    typically, conditions will be specified as a function that returns a boolean value. The function itself will be implemented in the Java code section.

  • action -- typical actions include (one or more of):
    (1) start a timer
    (2) send an event (a new CoordinationEvent to the coordination bean)
    (3) send a message (a KQMLMessage to a FSM in another agent)
    (4) no-op (perform no action, just change the state)

    similar to conditions, actions are typically specified as a function call (return value is not important, void is okay). Again, the function is to be defined later in the Java code section.

  • to state
• Java code:
  • variables: private class members
  • functions: there are two types of functions, one type is for customizing this FSM (so that it identifies itself and differentiate from other FSMs); and the other type is for implementing the conditions and actions (the functions used in the transitions) -- these functions typically is called to decide the type and content of the messages and events, and thus often involve some private class variables ...
  • inheritance: remember each script will be transformed into a Java source file (a new subclass of FSM), so each script need to specify the one class it is extending.

---