Ambientes em Sistemas Multi-agentes

Notas de estudo sobre Ambientes
por
Nécio de Lima Veras

Referência básica:
Environment programming in multi-agent
systems: an artifcat-based perspective (2011).
By
Alessando Ricci
Michele Piunti
Mirko Viroli
Dados da publicação:
Autonomous Agents and Multi-Agent Systems
Vol. 23 num. 2 ano 2011
DOI: 10.1007/s10458-010-9140-7

Objetivo
Estes slides objetivam documentar um estudo
sobre a concepção e programação de ambientes
para sistemas multi-agentes, assim como
também para obter uma fundamentação mínima
necessária para se conseguir um primeiro
contato com o software CArtAgO.

Agenda
● Introdução
● Programando Ambiente em sistemas multi-
agente
● Ambientes baseados em artefatos e CArtAgO.
● Aplicação para programação de sistemas
multi-agente
● Trabalhos relacionados

Introdução
● A noção de ambientes é um conceito primário em agentes
e SMA, sendo o lugar computacional ou físico que os
agentes serão situados;
– Este lugar irá prover e definir as noções de percepções, ações
e interações dos agentes;
● Os recursos fundamentais da abstração de agentes
estão direta ou indiretamente ligados com o ambiente.
Exemplo:
– Reatividade;
– Pró-atividade;
– Noções de objetivos;
– Aspectos de comportamento pró-ativo (tipicamente definido em
termos de estados do mundo).

Introdução
● Há duas principais perspectivas para definição
de ambientes em SMA:
– As raízes clássicas da IA;
– O contexto da Engenharia de Software Orientada
a Agentes (AOSE);
● Na visão clássica temos:
– A noção de ambiente define o mundo externo que
é percebido e atuado através dos agentes de
modo a cumprir com suas tarefas;

Introdução
● No contexto da AOSE temos que:
– Trabalhos recentes introduziram a ideia de ambiente como
uma abstração de primeira classe para engenharia de
SMA;
– Isso quer dizer que existe um lugar adequado para
encapsular funcionalidades e serviços que suportam
atividades de agentes;
● Trabalhos sobre o assunto:
– Weyns, D., & Parunak, H. V. D. (Eds.). (2007). Special issue on
environments for multi-agent systems. Journal of Autonomous Agents
and Multi-Agent Systems, 14(1), 1–116
– Weyns, D., Parunak, H. V. D., Michel, F., Holvoet, T., & Ferber, J. (2005).
Environments for multiagent systems: State-of-the-art and research
challenges. In D. Weyns, H. V. D. Parunak, F. Michel, T. Holvoet, & J. Ferber
(Eds.), Environment for multi-agent systems, volume 3374 (pp. 1–47).
Berlin/Heidelberg: Springer.

Introdução
● Nesta visão (AOSE) o ambiente não é mais apenas o alvo das ações do
agente, nem um container ou gerador de percepções para o agente, mas
agora ele é parte do SMA e pode ser desenhado para melhorar o
desenvolvimento global do sistema;
● O ambiente pode ser definido sob o ponto de vista da engenharia de um
SMA como endógeno, fazendo parte do sistema para o qual foi
desenhado;
● A contrário, a visão clássica da IA, pode ser definida dualmente como
exógena;
● As responsabilidades e funcionalidades dos ambientes endógenos são
resumidas sob três diferentes níveis de suporte:
– Básico;
– Abstração;
– Mediação/interação.

Introdução
● Os três níveis de suporte:
– Básico:
● O ambiente é explorado para habilitar o acesso do agente ao contexto
de implantação. (ex.: determinados recursos externos de
hardware/software que o SMA interage com sensores e atuadores);
– Abstração:
●
Explorando uma camada de abstração do ambiente para uma ponte do
gap (lacuna) conceitual entre a abstração do agente e o baixo nível de
detalhes do contexto de implantação, escondendo tais aspectos de
baixo nível do programador de agentes;
– Interação/mediação:
● Onde o ambiente é explorado tanto para regular o acesso quanto para
compartilhar recursos e, ainda, mediar a interação entre os agentes.
●
Esses três níveis representam diferentes graus de funcionalidades que os
agentes podem usar para atingir seus objetivos.

Introdução
● No artigo é alavancada uma perspectiva partindo do desenho
até a programação de SMA, elaborando o ambiente como
abstração de primeira classe para ser integrado com
linguagens de programação de agentes já existentes.
● Eles descreveram um computação concreta e um modelo de
programação baseado no metamodelo de Agentes e
Artefatos (A & A) e implementaram usando a tecnologia do
CArtAgO.
● A abordagem permitiu desenhar e programar um ambiente
em termos de conjuntos dinâmicos de entidades
computacionais de primeira classe denominados de artefatos
colecionados em localidades conhecidas como workspaces.

Introdução
● Artefatos representam recursos e ferramentas que os
agentes podem instanciar dinamicamente, compartilhar e
usar como suporte às suas atividades individuais e
coletivas.
– De um lado, eles são abstrações de primeira classe
para projetistas e programadores de SMA, quem
define os tipos de artefatos, sua estrutura e
comportamento.
– De outro lado, são entidades de primeira classe do
mundo de agentes, que percebe agentes, usa,
compõe e manipula como tal.

Introdução
● O Cartago provê suporte direto para todos os três
níveis demonstrados;
– No nível básico, artefatos podem ser usados para
envolver e habilitar o acesso aos recursos do contexto
de implantação;
– No nível de abstração, artefatos podem ser usados para
definir uma nova camada de abstração e esconder
um baixo nível de detalhes do contexto de implantação,
possibilitando que recursos computacionais sejam
totalmente virtuais;
– No nível de interação/mediação artefatos podem ser
projetados para encapsular e decretar mecanismos de
coordenação;

Programando Ambiente em
sistemas multi-agente
● A ideia básica da programação de ambiente pode
ser resumida como:
prog. de SMA = prog. de agente + prog. de ambiente
● Onde implicitamente será referenciado softwares de
SMA e ambientes endógenos;
● Nesta visão, o ambiente é uma parte programável do
sistema, ortogonal em relação à parte do agente;
– Ortogonalidade significa separação de interesses com
duas possibilidades;

Ortogonalidade
● Uso do XML Parse do apache Tomcat

Ortogonalidade
● Uso de Logging do apache Tomcat

Programando Ambiente em
● De um lado os agentes são abstrações básicas para
projetar e programar partes autônomas do sistema;
– ex.: essas partes são projetadas para realizar algum
objetivo, tanto individual ou coletivo, encapsulando a lógica
e o controle de suas ações;
● Por outro lado, o ambiente pode ser usado para
projetar e programar a parte computacional do
sistema que é funcional para o trabalho dos agentes;
– ex.: agentes podem dinamicamente acessar e usar
algumas tipos de funcionalidades para explorar,
possibilitando adaptar-se para melhor atender suas atuais
necessidades.

Um exemplo simples
● Considere a implementação dentro de um
programa multi-agente de uma caixa preta
como um mecanismo que habilita
comunicação desacoplada entre agentes;
– Sem o mecanismo de separação de interesse, a
“caixa preta” deverá ser implementada como um
agente, criando então uma incompatibilidade entre
projeto e implementação, uma vez que ela não é
tipicamente projetada para atender pro-atividade e
de forma autônoma algum objetivo, mas sim para
ser usado por outros agentes para se comunicar e
coordenar.

Um exemplo simples
– Adotando a programação de ambiente, a “caixa
preta” é implementada como um recurso de
ambiente, acessada pelos agentes em termos de
ações e percepções.
● O exemplo pode ser generalizado,
considerando qualquer entidade
computacional projetada corretamente para
ajudar o trabalho e a interação de agente.

Modelos de programação para
programação de ambiente
● Para programar ambientes necessitamos adotar algum
modelo computacional de programação de uso geral, por
meio de um modelo capaz de definir:
– Uma estrutura e comportamento computacional do ambiente;
– Que tipo de programação e construção podem ser usados por
desenvolvedores de SMA para projetar e implementar ambientes;
● Alguns modelos e princípios conhecidos:
– Abstração;
– Ortogonalidade;
– Generalidade;
– Modularidade;
– Extensibilidade dinâmica;
– Reusabilidade.

● Abstração;
● Ortogonalidade;
● Generalidade;
● Modularidade;
● Extensibilidade
dinâmica;
● Reusabilidade.
O modelo adotado deve preservar o nível de
abstração do agente, ou seja, o principais
conceitos utilizados para a estrutura e dinâmica
do ambiente do programa deve ser consistente
com os conceitos de agente e sua semântica.
Exemplos incluem a noção de ações, perceptos,
Eventos e tarefas / objetivos.

● Abstração;
● Ortogonalidade;
● Generalidade;
● Modularidade;
● Extensibilidade
dinâmica;
● Reusabilidade.
O modelo deve ser o mais ortogonal possível
em relação aos modelos, arquiteturas, linguagens
de programação do agente, de modo a
naturalmente suportar a engenharia de
sistemas heterogêneos.

● Abstração;
● Ortogonalidade;
● Generalidade;
● Modularidade;
● Extensibilidade
dinâmica;
● Reusabilidade.
O modelo deve ser geral e expressivo o suficiente
para permitir o desenvolvimento de diferentes tipos
de ambiente de acordo com diferentes
domínios e problemas de aplicação, explorando
o mesmo conjunto básico de conceitos e
construções

● Abstração;
● Ortogonalidade;
● Generalidade;
● Modularidade;
● Extensibilidade
dinâmica;
● Reusabilidade.
O modelo deve introduzir conceitos para
modularizar ambientes, evitando visões
monolítica e centralizada.

● Abstração;
● Ortogonalidade;
● Generalidade;
● Modularidade;
● Extensibilidade
dinâmica;
● Reusabilidade.
O modelo deve suportar a construção dinâmica,
substituindo, extensão de partes do ambiente,
em uma perspectiva de sistema aberto.

● Abstração;
● Ortogonalidade;
● Generalidade;
● Modularidade;
● Extensibilidade
dinâmica;
● Reusabilidade. O modelo deve promover a reutilização de partes
do ambiente em diferentes contextos ou domínios
de aplicação.

● Por fim é importante destacar que diferentes paradigmas de
programação podem ser reutilizados para definir outros modelos de
programação de ambiente apenas por fazer uma ponte entre a
lacuna de abstração em relação ao nível de abstração do agente;
● Exemplo:
– O conceito de objeto (POO) não pode ser reutilizado “como ele é” para
abstração de primeira classe de ambientes, pois as interações são feitas
usando a invocação de métodos e não em percepções e ações;
– Isso vale também para o Jade (OO baseado em Java);
● Assim, classes são usadas para implementar agentes e não para
criar ambientes compartilhados pelos agentes em relação à sua
coordenação e cooperação. Então:
– as classes/objetos NÃO são entidades de primeira classe para o mundo
de agentes (elas são básicas para construção de agentes);
– é necessária uma camada de abstração para definir a semântica de
interação agente-objeto.

● Tendo em conta esses requisitos gerais, os
autores levantaram o seguinte modelo
computacional para programação de
ambiente:
– Modelo de ação;
– Modelo de percepção;
– Modelo computacional de ambiente;
– Modelo de dados do ambiente;
– Modelo de distribuição do ambiente;

Modelo de ação
● Este aspecto preocupa-se em como os agentes afetam o
estado do ambiente;
– Inclui a noção externa de ação e o tipo de semântica para definir
sucesso ou fracasso de ação
– Isso significa aceitação ou rejeição de ação pelo ambiente;
– Toda via, no lado do agente, ele apenas saberá o resultado por
meio de suas percepções;
– A perspectiva de programação de ambiente torna a semântica
mais rica em relação aos efeitos de ações dos agentes;
– Em ambientes endógenos o conjunto de ações pode ser
considerado parte de um contrato que o ambiente provê para os
agentes (logicamente situados no ambiente);
– O modelo de execução de ação adotado pelas atuais linguagens
de programação de agentes são basicamente eventos (transações
atômicas);

Modelo de percepção
● Este aspecto preocupa-se em como os agentes irão
perceber o ambiente em relação à definição dos estímulos
gerados pelo ambiente e a percepção dos agentes;
● Somados com as ações, estes podem ser considerados
partes do contrato com os agentes;
● Essencialmente duas semânticas podem ser definidas:
● Baseado em estado:
– os estímulos são informações sobre o estado atual do ambiente;
– são gerados quando o agente está engajado em suas percepções
em um ciclo de execução;
● Baseado em evento:
– os estímulos são informações sobre as mudanças ocorridas
ambiente;
– são expedidas aos agentes independente do estado de execução;

Modelo de percepção
● Exemplos:
– A função see da arquitetura abstrata de Wooldridge é baseada
em estado;
– Em uma arquitetura BDI as percepções são usada para
atualizar o estado atual da base de crenças;
– No Jason a atualização da base de crença gera eventos que
podem desencadear planos;
● Vale ressaltar que no Jason essa semântica padrão pode
ser modificada injetando uma nova semântica;
● A escolha do modelo tem forte impacto na execução do SMA;
– Exemplo: uma adoção ao modelo baseado em estado em um
ambiente que muda várias vezes entre duas sequências do
estágio de percepção pode fazer com que o agente não
perceba determinada mudança no ambiente.

Modelo computacional de ambiente
● Este aspecto preocupa-se em como programar as
funcionalidade do ambiente, ou seja, as estruturas
internas e o seu comportamento;
● O aspecto mais importante refere-se ao modelo usado
para decompor o estado/comportamento do ambiente;
– O mais simples é o modelo monolítico;
● A estrutura e o comportamento são representados por um único
objeto com um único estado;
● O objeto é ponto de entrada para definir o efeito de ações e os
estímulos gerados;
● O JASON nativamente usa essa abordagem usando uma classe
para programar o ambiente;
● Um outro aspecto relacionado diz respeito ao modelo de
concorrência para executar os processos do ambiente;

Modelo de dados do ambiente
● Este aspecto preocupa-se com os tipos de dados trocados
pelos agente com o ambiente;
– É usado em particular para codificar parâmetros e feedbacks
de ação, percepções e sua representação;
– Ele conclui o contrato básico entre os agentes e o ambiente;
– Aparecem os mesmos problemas de interoperabilidade
quando desenvolvidos com diferentes linguagens ou
frameworks;
● Uma forma de resolver é utilizar tipos de dados
estruturados envolvendo percepções e ações, adotando
alguma representação (como a linguagem XML);
– Para o caso dos sistemas abertos o modelo deve definir
ontologias adequadas para explicitar a semântica dos dados
envolvidos na interação agente-ambiente;

Modelo de distribuição do ambiente
● Este aspecto preocupa-se com a forma de como programar
ambientes que precisam ser distribuídos (ou oportunamente,
distribuído) entre vários nós de uma rede;
– Para isso ele introduz uma noção de localização para definir a
parte não distribuída do ambiente e então define se/como os
lugares estão conectados e eventualmente interagem;
– Do lado do agente o modelo afeta o repertório de ações do
agente, possivelmente incluindo também ações para entrar em
um lugar ou mudar de um lugar para outro;

Agenda
● Introdução
● Programando Ambiente em sistemas multi-
agente
● Ambientes baseados em artefatos e
CArtAgO.
● Aplicação para programação de sistemas
multi-agente
● Trabalhos relacionados

Ambientes baseados em artefatos
● O ambiente é concebido como um conjunto
dinâmico de entidades computacionais
(artefatos);
● O conjunto total de artefatos pode ser
organizado em uma ou várias áreas de
trabalho (workspaces) distribuídas em
diferentes nós ou não;
● Um espaço de trabalho representa um lugar;

Uma visão geral dos principais conceitos que caracterizam ambientes
baseados em artefato

● Programadores de SMA definem os tipos de
artefatos de forma análoga à POO, pois é
definido estrutura e comportamento;
– Cada workspace possui
(dinamicamente) um
conjunto de tipos de
artefatos que podem ser
usados para criar
instâncias;
– Para possuir
funcionalidades disponíveis
e exploráveis por agentes,
um artefato fornece um
conjunto de operações e
propriedade observáveis;

● Operações representam processos (possivelmente de longo
prazo) executados dentro de um artefato e pode ser
disparado por um agente ou outros artefatos;
● O termo usado para interface indica o conjunto total de
operações disponíveis para agentes;
● Propriedades observáveis representam variáveis de estado,
cujo valor pode ser percebido pelos agentes;
● A execução de uma operação pode gerar sinais (percebidos
pelos agentes);
– Sinais são eventos observáveis não-persistentes que ocorrem
dentro de um artefato;
● Além dos estados observáveis, um artefato pode ter estados
ocultos (necessários para implementar alguma
funcionalidade);

● Do ponto de vista do agente, as operações de artefatos
representam ações externas fornecidas aos agentes pelo
ambiente: este é um aspecto central do modelo;
● Então o repertório de ações externas disponíveis para
um agente em um ambiente baseado em artefato é
definido pelo conjunto de artefatos que povoam o
ambiente;
● Isso implica que o repertório é dinâmico, pois o conjunto
de artefatos pode ser alterado pelos próprios agentes;
● Em arquiteturas BDI (Jason) percepções relacionadas
com as propriedades observáveis podem ser
modeladas no próprio agente como crenças sobre o
estado atual do ambiente;

● Por fim, um artefato pode ser equipado com um
manual;
– um documento legível por máquina a ser consultados
pelos agentes, contendo a descrição das
funcionalidades fornecidas pelo artefato e como
explorar essas funcionalidades;
– foi concebido especialmente para sistemas abertos
compostos por agentes inteligentes que decidem
dinamicamente que artefatos irão usar de acordo com
seus objetivos e também devem descobrir
dinamicamente como usá-los;

● Ações para trabalhar com artefatos
– Um agente precisa juntar-se a um workspace para
trabalhar com ele (ou vários ao mesmo tempo);
– Também deve sair o mais rápido possível quando
terminar o trabalho;
● Dentro de um workspace o agente pode realizar
ações para trabalhar com artefatos categorizados
em três grupos:
– Ações para criar / pesquisar / eliminar artefatos;
– Ações para usar artefatos, executar operações e
observar propriedades e sinais;
– Ações para vincular / desvincular artefatos;

Criando e descobrindo artefato
● Os artefatos são destinadas a ser criados,
descobertos e possivelmente descartados por
agentes em tempo de execução
– esta é uma forma básica em que o modelo
suporta extensibilidade dinâmica (além da
modularidade) do ambiente;
● Os três tipos básicos são:
– makeArtifact(ArName,ArTypeName,InitParams):ArId
– disposeArtifact(ArId)
– lookupArtifact(ArName):ArId

Usando e observando os artefatos
● Envolve dois aspectos:
– Ser capaz de executar operações listadas em
usage interface do artefato;
– Ser capaz de perceber informações observáveis
do artefato em termos de propriedades e eventos
observáveis;
● Aspecto 1 (figura 3):
– use(ArId,OpName(Params)):OpRes
● Aspecto 2 (figura 4):
– focus(ArId,{Filter}) (ou stopFocus(ArId))

Usando e observando os artefatos

Vinculando e desvinculando
artefatos
● A vinculação entre artefatos permite que um
artefato execute operações em detrimento a
outro artefato;
● Para isso existem duas ações básicas:
– linkArtifacts(LinkingArId,LinkedArId{,Port})
– unlinkArtifacts(LinkingArId,LinkedArId)
● Isso permite que agentes componham
dinamicamente artefatos complexos através
de simples ligações entre eles, criando redes
de artefatos;

CArtAgO
(Common ARtifact infrastructure for AGent Open environments)
● É um framework e infraestrutura para programação e
execução de ambientes baseados em artefatos implementado o
modelo informalmente descrito anteriormente;
● Enquanto framework ele fornece:
– uma API em Java para programar artefatos e ambientes em tempo
de execução para executar ambientes baseados em artefatos
– uma biblioteca com um conjunto de tipos de artefatos de uso geral
pré-definidos;
● Enquanto infraestrutura:
– Provê uma API e um mecanismo subjacente para estender
linguagens/framework de programação de agentes assim como
para que programa de agentes trabalhem dentro de ambientes
Cartago;

CArtAgO
● Modelo de programação de artefato
– Um artefato é programado diretamente em uma classe
Java, estendendo classe cartago.Artifact usando um
conjunto básico de anotações Java e métodos herdados
para definir os elementos estruturais de um artefato e seus
comportamentos;
– Exemplo simples:
● Counter:
– Um contador simples que fornece uma única
propriedade observável chamada de count
– Uma propriedade observável chamada de inc

CArtAgO

Um outro exemplo ilustrando o uso de sinais

CArtAgO
● Cartago é ortogonal para a tecnologia específica adotada
pela programação de agentes trabalhando em ambientes
baseados em artefatos;
● Foi concebido de modo a ser integrado com qualquer
linguagem de programação e plataforma de agentes,
permitindo a criação sistemas heterogêneos;
● Um exemplo ilustrativo de Cartago com Jason:
– Existem dois agentes Jason que criam, cooperam e usam três
artefatos do tipo Counter, MyArtifact e Clock.
– Eles executam operações de artefatos e percebem
propriedades e eventos observáveis;

CArtAgO
● Resultado da execução

Aplicação para programação de
● Neste seção (4), os autores a desenvolvem
inicialmente mostrando a aplicabilidade de uma
forma geral da abordagem sob um ponto de vista
metodológico;
– Em seguida eles consideram alguns contextos
específicos e problemas onde artefatos e Cartago podem
ser explorados para promover uma prática de
programação de SMA;
– No contexto específico temos:
● O problema do produtor/consumidor;
● A sincronização de tarefas;
● Mecanismo de comunicação social;
● Programação de recursos (internos e externos);

Exemplo independente
● Visando iniciar a programação de Ambientes e Agentes
usando Cartago e Jason codificamos um exemplo
simplório com os seguintes requisitos:
– O ambiente será um “bingo” onde números serão sorteados
depois de X cartelas “vendidas”;
– Temos dois agentes: um proprietário (owner) e um jogador
(player);
● O owner cria o artefato “Bingo” e o monitora a fim de perceber se as
X cartelas foram vendidas. Feito isso, ele realiza uma operação no
ambiente para iniciar o sorteio;
● O jogador fica vagando até encontrar o artefato “bingo”. Ao
encontrar realiza uma operação de “compra” para participar do
sorteio. Após isso sua função é monitorar o ambiente esperando por
números sorteados (informados por meio de sinais) e pelo final do
sorteio.

// CArtAgO artifact code for project
prj_MAS_Bingo
package tablet;
import java.util.Random;
import cartago.Artifact;
import cartago.INTERNAL_OPERATION;
import cartago.OPERATION;
public class Bingo extends Artifact {
String internalStatus = "void";
int MAXNumberSorted = 15;
int MAXSold = 02;
int sold = 0;
void init() {
defineObsProperty("numSorted", 0);
signal("status", "selling");
internalStatus = "selling";
}
@OPERATION
void sell(){
sold++;
if (sold >= MAXSold){
signal("status", "ready");
}
}
@OPERATION
void start(){
signal("status", "started");
internalStatus = "started";
execInternalOp("sortAnumber");
}
@INTERNAL_OPERATION
void stop(){
internalStatus = "stop";
signal("status", "stoped");
}
@INTERNAL_OPERATION
void sortAnumber(){
Random r = new Random();
int counter = 0;
while (!internalStatus.equals("stop")){
counter++;
int x = r.nextInt(100);
getObsProperty("numSorted").updateValue(x);
signal("status", "sorted");
await_time(3000);
if (counter >= MAXNumberSorted)
execInternalOp("stop");
}
}
}
Ambiente

Agent Owner
/* Initial beliefs and rules */
/* Initial goals */
!create.
/* Plans */
+!create : true <-
?setupBingo (ID).
+?setupBingo (C) : true <-
makeArtifact("b0", "tablet.Bingo", [], C);
focus(C).
-?setuBingo(C) : true <-
wait(10);
?setupBing(ID).
//Perceptions
//Signal status
+status(S) : S == "ready" <-
start.

Agente Player
/* Initial beliefs and rules */
/* Initial goals */
!observer.
/* Plans */
+!observer : true <-
?myArtifact (ID);
focus(ID);
sell; //buy
println("Comprei uma cartela ...no bingo:", ID).
+?myArtifact(C) : true <-
lookupArtifact("b0", C).
-?myArtifact(art) : true <-
.wait(1000);
println("Esperando por um bingo.");
!observer.
//Perceptions of th signals
+status(S) : S == "sorted" <-
?numSorted(V);
println("Opa, percebi um numero sorteado ... ", V).
+status(S) : S == "started" <-
println("Legal! Bingo inciado!").
+status(S) : S == "stoped" <-
println("Ahhhh .. já acabou.").
//Percepctions of the Observable Properties
+numSorted(V).

Alguns Trabalhos relacionados
● Exploração de ambiente no contexto de SMA em geral:
– Weyns, D., & Parunak, H. V. D. (Eds.). (2007). Special issue on environments
for multi-agent systems. Journal of Autonomous Agents and Multi-Agent
Systems
– Weyns, D., Parunak, H. V. D., Michel, F., Holvoet, T., & Ferber, J. (2005).
Environments for multiagent systems: State-of-the-art and research
challenges. In D. Weyns, H. V. D. Parunak, F. Michel, T. Holvoet, & J. Ferber
(Eds.), Environment for multi-agent systems, volume 3374 (pp. 1–47).
● Exploração do tipo de impacto a noção do ambiente como uma
abstração para programação de primeira classe pode ter em
sistemas multiagentes usando linguagens de agentes existentes:
– Gutknecht, O., & Ferber, J. (2000). The MADKIT agent platform architecture. In
Agents workshop on infrastructure for multi-agent systems (pp. 48–55).
– Bromuri, S., & Stathis, K. (2008). Situating cognitive agents in GOLEM. In D.
Weyns, S. Brueckner, & Y. Demazeau (Eds.), Engineering environment-
mediated multi-agent systems, volume 5049 of LNCS (pp. 115–134).

Alguns Trabalhos relacionados
● Definição de mecanismos baseados no ambiente para resolver problemas
específicos como comunicação e cooperação:
– Platon, E., Mamei, M., Sabouret, N., Honiden, S., & Parunak, H. V. (2007).
Mechanisms for environments in multi-agent systems: Survey and opportunities.
Autonomous Agents and Multi-Agent Systems, 14(1), 31–47.
– Weyns, D., & Holvoet, T. (2007). A reference architecture for situated multiagent
systems. In Environments for multiagent systems III, volume 4389 of LNCS (pp. 1–
40). Berlin/Heidelberg: Springer.
● Relacionados à noção de artefatos e Cartago:
– Omicini, A., Ricci, A., & Viroli, M. (2008). Artifacts in the A&A meta-model for multi-
agent systems. Autonomous Agents and Multi-Agent Systems, 17(3), 432–456.
– Ricci, A., Viroli, M., & Omicini, A. (2007). CArtAgO: A framework for prototyping
artifact-based environments in MAS. In D. Weyns, H. V. D. Parunak, & F. Michel
(Eds.), Environments for multiagent systems III, volume 4389 of LNAI (pp. 67–86).
– Ricci, A., Viroli, M., & Omicini, A. (2007). The A&A programming model &
technology for developing agent environments in MAS. In M. Dastani, A. El Fallah
Seghrouchni, A. Ricci, & M. Winikoff (Eds.), Programming multi-agent systems,
volume 4908 of LNAI (pp. 91–109). Berlin/Heidelberg: Springer.

Referência
● Ricci, Alessandro. Piunti, Michele. Viroli, Mirko. Environment
programming in multi-agent systems: an artifcat-based perspective.
In proccedings of the Autonomous Agent Multi-Agent Systems, 2011.
Berlin, Springer.

Ambientes em Sistemas Multi-agentes

Mais conteúdo relacionado

Mais procurados

Semelhante a Ambientes em Sistemas Multi-agentes

Mais de Nécio de Lima Veras

Ambientes em Sistemas Multi-agentes