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 RicciMichele PiuntiMirko Viroli

Dados da publicação:Autonomous Agents and Multi-Agent Systems

Vol. 23 num. 2 ano 2011DOI: 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




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.


● 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.




O modelo deve ser o mais ortogonal possível em relação aos modelos, arquiteturas, linguagensde programação do agente, de modo a naturalmente suportar a engenharia de sistemas heterogêneos.




O modelo deve ser geral e expressivo o suficiente para permitir o desenvolvimento de diferentes tipos de ambiente de acordo com diferentesdomínios e problemas de aplicação, explorando o mesmo conjunto básico de conceitos e construções




O modelo deve introduzir conceitos para modularizar ambientes, evitando visões monolítica e centralizada.




O modelo deve suportar a construção dinâmica, substituindo, extensão de partes do ambiente, em uma perspectiva de sistema aberto.



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


agente● Ambientes baseados em artefatos e

CArtAgO. ● Aplicação para programação de sistemas


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;


● 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

Um outro exemplo ilustrando o uso de sinais


● 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;


● Resultado da execução

Agenda




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";

}

@OPERATIONvoid 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; //buyprintln("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




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.

ambientes em sistemas multi-agentes

Documents