SlideShare uma empresa Scribd logo
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;
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
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
sistemas multi-agente
● 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.
Modelos de programação para
programação de ambiente
● 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.
Modelos de programação para
programação de ambiente
● 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.
Modelos de programação para
programação de ambiente
● 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
Modelos de programação para
programação de ambiente
● Abstração;
● Ortogonalidade;
● Generalidade;
● Modularidade;
● Extensibilidade
dinâmica;
● Reusabilidade.
O modelo deve introduzir conceitos para
modularizar ambientes, evitando visões
monolítica e centralizada.
Modelos de programação para
programação de ambiente
● 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.
Modelos de programação para
programação de ambiente
● 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.
Modelos de programação para
programação de ambiente
● 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.
Modelos de programação para
programação de ambiente
● 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;
Ambientes baseados em artefatos
Uma visão geral dos principais conceitos que caracterizam ambientes
baseados em artefato
Ambientes baseados em artefatos
● 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;
Ambientes baseados em artefatos
● 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);
Ambientes baseados em artefatos
● 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;
Ambientes baseados em artefatos
● 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;
Ambientes baseados em artefatos
● 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
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
(Common ARtifact infrastructure for AGent Open environments)
● 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
(Common ARtifact infrastructure for AGent Open environments)
Um outro exemplo ilustrando o uso de sinais
CArtAgO
(Common ARtifact infrastructure for AGent Open environments)
● 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
(Common ARtifact infrastructure for AGent Open environments)
CArtAgO
(Common ARtifact infrastructure for AGent Open environments)
● Resultado da execução
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
Aplicação para programação de
sistemas multi-agente
● 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).
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
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).
Berlin/Heidelberg: Springer.
● 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).
Berlin/Heidelberg: Springer.
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).
Berlin/Heidelberg: Springer.
– 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.

Mais conteúdo relacionado

Mais procurados

Metodologia orientado a objetos
Metodologia orientado a objetosMetodologia orientado a objetos
Metodologia orientado a objetos
Gabriel Faustino
 
Analise e projetos orientados a objetos
Analise e projetos orientados a objetosAnalise e projetos orientados a objetos
Analise e projetos orientados a objetos
Sliedesharessbarbosa
 
Analise e Desenho Orientado a Objetos com UML
Analise e Desenho Orientado a Objetos com UMLAnalise e Desenho Orientado a Objetos com UML
Analise e Desenho Orientado a Objetos com UML
Rildo (@rildosan) Santos
 
IA - Aula 04 - Agentes parte 2
IA - Aula 04 - Agentes parte 2IA - Aula 04 - Agentes parte 2
IA - Aula 04 - Agentes parte 2
Andrei Formiga
 
Java programação orientada a objetos
Java   programação orientada a objetosJava   programação orientada a objetos
Java programação orientada a objetos
Paulo Carvalho
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT
 
Análise Orientada a Objetos - Objetos E Classes
Análise Orientada a Objetos  -   Objetos E ClassesAnálise Orientada a Objetos  -   Objetos E Classes
Análise Orientada a Objetos - Objetos E Classes
CursoSENAC
 

Mais procurados (7)

Metodologia orientado a objetos
Metodologia orientado a objetosMetodologia orientado a objetos
Metodologia orientado a objetos
 
Analise e projetos orientados a objetos
Analise e projetos orientados a objetosAnalise e projetos orientados a objetos
Analise e projetos orientados a objetos
 
Analise e Desenho Orientado a Objetos com UML
Analise e Desenho Orientado a Objetos com UMLAnalise e Desenho Orientado a Objetos com UML
Analise e Desenho Orientado a Objetos com UML
 
IA - Aula 04 - Agentes parte 2
IA - Aula 04 - Agentes parte 2IA - Aula 04 - Agentes parte 2
IA - Aula 04 - Agentes parte 2
 
Java programação orientada a objetos
Java   programação orientada a objetosJava   programação orientada a objetos
Java programação orientada a objetos
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
 
Análise Orientada a Objetos - Objetos E Classes
Análise Orientada a Objetos  -   Objetos E ClassesAnálise Orientada a Objetos  -   Objetos E Classes
Análise Orientada a Objetos - Objetos E Classes
 

Semelhante a Ambientes em Sistemas Multi-agentes

Programação Orientada a Aspectos
Programação Orientada a AspectosProgramação Orientada a Aspectos
Programação Orientada a Aspectos
Regina Macedo
 
Sistemas Multiagentes Baseados em Modelagem por Redes de Petri: um estudo de ...
Sistemas Multiagentes Baseados em Modelagem por Redes de Petri: um estudo de ...Sistemas Multiagentes Baseados em Modelagem por Redes de Petri: um estudo de ...
Sistemas Multiagentes Baseados em Modelagem por Redes de Petri: um estudo de ...
Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Sul
 
MaDKit
MaDKitMaDKit
Apresentação final
Apresentação finalApresentação final
Apresentação final
valmon
 
Talkagent
TalkagentTalkagent
Talkagent
Percival Lucena
 
Sistemas Multiagentes e Sistemas Distribuídos Sensíveis ao Contexto
Sistemas Multiagentes e Sistemas Distribuídos Sensíveis ao ContextoSistemas Multiagentes e Sistemas Distribuídos Sensíveis ao Contexto
Sistemas Multiagentes e Sistemas Distribuídos Sensíveis ao Contexto
Helio Henrique L. C. Monte-Alto
 
342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf
GabrielMarchesan
 
Umlv4 090813182632-phpapp02
Umlv4 090813182632-phpapp02Umlv4 090813182632-phpapp02
Umlv4 090813182632-phpapp02
Jhonefj
 
Agent based software development
Agent based software developmentAgent based software development
Agent based software development
Alan Prando
 
Resumo prova
Resumo provaResumo prova
Resumo prova
Diogo Librelon
 
Net uma revisão sobre a programação orientada a objetos
Net   uma revisão sobre a programação orientada a objetosNet   uma revisão sobre a programação orientada a objetos
Net uma revisão sobre a programação orientada a objetos
LP Maquinas
 
Saam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halanSaam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halan
Halan Ridolphi
 
Aula02
Aula02Aula02
Li Weigang - GROUND HANDLING WORKSHOP - PANEL 3: Key challenges for the secto...
Li Weigang - GROUND HANDLING WORKSHOP - PANEL 3: Key challenges for the secto...Li Weigang - GROUND HANDLING WORKSHOP - PANEL 3: Key challenges for the secto...
Li Weigang - GROUND HANDLING WORKSHOP - PANEL 3: Key challenges for the secto...
IBAS International Brazil Air Show
 
Resumo diagrama de casos de utilização
Resumo diagrama de casos de utilizaçãoResumo diagrama de casos de utilização
Resumo diagrama de casos de utilização
Marco Coelho
 
poster
posterposter
poster
Ruan Costa
 
Aula4AgentesIntelig.ppt
Aula4AgentesIntelig.pptAula4AgentesIntelig.ppt
Aula4AgentesIntelig.ppt
Isaac Medeiros
 
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Lucas Furtado de Oliveira
 
88194121 puc-ihc-aula11-teorias-de-ihc-eng-cognitiva
88194121 puc-ihc-aula11-teorias-de-ihc-eng-cognitiva88194121 puc-ihc-aula11-teorias-de-ihc-eng-cognitiva
88194121 puc-ihc-aula11-teorias-de-ihc-eng-cognitiva
Josimar Lima
 
Pro model
Pro modelPro model
Pro model
Paulo Sideres
 

Semelhante a Ambientes em Sistemas Multi-agentes (20)

Programação Orientada a Aspectos
Programação Orientada a AspectosProgramação Orientada a Aspectos
Programação Orientada a Aspectos
 
Sistemas Multiagentes Baseados em Modelagem por Redes de Petri: um estudo de ...
Sistemas Multiagentes Baseados em Modelagem por Redes de Petri: um estudo de ...Sistemas Multiagentes Baseados em Modelagem por Redes de Petri: um estudo de ...
Sistemas Multiagentes Baseados em Modelagem por Redes de Petri: um estudo de ...
 
MaDKit
MaDKitMaDKit
MaDKit
 
Apresentação final
Apresentação finalApresentação final
Apresentação final
 
Talkagent
TalkagentTalkagent
Talkagent
 
Sistemas Multiagentes e Sistemas Distribuídos Sensíveis ao Contexto
Sistemas Multiagentes e Sistemas Distribuídos Sensíveis ao ContextoSistemas Multiagentes e Sistemas Distribuídos Sensíveis ao Contexto
Sistemas Multiagentes e Sistemas Distribuídos Sensíveis ao Contexto
 
342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf
 
Umlv4 090813182632-phpapp02
Umlv4 090813182632-phpapp02Umlv4 090813182632-phpapp02
Umlv4 090813182632-phpapp02
 
Agent based software development
Agent based software developmentAgent based software development
Agent based software development
 
Resumo prova
Resumo provaResumo prova
Resumo prova
 
Net uma revisão sobre a programação orientada a objetos
Net   uma revisão sobre a programação orientada a objetosNet   uma revisão sobre a programação orientada a objetos
Net uma revisão sobre a programação orientada a objetos
 
Saam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halanSaam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halan
 
Aula02
Aula02Aula02
Aula02
 
Li Weigang - GROUND HANDLING WORKSHOP - PANEL 3: Key challenges for the secto...
Li Weigang - GROUND HANDLING WORKSHOP - PANEL 3: Key challenges for the secto...Li Weigang - GROUND HANDLING WORKSHOP - PANEL 3: Key challenges for the secto...
Li Weigang - GROUND HANDLING WORKSHOP - PANEL 3: Key challenges for the secto...
 
Resumo diagrama de casos de utilização
Resumo diagrama de casos de utilizaçãoResumo diagrama de casos de utilização
Resumo diagrama de casos de utilização
 
poster
posterposter
poster
 
Aula4AgentesIntelig.ppt
Aula4AgentesIntelig.pptAula4AgentesIntelig.ppt
Aula4AgentesIntelig.ppt
 
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
 
88194121 puc-ihc-aula11-teorias-de-ihc-eng-cognitiva
88194121 puc-ihc-aula11-teorias-de-ihc-eng-cognitiva88194121 puc-ihc-aula11-teorias-de-ihc-eng-cognitiva
88194121 puc-ihc-aula11-teorias-de-ihc-eng-cognitiva
 
Pro model
Pro modelPro model
Pro model
 

Mais de Nécio de Lima Veras

Introdução ao JavaFX
Introdução ao JavaFXIntrodução ao JavaFX
Introdução ao JavaFX
Nécio de Lima Veras
 
Introdução à analise e complexidade de algoritmos
Introdução à analise e complexidade de algoritmosIntrodução à analise e complexidade de algoritmos
Introdução à analise e complexidade de algoritmos
Nécio de Lima Veras
 
Teste de software
Teste de softwareTeste de software
Teste de software
Nécio de Lima Veras
 
Versionamento com git
Versionamento com gitVersionamento com git
Versionamento com git
Nécio de Lima Veras
 
Uma Abordagem Baseada em Agentes para Planejamento e Monitoramento de Serviço...
Uma Abordagem Baseada em Agentes para Planejamento e Monitoramento de Serviço...Uma Abordagem Baseada em Agentes para Planejamento e Monitoramento de Serviço...
Uma Abordagem Baseada em Agentes para Planejamento e Monitoramento de Serviço...
Nécio de Lima Veras
 
Jason: Componentes personalizados
Jason: Componentes personalizados Jason: Componentes personalizados
Jason: Componentes personalizados
Nécio de Lima Veras
 
Revisão de matemática
Revisão de matemáticaRevisão de matemática
Revisão de matemática
Nécio de Lima Veras
 
Anotações do mapeamento OR
Anotações do mapeamento ORAnotações do mapeamento OR
Anotações do mapeamento OR
Nécio de Lima Veras
 
Hibernate-consultas
Hibernate-consultasHibernate-consultas
Hibernate-consultas
Nécio de Lima Veras
 
Mapeamento de herança OR
Mapeamento de herança ORMapeamento de herança OR
Mapeamento de herança OR
Nécio de Lima Veras
 
Relacionamentos do mapeamento OR
Relacionamentos do mapeamento ORRelacionamentos do mapeamento OR
Relacionamentos do mapeamento OR
Nécio de Lima Veras
 
Processos iniciais do mapeamento OR
Processos iniciais do mapeamento ORProcessos iniciais do mapeamento OR
Processos iniciais do mapeamento OR
Nécio de Lima Veras
 
Java swing
Java swingJava swing
Introdução à linguagem UML
Introdução à linguagem UMLIntrodução à linguagem UML
Introdução à linguagem UML
Nécio de Lima Veras
 
Introdução aos Sistemas operacionais
Introdução aos Sistemas operacionaisIntrodução aos Sistemas operacionais
Introdução aos Sistemas operacionais
Nécio de Lima Veras
 
Organizando um Repositório de Objetos de Aprendizagem para dispositivos móvei...
Organizando um Repositório de Objetos de Aprendizagem para dispositivos móvei...Organizando um Repositório de Objetos de Aprendizagem para dispositivos móvei...
Organizando um Repositório de Objetos de Aprendizagem para dispositivos móvei...
Nécio de Lima Veras
 
Classes abstratas e interfaces
Classes abstratas e interfacesClasses abstratas e interfaces
Classes abstratas e interfaces
Nécio de Lima Veras
 
Desenvolvimento ágil de software
Desenvolvimento ágil de softwareDesenvolvimento ágil de software
Desenvolvimento ágil de software
Nécio de Lima Veras
 
Internet: conceitos e segurança
Internet: conceitos e segurançaInternet: conceitos e segurança
Internet: conceitos e segurança
Nécio de Lima Veras
 
Conceitos básicos de usabilidade e acessibilidade
Conceitos básicos de usabilidade e acessibilidadeConceitos básicos de usabilidade e acessibilidade
Conceitos básicos de usabilidade e acessibilidade
Nécio de Lima Veras
 

Mais de Nécio de Lima Veras (20)

Introdução ao JavaFX
Introdução ao JavaFXIntrodução ao JavaFX
Introdução ao JavaFX
 
Introdução à analise e complexidade de algoritmos
Introdução à analise e complexidade de algoritmosIntrodução à analise e complexidade de algoritmos
Introdução à analise e complexidade de algoritmos
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Versionamento com git
Versionamento com gitVersionamento com git
Versionamento com git
 
Uma Abordagem Baseada em Agentes para Planejamento e Monitoramento de Serviço...
Uma Abordagem Baseada em Agentes para Planejamento e Monitoramento de Serviço...Uma Abordagem Baseada em Agentes para Planejamento e Monitoramento de Serviço...
Uma Abordagem Baseada em Agentes para Planejamento e Monitoramento de Serviço...
 
Jason: Componentes personalizados
Jason: Componentes personalizados Jason: Componentes personalizados
Jason: Componentes personalizados
 
Revisão de matemática
Revisão de matemáticaRevisão de matemática
Revisão de matemática
 
Anotações do mapeamento OR
Anotações do mapeamento ORAnotações do mapeamento OR
Anotações do mapeamento OR
 
Hibernate-consultas
Hibernate-consultasHibernate-consultas
Hibernate-consultas
 
Mapeamento de herança OR
Mapeamento de herança ORMapeamento de herança OR
Mapeamento de herança OR
 
Relacionamentos do mapeamento OR
Relacionamentos do mapeamento ORRelacionamentos do mapeamento OR
Relacionamentos do mapeamento OR
 
Processos iniciais do mapeamento OR
Processos iniciais do mapeamento ORProcessos iniciais do mapeamento OR
Processos iniciais do mapeamento OR
 
Java swing
Java swingJava swing
Java swing
 
Introdução à linguagem UML
Introdução à linguagem UMLIntrodução à linguagem UML
Introdução à linguagem UML
 
Introdução aos Sistemas operacionais
Introdução aos Sistemas operacionaisIntrodução aos Sistemas operacionais
Introdução aos Sistemas operacionais
 
Organizando um Repositório de Objetos de Aprendizagem para dispositivos móvei...
Organizando um Repositório de Objetos de Aprendizagem para dispositivos móvei...Organizando um Repositório de Objetos de Aprendizagem para dispositivos móvei...
Organizando um Repositório de Objetos de Aprendizagem para dispositivos móvei...
 
Classes abstratas e interfaces
Classes abstratas e interfacesClasses abstratas e interfaces
Classes abstratas e interfaces
 
Desenvolvimento ágil de software
Desenvolvimento ágil de softwareDesenvolvimento ágil de software
Desenvolvimento ágil de software
 
Internet: conceitos e segurança
Internet: conceitos e segurançaInternet: conceitos e segurança
Internet: conceitos e segurança
 
Conceitos básicos de usabilidade e acessibilidade
Conceitos básicos de usabilidade e acessibilidadeConceitos básicos de usabilidade e acessibilidade
Conceitos básicos de usabilidade e acessibilidade
 

Ambientes em Sistemas Multi-agentes

  • 1. Notas de estudo sobre Ambientes por Nécio de Lima Veras
  • 2. 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
  • 3. 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.
  • 4. 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
  • 5. 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).
  • 6. 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;
  • 7. 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.
  • 8. 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.
  • 9. 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.
  • 10. 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.
  • 11. 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.
  • 12. 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;
  • 13. 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
  • 14. 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;
  • 15. Ortogonalidade ● Uso do XML Parse do apache Tomcat
  • 16. Ortogonalidade ● Uso de Logging do apache Tomcat
  • 17. Programando Ambiente em sistemas multi-agente ● 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.
  • 18. 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.
  • 19. 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.
  • 20. 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.
  • 21. Modelos de programação para programação de ambiente ● 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.
  • 22. Modelos de programação para programação de ambiente ● 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.
  • 23. Modelos de programação para programação de ambiente ● 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
  • 24. Modelos de programação para programação de ambiente ● Abstração; ● Ortogonalidade; ● Generalidade; ● Modularidade; ● Extensibilidade dinâmica; ● Reusabilidade. O modelo deve introduzir conceitos para modularizar ambientes, evitando visões monolítica e centralizada.
  • 25. Modelos de programação para programação de ambiente ● 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.
  • 26. Modelos de programação para programação de ambiente ● 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.
  • 27. Modelos de programação para programação de ambiente ● 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.
  • 28. Modelos de programação para programação de ambiente ● 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;
  • 29. 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);
  • 30. 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;
  • 31. 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.
  • 32. 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;
  • 33. 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;
  • 34. 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;
  • 35. 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
  • 36. 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;
  • 37. Ambientes baseados em artefatos Uma visão geral dos principais conceitos que caracterizam ambientes baseados em artefato
  • 38. Ambientes baseados em artefatos ● 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;
  • 39. Ambientes baseados em artefatos ● 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);
  • 40. Ambientes baseados em artefatos ● 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;
  • 41. Ambientes baseados em artefatos ● 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;
  • 42. Ambientes baseados em artefatos ● 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;
  • 43. 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
  • 44. 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))
  • 45. Usando e observando os artefatos
  • 46. Usando e observando os artefatos
  • 47. 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;
  • 48. 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;
  • 49. CArtAgO (Common ARtifact infrastructure for AGent Open environments) ● 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
  • 50. CArtAgO (Common ARtifact infrastructure for AGent Open environments)
  • 51. Um outro exemplo ilustrando o uso de sinais
  • 52. CArtAgO (Common ARtifact infrastructure for AGent Open environments) ● 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;
  • 53. CArtAgO (Common ARtifact infrastructure for AGent Open environments)
  • 54. CArtAgO (Common ARtifact infrastructure for AGent Open environments) ● Resultado da execução
  • 55. 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
  • 56. Aplicação para programação de sistemas multi-agente ● 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);
  • 57. 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.
  • 58. // 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
  • 59. 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.
  • 60. 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).
  • 61. 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
  • 62. 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). Berlin/Heidelberg: Springer. ● 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). Berlin/Heidelberg: Springer.
  • 63. 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). Berlin/Heidelberg: Springer. – 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.
  • 64. 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.