RETSINA
Plataforma de Agentes CCM
MAS Framework
Equipe do Curso de ES para SMA
{lucena, furtado, choren, viviane}@inf.puc-rio.br
RETSINA
(Reusable Environment for Task Structured
Intelligent Network Agents)
Katia Sycara et al.
Carnegie Mellon University - EUA
O que é RETSINA?
• Uma infra-estrutura que oferece um conjunto de
tipos de agentes que podem ser adaptados para
implementar soluções para domínios específicos
• Propósitos
– Oferecer módulos re-utilizáveis: comunicação,
planejamento, agendamento e monitoramento
– Implementar sistemas como sociedades de entidades que
respondem a pedidos de execução de tarefas
Laboratório de Engenharia de Software (LES) – PUC-Rio
3
Requisitos
• Ambientes abertos e dinâmicos
– Agentes / serviços nem sempre existirão
– Localização dos agentes mudam
• Mobilidade
• Balanceamento de carga
– Identidade dos agentes pode mudar
• Não se pode antever seu nome
– Não se pode antever o vocabulário usado para descrevêlo
Laboratório de Engenharia de Software (LES) – PUC-Rio
4
Outros Requisitos
• Deve-se assumir que existe redundância de serviços
• Fornecedores múltiplos / competidores
– Diferenças nos parâmetros do serviço
– Velocidade
– Preço
– Segurança
– Reputação
Laboratório de Engenharia de Software (LES) – PUC-Rio
5
A Arquitetura dos Agentes RETSINA
Laboratório de Engenharia de Software (LES) – PUC-Rio
6
A Arquitetura dos Agentes RETSINA
• 4 threads paralelas
• Communicator
– Para comunicação com outros agentes
• Planner
– Relaciona entradas "sensoriais" e "crenças" a possíveis planos de ação
• Scheduler
– Agenda planos "habilitados" para execução
• Executor Monitor
– Executa um plano agendado
– Gerencia a execução dos planos (p. ex. troca por plano com maior
prioridade)
Laboratório de Engenharia de Software (LES) – PUC-Rio
7
A Infra-estrutura RETSINA
Laboratório de Engenharia de Software (LES) – PUC-Rio
8
A Infra-estrutura RETSINA
• Ambiente de operação
– Representam os computadores, sistema operacional,
infra-estrutura de rede, etc
– Devem ser totalmente transparentes para os agentes
– RETSINA exite em Java, C++ / para Windows, Linux e
SunOS
• Infraestrutura de comunicação
– Representam os canais de comunicação entre agentes
(camada de transporte)
– Prevê o uso de canais síncronos e assíncronos
– RETSINA usa os agentes Communicator
Laboratório de Engenharia de Software (LES) – PUC-Rio
9
A Infra-estrutura RETSINA
• Infra-estrutura de linguagem
– Representam a linguagem usada nas mensagens trocadas
pelos agentes (FIPA ACL, KQML, etc)
– Deve ser modular e alterável
– RETSINA oferece KQML
• Serviços de gerenciamento
– Representam serviços de instalação de agentes,
monitoramento de balanceamento de carga, log, etc
– Auxiliam o processo de inicialização dos agentes
– RETSINA oferece os serviços Logger, Activity Visualizer e
Launcher
Laboratório de Engenharia de Software (LES) – PUC-Rio
10
A Infra-estrutura RETSINA
• Medidas de performance
– Servem para otimizar a distribuição de tarefas entre os
agentes
– Muito baseado em algoritmos de tempo de resposta
– RETSINA não oferece suporte a performance
• Segurança
– Lida com os problemas de segurança do sistema
– Oferece uma interface para comunicação com
Autoridades de Certificação (?)
– RETSINA sabe falar SSL
Laboratório de Engenharia de Software (LES) – PUC-Rio
11
A Infra-estrutura RETSINA
• Mapeamento de nomes a locais de agentes
– Serve para permitir a busca de um agente pelo seu nome
– RETSINA oferece o ANS (Agent Naming Service) que
permite a atualização dinâmica da localização dos
agentes
• Mapeamento das funcionalidades dos agentes
– Serve para permitir a busca de um agente por sua
funcionalidade
– RETSINA oferece o A-Match
Laboratório de Engenharia de Software (LES) – PUC-Rio
12
A Infra-estrutura RETSINA
• Interoperação
– Serve para fazer a ligação entre um agente e a infraestrutura RETSINA
– Funciona como um broker entre o agente qualquer e o
modelo da arquitetura
– Deve ser desenvolvida pelo programador do agente
– RETSINA oferece os Agentes "Middle"
Laboratório de Engenharia de Software (LES) – PUC-Rio
13
A Arquitetura Funcional do RETSINA
Laboratório de Engenharia de Software (LES) – PUC-Rio
14
Agentes de Interface
• Requisitam entrada do usuário do sistema multiagentes
• Apresentam resultados aos usuários
• Freqüentemente são implementados como uma
parte do agente de tarefa
• Podem representar um device
Laboratório de Engenharia de Software (LES) – PUC-Rio
15
Agentes de Tarefa
• Sabem o que fazer e como fazê-lo
• Responsáveis por delegar tarefas
• Podem requisitar a ajuda de outros agentes de
tarefa
Laboratório de Engenharia de Software (LES) – PUC-Rio
16
Agentes “Middle”
• Agentes de infra-estrutura que ajudam na
escalabilidade do sistema
• Serviços mais comuns
– Serviço de nomes (white pages)
– Matchmaker (yellow pages)
– Broker
Laboratório de Engenharia de Software (LES) – PUC-Rio
17
RETSINA Matchmaker
• Permitem que os agentes encontrem uns aos outros
– Pela funcionalidade, disponibilidade, etc
– Sem saber quem o onde o agente requisitado possa estar
• Permite a reconfiguração dinâmica do sistema
• Ajuda a manter a escalabilidade do sistema
• RETSINA oferece o A-Match
http://www-2.cs.cmu.edu/~softagents/a-match/index.html
Laboratório de Engenharia de Software (LES) – PUC-Rio
18
O Processo de Matching do A-Match
Laboratório de Engenharia de Software (LES) – PUC-Rio
19
Agentes de Informação
• Fazem a interface com as fontes de informação no
sistema
• Normalmente ficam na fronteira entre o sistema e
fontes de dados externas
• Representam dados e eventos
Laboratório de Engenharia de Software (LES) – PUC-Rio
20
Concluindo...
• RETSINA é uma infra-estrutura para o
desenvolvimento de sistemas multi-agentes
• É fechado – não está disponível para download e
testes
• Katia Sycara
– [email protected]
Laboratório de Engenharia de Software (LES) – PUC-Rio
21
Plataforma de Agentes CCM
(ADM – Agent Deplyment Model)
Fábio Melo
LES
O que é a Plataforma de Agentes CCM?
• Uma plataforma para a implementação de sistemas
multi-agentes baseado no CCM (CORBA Compoment
Model)
• Propósito
– Componentização dos agentes
– Uso da infra-estrutura CORBA
Laboratório de Engenharia de Software (LES) – PUC-Rio
23
O CORBA Component Model
• Introduz o conceito de componente (core) e define
suas interfaces
• Define 4 portas: facetas, receptáculos, fontes de
eventos e leitores de eventos
Laboratório de Engenharia de Software (LES) – PUC-Rio
24
O CCM
• Facetas
– Definem as possíveis interfaces que o componente expõe
para os demais componentes da aplicação
– Um componente deve ter uma referência principal e
pode ter diversas facetas que dão suporte a diferentes
interfaces e são encaradas como referências distintas ao
componente
Laboratório de Engenharia de Software (LES) – PUC-Rio
25
O CCM
• Receptáculo
– Define o ponto de relacionamento estático entre
componentes
– Assim, um receptáculo permite que um componente
declare a sua dependência a uma referência
Laboratório de Engenharia de Software (LES) – PUC-Rio
26
O CCM
• Fontes e Leitores de Eventos
– Implementam o mecanismo de interação publishsubscribe
– Um componente é uma fonte de eventos quando declara
seu interesse de publicar (para mais de um destino) ou
emitir (para um único destino) um evento
– Um componente é um leitor de eventos quando tem o
interesse em ser notificado quando um determinado
evento ocorreu
– Fontes e leitores devem estar conectados
Laboratório de Engenharia de Software (LES) – PUC-Rio
27
A Plataforma de Agentes CCM (ADM)
• Baseado no CCM
• Sua definição de agente
– Um agente é uma entidade que, em algum ponto da
execução do sistema, pode fazer atividades, responder a
alguns eventos e gerar alguns eventos novos
Laboratório de Engenharia de Software (LES) – PUC-Rio
28
O Agente é uma Entidade
• Precisa de uma identidade (auto-representação) no
sistema
• O componente core é o responsável por ser o
núcleo do agente
• Armazena a referência principal do agente, seus
atributos e gerencia seu estado
• É responsável ainda pelo reasoning do agente,
tratamento de mensagens e gerenciamento de
planos
Laboratório de Engenharia de Software (LES) – PUC-Rio
29
O Agente faz Atividades
• Atividades são implementadas por planos de ação
(componentes plano)
• Deve-se definir componentes que serão os planos
dos agentes
• Estes componentes serão ligados ao core do agente
através dos receptáculos
Laboratório de Engenharia de Software (LES) – PUC-Rio
30
O Agente responde e gera Eventos
• As interfaces usadas para o envio e a recepção de
eventos (mensagens) são as fontes e os leitores
• Já modelam interações assíncronas por natureza
(derivado do modelo CORBA)
• Faz a ligação direta entre agentes que se
comunicam
Laboratório de Engenharia de Software (LES) – PUC-Rio
31
Os Componentes Não-agentes
• Os componentes não-agentes (recursos/objetos) do
sistema são implementados diretamente como
interfaces ou struts (do CCM)
• -- FALAR MAIS AQUI
Laboratório de Engenharia de Software (LES) – PUC-Rio
32
Generalizando para Organizações
• O modelo apresentado serve para implementar um
único agente
• Uma organização é implementada como um agente
– O core identifica a organização
– Os agentes da organização estão em seus receptáculos
– A comunicação entre agentes dentro de uma mesma
organização é feita diretamente entre suas fontes e
leitores
– A comunicação entre agentes de organizações diferentes
é feita através das fontes e leitores da organização
Laboratório de Engenharia de Software (LES) – PUC-Rio
33
Vantagens do uso de CCM
• Re-uso
– Por exemplo de planos já que são implementados como
componentes isolados
• Adaptação dinâmica
– Um agente pode se adaptar ao incluir ou remover planos
de seus receptáculos
• Modelo de comunicação
– Publish-subscribe que é assíncrono e não impõe uma
linguagem de comunicação
Laboratório de Engenharia de Software (LES) – PUC-Rio
34
Outras Vantagens
• Características inerentes do CCM
– Segurança
– Persistência
– Gerenciamento de transações
– Funções administrativas feitas pelo modelo
• Registro
• Localização
Laboratório de Engenharia de Software (LES) – PUC-Rio
35
Exemplo de Implementação usando ADM
• Sistema de marketplace
• Rodadas de negociação
– Anúncio de produtos
– Formação de grupos
– Lances
– Completar ou desistir da negociação
• Modelado com o ANote
– Diagramas de Agente, Planejamento, Interação e
Ontologia mapeados para o ADM
Laboratório de Engenharia de Software (LES) – PUC-Rio
36
Exemplo de Implementação usando ADM
• Classes de Agentes implementadas como
especializações do componente core
• Planos implementados como especializações do
componente plano
• Interações implementados como fontes e leitores
• Recursos implementados como interfaces ou struts
• Organizações implementados como agentes
Laboratório de Engenharia de Software (LES) – PUC-Rio
37
Exemplo de Implementação usando ADM
Laboratório de Engenharia de Software (LES) – PUC-Rio
38
Exemplo de Implementação usando ADM
Laboratório de Engenharia de Software (LES) – PUC-Rio
39
Exemplo de Implementação usando ADM
Laboratório de Engenharia de Software (LES) – PUC-Rio
40
Exemplo de Implementação usando ADM
Laboratório de Engenharia de Software (LES) – PUC-Rio
41
Exemplo de Implementação usando ADM
• Componente core  extensão da interface IAgent
– Cria todas as características do agente como start up,
instanciação de planos e envio de mensagens
Laboratório de Engenharia de Software (LES) – PUC-Rio
42
Exemplo de Implementação usando ADM
• Componente plano  extensão da interface IPlan
– Definicção do método que implementa o plano
– Deve ter uma referência para o componente core de
todos os agentes que podem executá-lo
Laboratório de Engenharia de Software (LES) – PUC-Rio
43
Exemplo de Implementação usando ADM
• Mensagem  evento
• Recurso  struct (ou interface)
Laboratório de Engenharia de Software (LES) – PUC-Rio
44
Concluindo...
• O ADM é uma plataforma para o desenvolvimento
de sistemas multi-agentes
– Implementa o modelo CCM
– Um agente
• Componente core
• Componentes planos
• Fontes e leitores de envetos
– Uma organização
• Como um agente
– Recursos (itens não-agentes)
• Interfaces ou struts
Laboratório de Engenharia de Software (LES) – PUC-Rio
45
MAS Framework
José Alberto Sardinha
LEARN
O que é MAS Framework?
• Um framework orientado a objetos para a
construção de aplicações baseadas em agentes
• Sistemas multi-agentes em ambiente distribuídos
• Propósitos
– Acelera o desenvolvimento de aplicações
– Faz re-uso de código
– Reduz a complexidade de desenvolvimento de sistemas
baseados em agentes
Laboratório de Engenharia de Software (LES) – PUC-Rio
47
Motivação
• Inicialmente o MAS Framework foi desenvolvido
influenciado pela metodologia GAIA
– Definição de papéis de agentes
– Divisão entre protocolos de interação e serviços
• Evoluiu para um framework de agentes distribuídos
de propósito geral
– Papéis/tipos de agentes definidos através de herança
– Infra-estrutura de comunicação baseada no IBM TSpaces
Laboratório de Engenharia de Software (LES) – PUC-Rio
48
O MAS Framework
• É composto por
– Uma classe abstrata
• Agent
– Duas classes públicas
• AgentCommunicationLayer
• ProcessMessageThread
– Quatro interfaces
• AgentInterface
• InteractionProtocols
• AgentMessage
• AgentBlackboardInfo
Laboratório de Engenharia de Software (LES) – PUC-Rio
49
O MAS Framework
Callback
AgentCom municatio nLayer
-listeners:Vector=new Vector()
-host:String
-msgTSName:String
-msgTS:TupleSpace
-blackboardTSName:String
-blackboardTS:TupleSpace
-seqNumEventReg:int
-name:String
ip:InteractionProtocols
Thread
ProcessMessageThread
1
0..*
java.io.Serializable
interface
A gentMessage
-agentMsgPtr:AgentMessage
-ip:InteractionProtocols
+ProcessMessageThread(agMsg:AgentMessage,ipTemp:InteractionProtocols)
+run():void
0..*
1
interface
+AgentCommunicationLayer(hostTemp:String,nameTemp:String,ipTemp:InteractionProtocols)
I nteracti onProtocol s
+addAgentBroadcastListener(AgentName:String):void
1
+blockingReadBBInfo(key:String):AgentBlackboardInfo
+blockingTakeBBInfo(key:String):AgentBlackboardInfo
+processMsg(msg:AgentMessage):void
+call(eventName:String,tsName:String,seqNum:int,tuple:SuperTuple,isException:boolean):boolean
+deleteAllBB():void
1
-initBlackboard():void
+readBBInfo(key:String):AgentBlackboardInfo
-registerCallBack():void
+removeAgentBroadcastListener(AgentName:String):void
1
+removeBBInfo(key:String):void
A gent
+removeBBInfo(key1:String,key2:String):void
+scanBBInfo(key:String):Tuple
+traceLevel:int=0
+scanBBInfo(key1:String,key2:String):Tuple
-runnit:Thread
+sendBBInfo(key1:String,key2:String,info:AgentBlackboardInfo):void
+sendBBInfo(key:String,info:AgentBlackboardInfo):void
1
1
+sendBroadcast(msg:AgentMessage):void
+sendMsg(agentName:String,msg:AgentMessage):void
+stopCommunicationLayer():void
+Agent(nameTemp:String)
+initialize():void
+process(ag:AgentInterface):void
+stopAgent():void
+terminate():void
+trace(msg:String):void
1
0..*
java.io.Serializable
interface
A gentBl ackboardI nfo
Runnable
interface
1 A gentInter face
+run():void
name:String
Laboratório de Engenharia de Software (LES) – PUC-Rio
50
A Classe Agent
• Classe abstrata que define o template dos agentes
da aplicação
• Define o nome de um agente
• Método initialize
– Responsável pelo código de inicialização do agente
• Método terminate
– Responsável pelo código de terminação do agente
• Métodos process e stopAgent
– Responsáveis por iniciar e parar a execução de serviços
do agente
Laboratório de Engenharia de Software (LES) – PUC-Rio
51
A Interface AgentInterface
• Responsável por fazer as subclasses de Agent
virarem threads
• Suas classes concretas devem implementar o
método run que é responsável por iniciar as
atividades (serviços) privados dos agentes
Laboratório de Engenharia de Software (LES) – PUC-Rio
52
A Interface InteractionProtocols
• É a interface que define como um agente irá se
comunicar com os demais agentes da organização
• Todo código relativo à interação entre agentes deve
ser colocado em sua classe concreta
• Sua classe concreta também deve implementar o
método processMsg que é chamado toda vez que o
agente receber uma mensagem
Laboratório de Engenharia de Software (LES) – PUC-Rio
53
As Interfaces AgentMessage e AgentBlackboardInfo
• A classe concreta de AgentMessage deve definir o
formato das mensagens usadas no sistema
• A classe concreta de AgentBlackboardInfo deve
definir o formato das mensagens usadas no
blackboard TSpaces
• Assim, todas as informações necessárias para a
comunicação dos agentes com o blackboard de
interação fica encapsulada nestas duas classes
Laboratório de Engenharia de Software (LES) – PUC-Rio
54
A Classe ProcessMessageThread
• É a classe responsável por fazer o tratamento das
mensagens recebidas por um agente
• O que ela faz
– Cria uma nova thread para o tratamento de uma
mensagem
– Este thread chamará o método processMsg (da classe
concreta de InteractionProtocols)
Laboratório de Engenharia de Software (LES) – PUC-Rio
55
A Classe AgentCommunicationLayer
• Classe que implementa as funcionalidades de uso
do blackboard TSpaces
• addAgentBroadcastListener
– Adiciona um agente a um grupo de receptores de
broadcast
• blockingReadBBInfo
– Usado para ler uma informação do blackboard. Se a
informação ainda não está no blackboard quando este
método for executado, a aplicação pára a sua espera
Laboratório de Engenharia de Software (LES) – PUC-Rio
56
A Classe AgentCommunicationLayer
• blockingTakeBBInfo
– Usado para retirar uma informação do blackboard. Da
mesma forma que blockingReadBBInfo, se a informação
ainda não está no blackboard, a aplicação pára
• deleteAllBB
– Usado para remover toda informação do blackboard
• removeAgentBroadcastListener
– Remove um agente de um grupo de receptores de
broadcast
Laboratório de Engenharia de Software (LES) – PUC-Rio
57
A Classe AgentCommunicationLayer
• removeBBInfo
– Remove uma informação do blackboard
• scanBBInfo
– Procura uma informação (definida atravé de uma query)
no blackboard
• sendBBInfo
– Envia uma informação para o blackboard
Laboratório de Engenharia de Software (LES) – PUC-Rio
58
A Classe AgentCommunicationLayer
• sendBroadcast
– Envia uma mensagem para os agentes registrados no
grupo de receptores de broadcast
• sendMsg
– Envia uma mensagem para um agente
• stopCommunicationLayer
– Pára o serviço blackboard
Laboratório de Engenharia de Software (LES) – PUC-Rio
59
Hot e Frozen Spots
• Hot Spots
– Agent
– AgentMessage
– AgentBlackboardInfo
– InteractionProtocols
– AgentInterface
• Frozen Spots
– AgentCommunicationLayer
– ProcessMessageThread
Laboratório de Engenharia de Software (LES) – PUC-Rio
60
Instanciando o MAS Framework
• Para cada agente deve-se
– Criar duas classes
– Uma que herda da classe abstrata Agent
– Esta classe deve ainda implementar a interface
AgentInterface
– Outra que implementa a interface InteractionProtocols
Laboratório de Engenharia de Software (LES) – PUC-Rio
61
Exemplo de Instanciação
Laboratório de Engenharia de Software (LES) – PUC-Rio
62
Callback
AgentCom municatio nLayer
-listeners:Vector=new Vector()
-host:String
-msgTSName:String
-msgTS:TupleSpace
-blackboardTSName:String
-blackboardTS:TupleSpace
-seqNumEventReg:int
-name:String
ip:InteractionProtocols
Thread
ProcessMessageThread
1
0..*
java.io.Serializable
interface
A gentMessage
-agentMsgPtr:AgentMessage
-ip:InteractionProtocols
+ProcessMessageThread(agMsg:AgentMessage,ipTemp:InteractionProtocols)
+run():void
0..*
1
interface
+AgentCommunicationLayer(hostTemp:String,nameTemp:String,ipTemp:InteractionProtocols)
I nteracti onProtocol s
+addAgentBroadcastListener(AgentName:String):void
1
+blockingReadBBInfo(key:String):AgentBlackboardInfo
+blockingTakeBBInfo(key:String):AgentBlackboardInfo
+processMsg(msg:AgentMessage):void
+call(eventName:String,tsName:String,seqNum:int,tuple:SuperTuple,isException:boolean):boolean
+deleteAllBB():void
1
-initBlackboard():void
+readBBInfo(key:String):AgentBlackboardInfo
-registerCallBack():void
+removeAgentBroadcastListener(AgentName:String):void
1
+removeBBInfo(key:String):void
A gent
+removeBBInfo(key1:String,key2:String):void
+scanBBInfo(key:String):Tuple
+traceLevel:int=0
+scanBBInfo(key1:String,key2:String):Tuple
-runnit:Thread
+sendBBInfo(key1:String,key2:String,info:AgentBlackboardInfo):void
+sendBBInfo(key:String,info:AgentBlackboardInfo):void
1
1
+Agent(nameTemp:String)
+sendBroadcast(msg:AgentMessage):void
+sendMsg(agentName:String,msg:AgentMessage):void +initialize():void
+process(ag:AgentInterface):void
+stopCommunicationLayer():void
+stopAgent():void
+terminate():void
+trace(msg:String):void
1
0..*
java.io.Serializable
interface
A gentBl ackboardI nfo
Runnable
interface
1 A gentInter face
+run():void
name:String
AgentBuyer
itemsEncountered:Vector
buyProfile:Hashtable
user:Hashtable
agentUserName:String
agentBuyerName:String
buyProfileName:Message
buyProfileMsg:Profile
negotiationParameters:Hashtable
proposal:Hashtable
closedProposal:Hashtable
itemsNegotiated:Vector
transactionItem:Hashtable
newValue:Double
negotiationParameterList:Vector
idadd:String
transactionItem:String
agBuyerIP:AgentBuyerIP
Laboratório de Engenharia de Software (LES) – PUC-Rio
AgentBuyerIP
aclAgBuyer:AgentCommunicationLayer
agBuyer:AgentBuyer
+AgentBuyerIP(name:String)
+informListEncounteredItems(itemsEncountered:Vector):Vector
+sendNegotiationParameters(proposal:Hashtable):Hashtable
+negotiate():void
+sendCounterProposal():void
+sendUserMsg():void
+sendNegotiationResult(itemsNegotiated:Vector):Vector
+terminateBuying(transactionItem:Hashtable):String
+informTermination():void
+informTimeExpired():void
+processMsg(msg:AgentMessage):void
+AgentBuyer(name:String)
+initialize():void
+run():void
+terminate():void
+trace(msg:String):void
+findItem(buyProfile:Vector):Vector
+evaluateReceivedProposal(proposal:Hashtable):Hashtable
63
Exemplo de Instanciação
import masframework.*;
public class Agent1 extends Agent implements AgentInterface {
private boolean alive;
public Agent1(String _name,
InteractionProtocols _interactionProtocols){
super(_name,_interactionProtocols);
}
public void initialize() {
alive = true;
}
public void terminate() {
alive = false;
}
public void trace(String msg, int level) {
System.out.println(msg);
}
Laboratório de Engenharia de Software (LES) – PUC-Rio
64
Exemplo de Instanciação
// Seqüência de Agent1
public void run() {
while(alive) {
try {
trace("Agent1: executando", 1);
((Agent1IP)getInteractionProtocols()).sendMsgAgent2();
Thread.sleep(2000);
}
catch(Exception e){
System.out.println("Erro!");
}
}
}
}
Laboratório de Engenharia de Software (LES) – PUC-Rio
65
Exemplo de Instanciação
import masframework.*;
public class Agent1IP extends InteractionProtocols {
public void processMsg(AgentMessage msg) {
}
public void sendMsgAgent2() {
SimpleMessage msg = new SimpleMessage();
msg.content = "Oi";
getAgCommLayer().sendMsg("Agent2",msg);
}
}
Laboratório de Engenharia de Software (LES) – PUC-Rio
66
Exemplo de Instanciação
import masframework.*;
public class Agent2 extends Agent implements AgentInterface {
private boolean alive;
public Agent2(String _name,
InteractionProtocols _interactionProtocols) {
super(_name, _interactionProtocols);
}
public void initialize() {
alive = true;
}
public void terminate() {
alive = false;
}
public void trace(String msg, int level) {
System.out.println(msg);
}
Laboratório de Engenharia de Software (LES) – PUC-Rio
67
Exemplo de Instanciação
// Seqüência de Agent2
public void run() {
while(alive) {
try{
trace("Agent2: running",1);
Thread.sleep(2000);
}
catch(Exception e){
System.out.println("Erro!");
}
}
}
}
Laboratório de Engenharia de Software (LES) – PUC-Rio
68
Exemplo de Instanciação
import masframework.*;
public class Agent2IP extends InteractionProtocols {
public void processMsg(AgentMessage msg) {
SimpleMessage simpleMessage = (SimpleMessage) msg;
System.out.println("Mensagem recebida = " +
simpleMessage.content);
}
}
import masframework.AgentMessage;
public class SimpleMessage implements AgentMessage {
String content;
public SimpleMessage() {
super();
}
}
Laboratório de Engenharia de Software (LES) – PUC-Rio
69
Exemplo de Instanciação
import masframework.*;
public class Environment {
public static void main(String[] args) {
// Cria o Agente 1
Agent1IP ag1IP = new Agent1IP();
AgentCommunicationLayer acl1 = new AgentCommunicationLayer(
"localhost", "Agent1", ag1IP);
ag1IP.setAgCommLayer(acl1);
Agent1 ag1 = new Agent1("Agent1",ag1IP);
// Cria o Agente 2
Agent2IP ag2IP = new Agent2IP();
AgentCommunicationLayer acl2 = new AgentCommunicationLayer(
"localhost", "Agent2", ag2IP);
ag2IP.setAgCommLayer(acl2);
Agent2 ag2 = new Agent2("Agent2", ag2IP);
Laboratório de Engenharia de Software (LES) – PUC-Rio
70
Exemplo de Instanciação
// Seqüência de Environment
// Inicia os agentes
ag1.process(ag1);
ag2.process(ag2);
}
}
Laboratório de Engenharia de Software (LES) – PUC-Rio
71
Exemplo de Instanciação
• Copiar a SimpleMessage.class para o diretório de
classes do TSpaces
<%TSPACES_HOME%>\classes
• Iniciar o TSpaces
• Executar o Environment.class
Laboratório de Engenharia de Software (LES) – PUC-Rio
72
Exemplo de Instanciação
Laboratório de Engenharia de Software (LES) – PUC-Rio
73
Exemplo de Instanciação
Laboratório de Engenharia de Software (LES) – PUC-Rio
74
Concluindo...
• O MAS Framework é um framework para o
desenvolvimento de sistemas multi-agentes
– Possui classes para implementar agentes e suas
interações
– Um agente
• Extensão de Agent
• Implementação de InteractionProtocols
– Infra-estrutura de comunicação
• Baseada no IBM TSpaces
Laboratório de Engenharia de Software (LES) – PUC-Rio
75
Laboratório de Engenharia de Software (LES) – PUC-Rio
76