Patterns of agents

Massimo CossentinoMassimo Cossentino, Luca Sabatucci

ICAR/CNR High performance computing and networks instituteItalian National Research Council

The Goal of This Work

We aim to drastically affect the cost of developing a multi-agent application.

But… it is not easy to achieve this goal without simplifying the problem.

We decided of using FIPA-compliant platforms and this reduces effectively the dimension of the problem (almost all of these platforms are JAVA-based and have a similar structure).

By now we refer to two different platforms: FIPA-OS and JADE

Difference in implementing a simple agent behavior in FIPA-OS and JADE

FIPAOSAgent

ComponentAgent

ComponentAgent()setup()shutdown()

<<Agent>>

Task

ComponentTask1

ComponentTask1()startTask()done()

<<Task>>

ComponentTask2

ComponentTask2()startTask()

<<Task>>

ComponentAgent

setup

shutdown

ComponentTask1

startTask

done

ComponentTask2

startTask

ComponentTask2ComponentTask1ComponentAgent

Agent

ComponentAgent

ComponentAgent()setup()

<<Agent>>

Behaviour

ComponentTask1

ComponentTask1()action()done()

<<Task>>ComponentTask2

ComponentTask2()action()done()

<<Task>>

setup

ComponentAgent

ComponentTask1

action

done

ComponentTask2

action

done

ComponentTask2ComponentTask1ComponentAgent

FIPA-OS

JADE

FIPA-OS

JADE

Different use of the done method in the two platformsSame structure of behaviors but different name of methods

Constructor and setup methodin both the platformsShutdown method in FIPA-OS only

What is a pattern

Christopher Alexander* definition:

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”

*C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. A pattern language. Oxford Univ. Press, New York, 1977

OO Patterns classification

E. Gamma and R. Helm and R. Johnson and J. Vlissides - "Design Patterns Elements of Reusable Object Oriented Software“ - "Addison-Wesley", 1994

According to Gamma *, patterns can be classified using two criteria: • Purpose: what the pattern does. They can belong to the following

categories:• creational (dealing with the process of object creation), • structural (dealing with the composition of classes and objects) or • behavioural (describing the interactions of classes/objects)

patterns. • Scope: classification is directed to separate patterns that apply to

classes or object. • Class patterns deal with the relationships among classes (usually

structural, for example inheritance), • Object patterns include relationships among object (usually

dynamic and established at runtime).

AO patterns classification

Lind1 classifies agent-oriented patterns in accordance to the views defined by the author in the MASSIVE methodology.

Categories reported in this work are: Interaction, Role, Architecture, Society, System, Task, and Environment.

Aridor2 clusters patterns in these categories: traveling (dealing with agent mobility issues), task (regarding the breakdown of agents tasks and the

delegation of them from one agent to another) interaction (dealing with agents communications)

categories.

(1) Jurgen Lind, "Patterns in Agent-Oriented Software Engineering", in Proc. Of AOSE Workshop at AAMAS 2002. July 2002, Bologna(Italy)

(2) Y. Aridor and D. B. Lange, "Agent Design Patterns: Elements of Agent Application Design", in Proc. Of the Autonomous Agents '98 Conf., 1998.

Our concept of patterns

We consider a pattern of agent as composed of its design level description and the corresponding JAVA code.

More in detail each pattern is composed of: A structure

Usually a base agent class and a set of task/behavior classes. Described using UML class diagrams

A behavior Expressed by the agent using its structural elements Detailed in UML dynamic diagrams (activity/state chart

diagrams) A portion of code

Some lines of code implementing the structure and behavior described in the previous diagram

The proposed AO classification

We think that: the basic duality (structure/dynamics) that exists in software is

captured by the Gamma's approach we also consider the importance of enriching it in order to fit the

specific context (agents not objects). We classify the patterns using two main criteria (like in

Gamma et al.) and include agent specific subcategories in them.

Classification Criteria: Application context: it regards the structural aspects of the

pattern, whether it is to be applied to one agent, more agents or to their composing elements (tasks/behaviors).

Functionality: it regards the functional/behavioral aspects of the pattern.

Application Context patterns category

Sub-categories:

Action patterns. They address a functionality of the system; for instance they can be implemented as a method of either an agent class or a task class.

Behavior patterns. They address a specific behavior of an agent; we can look at each of them as a collection of actions.

Component patterns. They are entire agent patterns; these patterns propose a solution composed of the entire structure of an agent together with its tasks.

Service pattern. Concerned about the collaborations between two or more agents; they can be thought as an aggregation of component patterns.

Functionality patterns category

Sub-categories:

Access to local resources. They deal with information retrieval and manipulation of data source.

Communication. They represent the solution to the problem of making two agents communicate by an interaction protocol.

Elaboration. They are used to deal with the agent's functionality devoted to perform some kind of elaboration on its knowledge.

Mobility. These patterns describe the possibility for an agent to move from a platform to another

Patterns in our repository

Patterns documentation Name

The name of the pattern Classification

The classification of the pattern according to the categories reported in the previous slides

Intent A description of what the pattern does and its rationale and intent

Motivation A scenario that illustrates a design problem and how the agents and their

tasks in the pattern solve the problem. Pre-conditions

The initial situation in which the pattern can be applied. Post-conditions

The consequences of the application of the pattern: what changes the pattern introduces into the system

Structure A graphical representation of the structure of the agent and its tasks

(usually done with a class diagram)

Patterns documentation

Participants A description of the agents involved in the pattern and their roles

Collaborations A (graphical) representation of the collaborations of the agents

involved in the pattern (if any) Implementation availability

Availability of the implementation code for the FIPA-OS/JADE platforms. Availability of the UML diagrams of the solution (XMI) for importing them in the existing system design

Implementation description Comments on the most significant code fragments to illustrate the

pattern implementation in the specific agent platforms Implementation Code

FIPA-OS/JADE code of the solution Related Patterns

Patterns that should be used in conjunction with this one

The phases of the pattern production/reuse process

Meta-pattern XSLT platformspecialization

XSL rules

pattern constraintsresolver

Constraints

+Java

skeleton

Action pattern

Java agentcomplete code

ClassDiagram(s)

ActivityDiagram

XSLT

Multi-Platform Representation Platform-Specific Representation

Design

Representation

UML XML JAVA

The design level representation of the pattern

Meta-pattern XSLT platformspecialization

XSL rules

pattern constraintsresolver

Constraints

+Java

skeleton

Action pattern

Java agentcomplete code

ClassDiagram(s)

ActivityDiagram

DesignRepresentation

UML

XSLT

Design level representation of the pattern using UML class and activity

diagrams

…

constructor

setup

startTask

constructor

new Task

handleInform

constructor

setup

constructornew Task

startTask

handleQueryIf

message()

constructornew Task

startTask

new Agent new Agent

QueryReplyTaskListenerQueryParticipantAgentQueryTaskQueryInitiatorAgent

Listener

constructor()start()handleQueryIf()

AgentShell

QueryParticipant

constructor()setup()shutdown()

TaskShell

QueryReply Task

constructor()start()sendInform()sendRefuse()

QueryInitiator

constructor()setup()shutdown()

QueryTask

constructor()start()handleRefuse()handleInform()

TaskShellAgentShell

QueryInitiator Agent QueryParticipant Agent

QueryReceiveTask

The XML meta-pattern representation

Meta-pattern XSLT platformspecialization

XSL rules

pattern constraintsresolver

Constraints

+Java

skeleton

Action pattern

Java agentcomplete code

ClassDiagram(s)

ActivityDiagram

DesignRepresentation

UML

XSLT

• Meta-patterns are platform independent

• Meta-patterns contain all the common elements of patterns for different MA platforms

…

Multi-Platform Representation

XML

+AgentConstructor()+AgentSetup()+Shutdow n()

«Agent»QueryInitiator

+TaskConstructor(in Conversation)+TaskSetup()+handleRefuse(in Conversation)+handleInform(in Conversation)

«Task/Behavior»QueryReceiveTask

<Agent name="QueryInitiator"> <Visibility>public</Visibility>

<ExtendsAgentShell/> <AgentConstructor>

<Code>constructor@generic_agent</Code> </AgentConstructor>

<AgentSetup> <Code>setup@generic_agent</Code> </AgentSetup><Shutdown> <Code>shutdown@generic_agent</Code> </Shutdown><Task name="QueryReceiveTask "> <Visibility>public</Visibility> <ExtendsTaskShell/> <TaskConstructor>

<Argoment type="Conversation" name="conv"/><Code>constructor@query_initiator_task</Code>

</TaskConstructor> <TaskSetup> <Code>setup@query_initiator_task</Code>

</TaskSetup> <Method name="handleRefuse" type="void"> <Visibility>public</Visibility> <Argoment type="Conversation" name="conv"/>

<Code>handle_refuse@query_initiator_task</Code>

</Method>

From meta-patterns to patterns – XSL rules

Meta-pattern XSLT platformspecialization

XSL rules

pattern constraintsresolver

Constraints

+Java

skeleton

Action pattern

Java agentcomplete code

ClassDiagram(s)

ActivityDiagram

DesignRepresentation

UML

XSLT

• Each pattern is specific for one of the selected platforms.

• In order to obtain a FIPA-OS pattern we apply to the meta-pattern the XSLT transformation shown on the right

…

<!—FIPA-OS SPECIFIC TRANSFORMATION-><xsl:template match="ExtendsAgentShell"> <Extends>FIPAOSAgent</Extends></xsl:template><xsl:template match="AgentConstructor"> <Constructor name="{parent::*/@name}"> <Visibility>public</Visibility> <Argument type="String" name="platform"> </Argument> <Argument type="String" name="name"> </Argument> <Argument type="String" name=“ownership"> </Argument> <xsl:copy-of select="Code" /> </Constructor></xsl:template><xsl:template match="AgentSetup"> <Method name="setup" type="void"> <Visibility>private</Visibility> <xsl:copy-of select="Code" /> …

Multi-Platform Representation

XML

From meta-patterns to patterns

Meta-pattern XSLT platformspecialization

XSL rules

pattern constraintsresolver

Constraints

+Java

skeleton

Action pattern

Java agentcomplete code

ClassDiagram(s)

ActivityDiagram

DesignRepresentation

UML

XSLT

• The resulting pattern is localized to a specific platform

• The pattern is still general and can be customized for the specific application

…

Multi-Platform Representation

XML

+constructor(in platform : String, in name : String, in ow nership : String)+setup()+shutdow n()

«FIPAOSAgent»QueryInitiator

+AgentConstructor()+AgentSetup()+Shutdow n()

«Agent»QueryInitiator

Meta-pattern

Pattern

XSL Transformation

<Agent_description agent_system="FIPAOS"> <Agent name="QueryInitiator"> <Visibility>public</Visibility> <Extends>FIPAOSAgent</Extends> <Constructor> <Visibility>public</Visibility> <Argoment type="String" name="platform"/> <Argoment type="String" name="name"/> <Argoment type="String" name="ownership"/> <Code>constructor@generic_agent</Code> </Constructor> <Method name="setup" type="void"> <Visibility>public</Visibility> <Code>setup@generic_agent</Code> </Method>…

Patterns introduction in the project generates constraints

When a pattern is applied to a project, it modifies the context in which it is placed (introducing new functionality into the system)

The relationship between the pattern and existing elements could be expressed with a constraint.

A constraint is a rule composed of three elements:

A target that specifies what agent/task will be influenced by the rule.

A platform that specifies which is the application context (FIPA-OS or JADE)

A content that expresses the changes to be applied when the pattern is inserted into the project (it could be an aggregation of attributes, constructors or methods).

An example in FIPA-OS:

When we insert a communication task pattern into an existing agent, the listener task (IdleTask) should have a handleX method to catch performative acts of a particular type (i.e. QueryIf, Request, Inform, …)

IdleTask

constructor()startTask()handleQueryIf()

AgentShell

QueryParticipant

constructor()setup()shutdown()

TaskShell

QueryReply Task

constructor()startTask()sendInform()sendRefuse()

Constraints

Meta-pattern XSLT platformspecialization

XSL rules

pattern constraintsresolver

Constraints

+Java

skeleton

Action pattern

Java agentcomplete code

ClassDiagram(s)

ActivityDiagram

XSLT …

Multi-Platform Representation Platform-Specific Representation

Design

Representation

UML XML JAVA

From the previous example: here we have the constraint used to introduce the handleQueryIf method in the IdleTask class of a FIPA-OS agent

<Constraint> <Idle_task platform="FIPAOS"> <Method name="handleQueryIf" type="void"> <Visibility>public</Visibility> <Argument type="Conversation" name="conv"/>

<Code>a_function</Code> </Method> </Parent_task></Constraint>…

From skeleton of classes to complete code

With the previous steps we obtained a skeleton of the agent with its tasks/behaviors that is complete down to the method interfaces of each class

In order to (partially) fill the skeleton with the remaining code, action patterns are applied.

An action pattern is a portion of JAVA code realizing some kind of behavior. It is specific for each platform.

For example the registration to the DF service (Directory Facilitator, the yellow pages of the platform) it is part of the setup@generic_agent action pattern and it is introduced in the setup method of the agent

Action patterns are stored in a database of pieces of code and the correct one for each method is selected referring to the value of the Code tag for the specific module (see the XML pattern representation)

Constraints

Meta-pattern XSLT platformspecialization

XSL rules

pattern constraintsresolver

Constraints

+Java

skeleton

Action pattern

Java agentcomplete code

ClassDiagram(s)

ActivityDiagram

XSLT

try { registerWithDF( AGENT_TYPE ); DIAGNOSTICS.println("Registered with DF", this,DIAGNOSTICS.LEVEL_MAX );}catch (DFRegistrationException dfre) { DIAGNOSTICS.println(dfre, this, DIAGNOSTICS.LEVEL_MAX ); String reason = dfre.getExceptionReason(); if ( reason == null || !reason.equals(FIPAMANCONSTANTS. AGENT_ALREADY_REGISTERED) ) { shutdown(); return; } } …

The action pattern for the setup method of a generic

FIPA-OS agent

Multi-Platform Representation Platform-Specific Representation

Design

Representation

UML XML JAVA

The AgentFactory web application

Screenshots

Create a new multi agent system

Select the agent platform (FIPA-OS or Agent)

Screenshots

Add a component pattern to the MAS

Select the Generic Agent pattern

Screenshots

Static, dynamic structure of the pattern and tree representation of the system

Screenshots

Add a behaviour pattern to ‘myTask’

Select the FIPA Query Initiator pattern

Screenshots

Static structure of the FIPA Query Initiator pattern

Select the previously created agent from the list

Screenshots

The result of the pattern application: the agent structure, the automatically generated code…

Screenshots

… the static structure and the dynamic behavior

Conclusions and future works

Conclusions and future works

Experimental results are encouraging but the amount of code automatically produced depends on the dimension of the pattern repository

It is difficult to synchronize the DB of patterns for many different platforms

An high level representation of patterns is needed in order to facilitate reuse in early stages of design processes