desenvolvimento de um algoritmo para problema de...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIENCIAS EXATAS E NATURAIS
CURSO DE CIENCIAS DA COMPUTACAO – BACHARELADO
DESENVOLVIMENTO DE UM ALGORITMO
PARA PROBLEMA DE SATISFACAO DE
RESTRICAO DISTRIBUIDA
DANIEL MOSER TRALAMAZZA
BLUMENAU2004
2004/I-6
DANIEL MOSER TRALAMAZZA
DESENVOLVIMENTO DE UM ALGORITMO
PARA PROBLEMA DE SATISFACAO DE
RESTRICAO DISTRIBUIDA
Trabalho de Conclusao de Curso submetidoa Universidade Regional de Blumenau para aobtencao dos creditos na disciplina Trabalhode Conclusao de Curso II do curso de Cienciada Computacao – Bacharelado.
Prof. Jomi Fred Hubner – Orientador
BLUMENAU2004
2004/I-6
DESENVOLVIMENTO DE UM ALGORITMOPARA PROBLEMA DE SATISFACAO DE
RESTRICAO DISTRIBUIDA
Por
DANIEL MOSER TRALAMAZZA
Trabalho aprovado para obtencao doscreditos na disciplina de Trabalho de Con-clusao de Curso II, pela banca examinadoraformada por:
Presidente: Prof. Jomi Fred Hubner – Orientador, FURB
Membro: Prof. Paulo Cesar Rodacki Gomes, FURB
Membro: Prof. Claudio Loesch, FURB
BLUMENAU2004
AGRADECIMENTOS
Agradeco meu orientador, minha famılia e namorada.
RESUMO
Este trabalho esta inserido no contexto dos Distributed Constraint Satisfaction Problems(DCSP). DCSP sao problemas que podem ser caraterizados pela distribuicao geograficadas informacoes, normalmente representadas como restricoes sobre os valores que determi-nadas variaveis podem assumir e sua resolucao consiste em encontrar valores consistentespara estas variaveis. Existem varios algoritmos para sua resolucao, sendo que os primeirosforam propostos por Yokoo et al. (1992). Este trabalho especificou (utilizando Orientacaoa Objetos), implementou (em linguagem Java) e analisou empiricamente o algoritmo AWCproposto por Makoto. Os principais resultados sao: (i) o impacto do numero de maquinasno desempenho do algoritmo e (ii) a proposta de novas heurısticas para o AWC.
Palavras Chave: IA, CSP, DCSP, SMA, Sistemas distribuıdos.
ABSTRACT
This work is concerned with Distributed Constraint Satisfaction Problems (DCSP).DCSP are problems that have their information geographicaly distributed. There infor-mation are normally represented as constraints over the values that variables can assume,the DCSP resolution consists of finding consistent values for its variables. There are se-veral algorithms for its resolution, the first were proposed by Yokoo et al. (1992). Thiswork has specified (using Object Orientation), implemented (in the Java language) andanalyzed the AWC algorithm proposed by Makoto. The main results are: (i) the impactof the number of machines in the performance of the algorithm and (ii) new heuristicsproposals for the AWC.
Key-Words: AI, CSP, DCSP, MAS, Distributed Systems.
LISTA DE ILUSTRACOES
Figura 2.1 – Exemplo de coloracao de grafo. . . . . . . . . . . . . . . . . . . . . 14
Figura 2.2 – Problema das N-Rainhas, onde N=4. . . . . . . . . . . . . . . . . 14
Figura 2.3 – Exemplo de um laco de avaliacao. . . . . . . . . . . . . . . . . . . 16
Figura 2.4 – Ordenacao das variaveis do problema das 4 rainhas. . . . . . . . . 17
Figura 2.5 – Algoritmo ABT adaptado de Yokoo (2001). . . . . . . . . . . . . . 19
Figura 2.6 – Exemplo de ordenacao AWC. . . . . . . . . . . . . . . . . . . . . . 20
Figura 2.7 – Exemplo de ma escolha de valores. . . . . . . . . . . . . . . . . . . 20
Figura 2.8 – Algoritmo AWC adaptado de Yokoo (2001). . . . . . . . . . . . . . 21
Figura 3.1 – Pacotes do framework para DCSP. . . . . . . . . . . . . . . . . . . 24
Figura 3.2 – Interface de comunicacao. . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 3.3 – Interface Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 3.4 – Parametros de execucao. . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 3.5 – Exemplo de execucao. . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 3.6 – Monitor do SACI . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 3.7 – Solucao encontrada utilizando circulating token. . . . . . . . . . . 29
Figura 3.8 – Classe base de um algoritmo distribuıdo. . . . . . . . . . . . . . . 30
Figura 3.9 – Classe para guardar a prioridade da variavel. . . . . . . . . . . . . 31
Figura 3.10 – Classe AWC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 3.11 – Rotinas do AWC. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 3.12 – Tempo de execucao do AWC. . . . . . . . . . . . . . . . . . . . . . 34
Figura 3.13 – Tempo de execucao do AWC e AWC+. . . . . . . . . . . . . . . . 35
SUMARIO
1 Introducao 11
1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Estrutura do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Revisao Bibliografica 13
2.1 Constraint Satisfaction Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Distributed Constraint Satisfaction Problem . . . . . . . . . . . . . . . . . . . 15
2.3 Asynchronous Backtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Asynchronous Weak Commitment . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Desenvolvimento 23
3.1 Visao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 Pacote de Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Pacote de Entrada e Saıda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.3 Pacote de Inicializacao e Controle . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.4 Deteccao de parada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.5 Pacote de Algoritmos DCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Especificacao do algoritmo AWC . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Implementacao do AWC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Proposta de melhorias para o AWC . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.1 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Conclusoes 36
4.1 Extensoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Referencias Bibliograficas 37
11
1 INTRODUCAO
Um problema de satisfacao de restricoes, em ingles Constraint Satisfaction Problem
(CSP), e uma forma simples de se representar alguns problemas na Inteligencia Artificial
(IA). Os CSPs constituem uma classe de problemas que pode ser expressa por um con-
junto de variaveis ligadas por um conjunto de restricoes. As variaveis representam o
estado do problema e seus domınios podem ser finitos (enumeracoes) ou infinitos (con-
junto dos numeros inteiros, por exemplo). Uma restricao pode ser tanto uma simples
igualdade quanto uma formula matematica complexa e seu papel e de restringir o valor
das variaveis. A resolucao de um CSP consiste em encontrar e atribuir um valor para
cada variavel respeitando todas as restricoes impostas. Caso seja encontrado, este valor
e dito consistente.
Entretanto, em alguns casos, as informacoes que definem um CSP estao geogra-
ficamente distribuıdas, inviabilizando a utilizacao dos algoritmos tradicionais, que pres-
supoem que as informacoes possam ser centralizadas num determinado momento. A
solucao aparentemente obvia seria pedir para que todas as maquinas enviassem suas
variaveis e restricoes para um unico computador. Contudo esta solucao mostra-se inade-
quada pois o custo computacional necessario para isto poderia ser muito grande. Alem
disto, por motivos de seguranca ou de privacidade, certas aplicacoes nao podem permitir
que seus dados sejam transmitidos livremente por uma rede.
Tem-se entao uma nova classe de problemas chamada Distributed Constraint Satis-
faction Problem (DCSP). Em um DCSP, as variaveis e as restricoes estao distribuıdas em
multiplos agentes. Estes agentes podem estar em maquinas diferentes e utilizam uma rede
para se comunicar. O proposito basico do DCSP e considerar informacoes descentralizadas
e aumentar a eficiencia atraves do paralelismo.
Os primeiros algoritmos assıncronos completo para resolucao de DCSP foram de-
senvolvidos por Yokoo (2001) e sua equipe. Foram propostos tres algoritmos chamados
Asynchronous Backtracking (ABT), Asynchronous Weak Commitment (AWC) e Distri-
buted Breakout (DB). Analises preliminares apontaram algumas limitacoes destes algo-
ritmos:
a) nao se preocupam em detectar a parada;
b) manipulam apenas variaveis com domınios finitos;
1.1 Objetivo 12
c) os agentes sao apenas reativos, nao aproveitando o estado ocioso entre perıodos
sem comunicacao;
d) a completude do algoritmo e obtida com um alto custo computacional.
As duas primeiras limitacoes foram apontadas pelo proprio autor, sendo a terceira
e quarta motivacao para o desenvolvimento deste trabalho que tera por objetivo ameniza-
las.
1.1 OBJETIVO
O objetivo deste trabalho e epecificar, implementar, avaliar e propor melhorias
para o algoritmo AWC inicialmente proposto por Yokoo (2001).
1.2 ESTRUTURA DO TEXTO
O capıtulo seguinte inicia com as definicoes basicas de CSP (secao 2.1) necessarias
para a compreensao dos DCSP (secao 2.2). Suas sessoes (secao 2.3 e secao 2.4) descrevem
os dois algoritmos de DCSP especificados por Yokoo (2001). O capıtulo 3 descreve como
o objetivo deste trabalho foi alcancado. Para isso e especificado detalhadamente a imple-
mentacao do AWC, as extensoes propostas e a avaliacao dos resultados conseguidos. Por
fim, o capıtulo de conclusao resume os resultados e aponta para trabalhos futuros.
13
2 REVISAO BIBLIOGRAFICA
Yokoo e sua equipe, pioneiros na pesquisa sobre DCSP, desenvolveram tres algo-
ritmos capazes de solucionar um DCSP:
a) ABT, descrito na secao 2.3;
b) AWC, descrito na secao 2.4;
c) DB.
Estes algoritmos sao a principal fonte de inspiracao para este trabalho, dando-se
maior atencao aos dois primeiros. O terceiro (DB) possui caracterısticas muito diferen-
ciadas dos dois anteriores e por isso nao sera discutido. Para a melhor compreensao dos
algoritmos de resolucao de DCSP estudados neste trabalho, a secao seguinte define os
conceitos basicos sobre CSP.
2.1 CONSTRAINT SATISFACTION PROBLEM
Um CSP e formalmente definido por Tsang (1993):
a) um conjunto de variaveis x1, x2, ..., xn, cujos valores v1, v2, ..., vn pertencem a
domınios D1, D2, ..., Dn nao vazios;
b) um conjuto de restricoes C1, C2, ..., Cm sobre os valores.
Cada restricao afeta um subconjuto de variaveis, condicionando seus valores. Uma
atribuicao e dita consistente se esta nao violar nenhuma restricao. A solucao e encontrada
quando todas as variaveis possuirem um valor consistente (RUSSEL; NORVIG, 2003).
Este trabalho abordara principalmente CSP com variaveis de domınio finito e res-
tricoes contendo duas variaveis, tambem chamadas, restricoes binarias. Apesar da de-
finicao simples, varios problemas podem ser solucionados com CSP, como por exemplo,
alocacao de recursos, agendamento de tarefas, coloracao de grafos. De fato um CSP e
comumente representado como um grafo, onde os vertices sao as variaveis e as arestas as
restricoes, como exemplifica a fig. 2.1. A fig. 2.1 representa um CSP onde:
a) o conjunto de variaveis e {x1, x2, x3, x4} e todas possuem o mesmo domınio, que
no exemplo sao as cores D = {azul, verde, vermelho};b) o conjunto de restricoes e {x1 6= x3, x1 6= x4, x2 6= x4, x3 6= x4};c) um possıvel conjunto solucao e {x1 = azul, x2 = azul, x3 = verde, x4 =
2.1 Constraint Satisfaction Problem 14
vermelho}.
X1 X2
X3 X4
Figura 2.1 - Exemplo de coloracao de grafo.
Um problema classico em CSP e o das N-Rainhas, que consite em posicionar um
numero N (N ≥ 4) de rainhas em um tabuleiro de xadrez de dimensao NxN sem que
nenhuma rainha ameasse outra. A fig. 2.2 ilustra um exemplo onde N = 4. Uma forma
de representar este problema como um CSP e:
a) o conjunto de variaveis e {xi| 0 < i <= N} e cada variavel representa a posicao
de uma rainha;
b) o domınio da cada variavel xi e o conjuto de posicoes que uma rainha pode
ocupar na sua linha Di = {1..N}, esta reducao e possıvel pois nunca havera
duas rainhas em uma mesma linha;
c) o conjunto de restricoes entre duas rainhas xi e xj pode ser representado pelo
predicado (xi 6= xj) ∧ (|i− j| 6= | xi − xj|) (YOKOO, 2001) 1;
d) um possıvel conjunto solucao e {x1 = 3, x2 = 1, x3 = 4, x4 = 2}.
N
N
x4
x2
x1
x3
Figura 2.2 - Problema das N-Rainhas, onde N=4.
1Neste predicado a primeira diferenca da conjuncao garante que duas rainhas nao ocuparao a mesmacoluna e a segunda diferenca garante que duas rainhas nao ocuparao a mesma diagonal.
2.2 Distributed Constraint Satisfaction Problem 15
2.2 DISTRIBUTED CONSTRAINT SATISFACTION PROBLEM
Em um DCSP, as variaveis e restricoes estao distribuıdas entre agentes automa-
tizados (YOKOO, 2001). A diferenca fundamental entre os algoritmos para resolucao de
CSP e DCSP e a manipulacao do conhecimento. Enquanto em um algoritmo de CSP
o conhecimento do problema (variaveis e restricoes) e centralizado, em um algoritmo de
DCSP o conhecimento esta disperso entre diversos agentes, fazendo com que nenhum
agente sozinho conheca todo o problema. O impacto direto e o aumento da dificuldade
de ser ter uma visao global instantanea do problema, pois os agentes podem estar em
maquinas diferentes, com tempos de respostas diferentes.
O objetivo primario de um algoritmo de DCSP nao e alcancar maior eficiencia
atraves do paralelismo, mas sim tratar o conhecimento distribuıdo sem centraliza-lo. Este
conhecimento distribuıdo proporciona novos desafios e areas de estudo. Por exemplo,
pode-se desejar que os algoritmos considerem tempos de resposta mınimos, quedas de
agentes, problemas dinamicos (restricoes alteradas durante o processamento do algoritmo)
e seguranca ou privacidade dos dados trafegados.
2.3 ASYNCHRONOUS BACKTRACKING
No algoritmo ABT, os agentes agem concorrentemente, de forma assıncrona e sem
um controle global (YOKOO, 2001). O ABT foi o primeiro algoritmo desenvolvido por
Yokoo, ele e capaz de achar uma solucao para um DCSP, e caso esta nao existir, ele
cessara a execucao. Cada agente possui:
a) um identificador unico;
b) um conjunto de agentes diretamente conectados, chamados vizinhos;
c) para efeito de simplificacao, exatamente uma variavel xi com um valor vi per-
tencente a um domınio finito Di;
d) um conjunto de restricoes que afetam a variavel xi.
O objetivo de um agente e tornar sua variavel consistente, isto e, verificar se existe
um valor para sua variavel que satisfaca todas as restricoes. Contudo, a avaliacao de uma
restricao envolve os valores escolhidos por mais de um agente. Uma primeira forma de
resolver este problema e estabelecer que todos os agentes envolvidos em uma restricao a
avaliem. Porem, esta solucao inicial no controle das avaliacoes das restricoes por parte dos
agentes pode causar problemas de lacos infinitos. Um laco pode ocorrer, por exemplo, se
dois agentes que compartilham uma mesma restricao avaliarem esta restricao simultanea-
2.3 Asynchronous Backtracking 16
mente e enviarem seus novos valores um para o outro, reinvalidando a restricao (fig. 2.3).
Para evitar estes lacos infinitos de processamento, o ABT define uma ordenacao entre os
Figura 2.3 - Exemplo de um laco de avaliacao.
agentes, onde para cada restricao existe um agente que escolhe e envia seu valor e outro
que avalia a restricao. No ABT, esta ordenacao e estatica e definida pela ordem alfabetica
dos agentes atraves dos seus identificadores, a fig. 2.4 representa esta ordenacao para o
problema das 4 rainhas. No exemplo, as restricoes sao representadas pelas arestas digiri-
das, onde a variavel que recebe a aresta avalia a restricao. A variavel x1 possui a maior
prioridade e por isso apresenta o maior numero de arestas partindo para outras variaveis.
Para a comunicacao entre os agentes, o algoritmo ABT define dois tipos de men-
sagens:
a) ok? : enviada por um agente que escolheu um valor a um agente que avalia a
restricao para saber se o valor escolhido e aceitavel. No exemplo da fig. 2.4, x1
envia um ok? para x2, x3 e x4;
b) nogood : enviada por um agente que avaliou uma restricao para um agente que
escolheu um valor, indicando que houve uma violacao de restricao. No exemplo
da fig. 2.4, caso x2 nao consiga um valor consistente para si, um nogood sera
enviado para x1.
Cada agente tambem possui um conjunto de agentes, chamado vizinhos, que e
separado em dois outros sub conjuntos, Incoming formado pelos agentes que lhe enviam
ok? e Outgoing formado pelos agentes que lhe enviam nogood. Esta separacao e dada
pela direcao da aresta, como ilustra a fig. 2.4 e a tab. 2.1.
Cada agente possui um mapeamento de variaveis para valores chamado agent view,
este mapeamento representa a visao que o agente possui dos valores dos seus vizinhos.
O agent view nada mais e do que uma tabela de pares variavel/valor. Por exemplo, em
determinado momento o agent view do agente x4 poderia ser {x1 = 3, x2 = 1, x3 = 4}.
2.3 Asynchronous Backtracking 17
x4
x2
x1
x3
Figura 2.4 - Ordenacao das variaveis do problema das 4 rainhas.
Tabela 2.1 - Exemplo 4 Rainhas.
Agente Outgoing Incoming Domınio
x1 x2, x3, x4 - 1, 2, 3, 4x2 x3, x4 x1 1, 2, 3, 4x3 x4 x1, x2 1, 2, 3, 4x4 - x1, x2, x3 1, 2, 3, 4
Ao iniciar, cada agente escolhe um valor para sua variavel, o envia (send ok()) para
seus respectivos vizinhos e entra em modo de espera, aguardando novas mensagens. A
partir deste instante, o algoritmo e executado conforme ilustra a fig. 2.5. A cada mensa-
gem de ok recebida, a rotina received nogood e executada atualizando o agent view
e verificando a consistencia chamando a rotina check agent view. Um agent view e
consistente se este nao violar nenhuma das restricao do agente que inclua variaveis de
maior prioridade e nao for um nogood conhecido. Caso o agent view nao seja consistente,
o algoritmo tenta achar um valor consistente dentro do domınio Di. Se for achado, este
sera o valor atual da variavel, caso contrario o algoritmo executa o metodo backtrack.
Quando o algoritmo executa um backtrack ele esta sinalizando aos demais agentes
que nao conseguiu se tornar consistente. Para isto ele gera um nogood que no caso e o
proprio agent view. Este nogood gerado e entao enviado ao agente de menor prioridade
diretamente conectado. Cada nogood recebido e armazenado em uma lista chamada no-
goodlist sendo utilizada na checagem de consistencia do agent view. Cada item desta lista
(nogoodlist) pode ser visto como uma nova restricao, pois a rotina check agent view
verifica se o agentview e um nogood antigo conhecido. Armazenar tentativas passadas
garante que elas nao se repitam no futuro, porem, para certos domınios isto nao pode ser
2.4 Asynchronous Weak Commitment 18
aplicado, pois caso o domınio seja extenso/infinito o numero de nogoods possıveis tornaria
o processo inviavel ou ate impossivel, por exemplo o domınio dos numeros reais.
E importante notar que o algoritmo ABT detecta a parada por falha, caso o pro-
blema nao possua solucao, mas nao por sucesso, neste caso e necessario utilizar um algo-
ritmo auxiliar para detectar a parada.
2.4 ASYNCHRONOUS WEAK COMMITMENT
Pode-se dizer que o AWC (especificado na fig. 2.8) e uma versao aprimorada do
ABT. Ele possui as mesmas informacoes e mensagens que o ABT, entretanto existem
duas grandes diferencas:
a) a ordenacao dos agentes e dinamica;
b) a escolha de valores e feita com o auxılio de uma heurıstica.
Enquanto no ABT a ordem entre os agentes e apenas alfabetica, no AWC cada
agente possui um valor inteiro de prioridade, que e enviado junto com cada mensagem. O
valor da prioridade so e modificado quando ocorre backtrack sinalizando que este agente
nao conseguiu achar um valor consistente, logo a sua prioridade aumenta e os seus vizinhos
agora precisam avaliar suas restricoes. Caso dois agentes possuam o mesmo valor, a ordem
alfabetica e utilizada. O exemplo da fig. 2.6 ilustra tres variaveis e suas prioridades (entre
parenteses). Gracas a este valor, a variavel x3 possui maior prioridade que x2. Em funcao
desta prioridade dinamica, os agentes podem revisar uma ma escolha cometida por um
agente de prioridade mais alta sem precisar executar uma busca exaustiva. O exemplo
da fig. 2.7 demonstra tal situacao. Os cırculos representam as rainhas e os numeros entre
parenteses suas prioridades. Ao iniciar a execucao, todos posseum prioridades iguais
a zero, logo a ordem alfabetica e utilizada e por isto apenas a variavel x4 encontra-se
inconsistente. Como x4 nao consegue nenhum valor consistente dentro do domınio, ela ira
criar e enviar um nogood, aumentar sua prioridade para 1, escolher um valor que possua o
menor conflito (neste caso a posicao 3) e enviar uma mensagem de ok? apos escolher seu
valor. Ao receber a mensagem de ok? a variavel x3 tambem nao possui valor consistente,
pois agora x4 possui maior prioridade. Logo x3 tambem envia nogood, incrementa sua
prioridade para 2, escolhe um valor e envia um ok?. A variavel x2 esta consistente porem
x1 nao. A variavel x1 muda seu valor para dois, torna-se consistente e a execucao e
encerrada.
Na fig. 2.7 se a primeira rainha ocupar a primeira posicao o problema nao tera
solucao. No ABT isto so e detectado depois que todos os agentes de menor prioridade
2.4 Asynchronous Weak Commitment 19
received ok(xj, dj)1 add(xj, dj) to agent view;2 check agent view();
received nogood(xj, nogood)1 add(nogood) to nogoodlist;2 if xk ← (6∈ links and ∈ nogood)3 then request addlink(xk, xi);4 add(xk, dk) to agent view;5 old value ← current value;6 check agent view();7 if old value = current value8 then send ok(xj, current value, xj);
check agent view()1 if agent view is not consistent with current value2 then if no value in Di is consistent with agent view3 then backtrack();4 else select d ∈ Di where agent view and d are consistent;5 current value ← d;6 send ok(xi, d) to outgoing links;
backtrack()1 nogoods ← {V |V = inconsistent subset of agent view};2 if nogoods = {}3 then broadcast nosolution();4 return5 for each V ∈ nogoods6 do select (xj, dj) where xj has the lowest priority;7 send nogood(nogood, xi, V ) to xj;8 remove (xj, dj) from agent view;9 check agent view();
Figura 2.5 - Algoritmo ABT adaptado de Yokoo (2001).
2.4 Asynchronous Weak Commitment 20
executarem seu backtrack, como a primeira rainha possui a maior prioridade, logo, todos
os outros agentes terao de mudar de valor ate retornarem com um backtrack para a
primeira rainha. No caso do AWC isto nao acontecera, porque sera forcada uma troca
de prioridade fazendo com que a primeira rainha tenha que trocar de posicao sem a
necessidade de executar todos os backtrack das variaveis de menor prioridade.
x1(1) x3(1) x2(0)
Figura 2.6 - Exemplo de ordenacao AWC.
0
0
2
1 1
2
0
0
1
0 0
0
0
0
0
0
Figura 2.7 - Exemplo de ma escolha de valores.
O algoritmo ABT nao especifica a forma de escolha dos valores, por padrao o
domınio e percorrido sequencialmente e o primeiro valor consistente e utilizado. O AWC
utiliza a heurıstica do menor conflito para a escolha do valor (MINTON et al., 1992). A
heurıstica consiste em: ao escolher um valor para a variavel, se existir mais de um valor
consistente, deve-se preferir o valor que possua o menor numero de violacoes de restricoes
com variaveis de menor prioridade. Esta estrategia tenta escolher um valor que possua
uma probabilidade mais alta de ser aceita pelos vizinhos, pois menos agentes precisarao
trocar de valor.
2.4 Asynchronous Weak Commitment 21
received ok(xj, dj, priority)1 add(xj, dj, priority) to agent view;2 check agent view();
received nogood(xj, nogood)1 add(nogood) to nogoodlist;2 if xk ← (6∈ neighbors and ∈ nogood)3 then add(xk) to neighbors;4 add(xk, dk, priority) to agent view;5 check agent view();
check agent view()1 if agent view isnot consistent with current value2 then if no value in Di is consistent with agent view3 then backtrack()4 else select d ∈ Di where agent view and d are consistent and use minconflict;5 current value ← d;6 send ok(xi, d, current priority) to neighbors;
backtrack()1 nogoods ← {V |V = inconsistent subset of agent view};2 if nogoods = {}3 then broadcast nosolution();4 return5 if nogoods 6∈ nogood sent6 then for each V ∈ nogoods7 do add(V ) to nogood sent;8 for each (xj, dj, pj) ∈ V9 do send nogood(nogood, xi, V ) to xj;
10 pmax ← max(xj ,dj ,pj)∈agent view(pj);11 current priority ← 1 + pmax;12 select d ∈ Di using minconflict;13 current value ← d;14 send ok(xi, d, current priority) to neighbors;
Figura 2.8 - Algoritmo AWC adaptado de Yokoo (2001).
2.5 Consideracoes Finais 22
2.5 CONSIDERACOES FINAIS
Algoritmos para DCSP apresentam diversos desafios aos desenvolvedores, princi-
palmente na sua implementacao. Por serem distribuıdos (e por isto nao determinısticos)
dificultam o acompanhamento da execucao. Os algoritmos descritos por Yokoo (2001)
encontram-se especificados em pseudo linguagem com um alto grau de abstracao, o que
tornou sua compreensao e implementacao demorada e propensa a erros de interpretacao.
23
3 DESENVOLVIMENTO
Neste capıtulo sera inicialmente detalhado o framework (DynDCSP. . . , 2004) em que
o prototipo foi desenvolvido (secao 3.1). Posteriormente e apresentada a especificacao
(secao 3.2), a implementacao (secao 3.3) e avaliacao do prototipo (secao 3.5).
3.1 VISAO GERAL
Este trabalho esta inserido em um framework para DCSP desenvolvido pelo grupo
de pesquisa de IA da Fundacao Universidade Regional de Blumenau (FURB). O fra-
mework possui dois grandes modulos: CSP e DCSP (fig. 3.1).
O modulo CSP contem classes capazes de formalizar, modelar e manipular um CSP
completo, entre seus pacotes destacam-se:1
a) Examples : Instancias de problemas de CSP parametrizaveis para testes;
b) Domains : Prove suporte a diversos domınios de variaveis;
c) Expression: Avalia e soluciona expressoes numericas e logicas.
As principais classes destes pacotes sao as seguintes:
a) Variable: Representa uma variavel do CSP e seu domınio (definido no pacote
Domains);
b) Value: Armazena um valor para uma variavel;
c) Instantiation: Armazena um mapeamento de variaveis para valores, e utilizado
para representar solucoes de um CSP;
d) Constraint : Encapsula uma expressao logica (definida no pacote Expressions)
que representa uma restricao de um CSP.
O modulo DCSP preocupa-se com a resolucao do DCSP, seus principais pacotes
sao:
a) Communication: Executa a comunicacao entre os agentes;
b) IO : Implementa saıda e formatacao dos dados em diferentes mıdias;
c) Algorithms : Implementa os algoritmos estudados alem do proprio prototipo;
d) Main: Inicia e coordena a execucao do problema.
1Em (DynDCSP. . . , 2004) pode ser consultada a documentacao detalhada das classes do framework.
3.1 Visao Geral 24
Como os pacotes deste modulo estao relacionados com o algoritmo implementado
neste trabalho, as proximas secoes descrevem brevemente cada um de seus pacotes.
DCSP
Algorithms
Comm IOMain
CSP
Expression
ExamplesDomains
Figura 3.1 - Pacotes do framework para DCSP.
3.1.1 PACOTE DE COMUNICACAO
Por ser um algoritmo distribuıdo, a comunicacao entre os agentes representa um
dos principais papeis na sua execucao. Para gerenciar esta comunicacao, o prototipo
possui uma camada generica, que abstrai o tipo de comunicacao utilizada, como ilustra a
fig. 3.2.
Communication
+tell(Message:msg): void+ask(Message:msg,timeout:int): Message+createMessage(id:String): Message+addMessageHandler(id:String,handler:MessageHandler): void
SaciCommunication
+initAg(args:String[]): void+stopAg(): void
Agent
+initAg(args:String[]): void
Figura 3.2 - Interface de comunicacao.
A maioria dos metodos da interface Communication fazem referencia a classe Mes-
sage. A classe Message carrega a informacao de um agente para o outro. As informacoes
estao contidas em uma lista de parametros da mensagem. Cada mensagem deve conter
3.1 Visao Geral 25
um parametro chamado receiver que indica o seu destino. O destino e o identificador
unico de cada agente, neste caso o nome da variavel do agente.
A interface Communication descreve poucos metodos a serem implementados,
sendo os principais:
a) createMessage: cria uma nova instancia da classe Message, no caso uma men-
sagem do tipo indicado pelo parametro id ;
b) tell : encaminha uma mensagem conforme seus parametros;
c) ask : encaminha uma mensagem e espera por um tempo determinado uma men-
sagem de resposta;
d) addMessageHandler : permite que um determinado tipo de mensagem, indicado
pelo parametro id, seja tratado pelo objeto handler passado tambem como
parametro.
O prototipo utiliza a classe concreta chamada SaciCommunication para executar
a comunicacao. A classe SaciCommunication implementa a interface Communication e
e derivada da classe saci.Agent que faz parte da ferramenta Simple Agents Communica-
tion Infrastructure (SACI) desenvolvida por Hubner e Sichman (2000). O SACI e uma
ferramenta criada para implementar a comunicacao de Sistemas Multiagentes (SMA) que
utiliza o Remote Method Invocation (RMI) do Java para a transmissao das mensagens.
O metodo initAg e chamado pelo SACI para iniciar um novo agente. O SACI foi esco-
lhido pela sua simplicidade, versatilidade e boa documentacao, agilizando o processo de
implementacao dos agentes bem como seu monitoramento.
3.1.2 PACOTE DE ENTRADA E SAIDA
Os comandos de Input/Output (IO) abstraem o tipo da saıda de informacoes nas
varias classes do framework utilizando a interface Console (fig. 3.3). O framework possui
tres implementacoes basicas desta interface:
a) TextConsole: Saıda de texto no prompt de execucao;
b) GuiConsole: Saıda de texto em uma janela grafica (uma janela por agente);
c) NullConsole: Nenhuma saıda e exibida.
Cada agente possui um objeto agregado que implementa a interface Console. A
escolha do console e feita localmente pelo agente conforme parametros enviados durante
a sua criacao.
3.1 Visao Geral 26
Console
+print(str:String): void+println(str:String): void+showCurrentValue(value:Value): void
GUIConsole TextConsole NullConsole
Figura 3.3 - Interface Console.
3.1.3 PACOTE DE INICIALIZACAO E CONTROLE
Para executar o prototipo e necessario entender seus dois processos distintos: laun-
cher e managerAg. O processo launcher e executado em cada maquina que fara parte da
computacao, isto porque o launcher e encarregado de criar os agentes. Todos os laun-
chers executados sao automaticamente reconhecidos e gerenciados pelo SACI (fig. 3.6).
O processo managerAg e responsavel por criar o CSP, distribuı-lo entre os launchers dis-
ponıveis e iniciar cada agente. Por padrao o managerAg tenta distribuir igualmente os
agentes entre as maquinas. Para facilitar a configuracao das execucoes um arquivo de
propriedades (fig. 3.4), no formato chave = valor, define diversos parametros passados
para o managerAg. O arquivo de propriedades precisa especificar ao menos os seguintes
parametros:
a) algorithm: Algoritmo DCSP utilizado;
b) console: Tipo de IO;
c) comm: Tipo de comunicacao;
d) csp.factory : Classe construtora do problema CSP.
csp.factory=csp.examples.nqueens.NQueensCSPFactory
society.name=dcsp
console=textcomm=sacialgorithm=awc
numberOfQueens=40
Figura 3.4 - Parametros de execucao.
Para iniciar a execucao o managerAg precisa receber como primeiro parametro o
nome do arquivo de propriedades. O processo de execucao exemplificado pela fig. 3.5 e
3.1 Visao Geral 27
composto por tres etapas identificadas por A, B, C e D.
launcherMaster
launcher
agent
managerAg
A)
C)
D)
B)
Figura 3.5 - Exemplo de execucao.
Na etapa A apenas o processo launcherMaster foi iniciado. O launcherMaster e
um launcher que apenas grava em um arquivo o nome da maquina onde esta sendo execu-
tado para que futuros launchers possam saber onde ele esta. Apos o launcherMaster estar
iniciado, os outros launchers sao iniciados (etapa B) nas demais maquinas da rede. Na
etapa C, o processo managerAg foi iniciado em uma das maquinas da rede, o que desen-
cadeou a criacao de tres agentes por maquina e o inıcio da execucao (etapa D). Quando o
termino e detectado (secao 3.1.4), o managerAg grava, por padrao em um arquivo texto,
um log da resolucao do DCSP contendo a solucao, o tempo gasto e estatısticas.
3.1 Visao Geral 28
Figura 3.6 - Monitor do SACI
3.1.4 DETECCAO DE PARADA
O framework implementa um mecanismo de deteccao de parada, pois os algoritmos
estudados por este trabalho nao detectam a parada por sucesso, somente por falha2. O
mecanismo utiliza o algoritmo circulating token de Raynall (1992). Este algoritmo foi
escolhido por sua simplicidade e pouco impacto sobre a implementacao existente. Nao
foi necessario modificar muito o codigo existente para adaptar a deteccao de parada. O
algoritmo circulating token possui as seguintes caracterısticas:
a) Para seu funcionamento e necessario estabelecer uma lista circular entre os
agentes que compoem o problema, para isso cada agente possui o identificador
do seu proximo vizinho;
b) Cada agente possui um flag que indica seu estado de consistencia, o algoritmo
utiliza uma variavel que aceita duas cores: branco, preto;
c) Uma mensagem, chamada token, contendo a informacao de parada circula pela
rede formada pelos agentes.
O algoritmo inicia enviando uma mensagem para o primeiro agente da fila contendo
um token, este por sua vez contem um contador e a solucao parcial do problema. O token
permanece no agente enquanto este for inconsistente (preto). Sempre que um token deixa
um agente seu contador interno e incrementado e a variavel/valor do agente e inserida
2Nao existe solucao possıvel.
3.1 Visao Geral 29
na solucao parcial. Tokens de prioridade inferior sao descartados sempre que encontram
um de maior. O algoritmo detecta a parada quando seu contador for igual ao numero de
agentes na rede e todos eles estiverem consistentes (brancos) fig. 3.7.
x1
x2
x3
x4
Figura 3.7 - Solucao encontrada utilizando circulating token.
3.1.5 PACOTE DE ALGORITMOS DCSP
Os algoritmos implementados pelo framework possuem diversas caracterısticas e
necessidades comuns entre si:
a) variavel do agente;
b) valor atual;
c) lista de restricoes;
d) console para saıda de dados;
e) interface de comunicacao entre agentes.
O pacote Algorithms do framework possui uma classe base chamada BaseAlg
(fig. 3.8) que implementa estas necessidades basicas de um algoritmo DCSP. A classe
BaseAlg possui apenas um metodo abstrato chamado start que e chamado para indicar
o inıcio da execucao. Os algoritmos estudados por este trabalho e o prototipo derivam
diretamente de BaseAlg.
Os principais atributos e metodos da classe BaseAlg sao os seguintes:
a) fConstraints : Lista de objetos Constraint que o agente deve avaliar;
b) fNogoods : Lista de objetos Instantiation representando os nogoods recebidos;
c) fNeighboorsAgs : Lista de nomes dos agentes diretamente conectados;
d) fAgentView : Lista de objetos Instantiation representando a visao atual
(agent view) do agente;
e) fCurrentValue: Valor atual da variavel do agente;
3.2 Especificacao do algoritmo AWC 30
Figura 3.8 - Classe base de um algoritmo distribuıdo.
f) fVariable: Variavel do agente;
g) fComm: Interface de comunicacao entre agentes;
h) fConsole: Interface de entrada e saıda;
i) start(): Marca o inicio da execucao do agente;
j) isConsistent(): Avalia a consistencia do valor atual da variavel e do agent view.
3.2 ESPECIFICACAO DO ALGORITMO AWC
Como visto anteriormente, uma das principais diferencas do AWC em relacao ao
ABT e a prioridade dinamica do AWC. O AWC utiliza uma classe chamada PriorityVari-
able (fig. 3.9) para representar sua variavel. A classe PriorityVariable deriva de Variable e
possui um atributo para guardar sua prioridade e desta forma a associacao entre variavel
e prioridade e garantida.
O metodo compareTo, sobreescrito pela classe, e utilizado por classes como Hash-
Map e TreeMap, ambas pertencentes ao pacote Collections do Java, para garantir a or-
denacao de acordo com o valor de prioridade da classe.
O algoritmo AWC e implementado pela classe de mesmo nome. A classe AWC
deriva diretamente de BaseAlg e possui as seguintes diferencas:
a) fNogoodSent : Lista de nogoods recebidos;
3.3 Implementacao do AWC 31
Figura 3.9 - Classe para guardar a prioridade da variavel.
b) getMinConflict(): Retorna o valor que causa o menor numero de conflitos (in-
consistencias);
c) getConstraintViolations(): Retorna o numero de restricoes violadas.
AWC+fNogoodSent: List#getMinConflictValue(solution:Instantiation): Value#getConstraintViolations(solution:Instantiation): int
BaseAlg
Figura 3.10 - Classe AWC.
3.3 IMPLEMENTACAO DO AWC
A implementacao foi realizada na linguagem Java utilizando o JDK 1.4.2 da Sun
e o editor Eclipse versao 2.13. A escolha da linguagem foi feita considerando os aspectos
abaixo:
a) Excelente suporte a Orientacao a Objetos (OO);
b) Camada de comunicacao ja existente;
c) Facilidade de pesquisa.
3.4 Proposta de melhorias para o AWC 32
getMinConflict(Instantiation solution)1 tmpSolution ← clone of solution;2 for each value ∈ fV ariable.domain3 do tmpSolution[fV ariable] ← value;4 count = getConstraintViolations(tmpSolution);5 if count < minCount6 then minCount ← count;7 minV alue ← value;8 return minV alue;
getConstraintViolations(Instantiation solution)1 vars ← lower priority variables;2 count ← 0;3 for each cons ∈ fConstraints4 do if cons.variables ∈ vars5 then if cons is inconsistent6 then count ← count + 1;7 return count;
Figura 3.11 - Rotinas do AWC.
Como ja foi mencionado, o AWC possui poucos metodos alem dos existentes na
classe base. O pseudo codigo dos dois principais metodos do algoritmo AWC estao espe-
cificados na 3.11.
3.4 PROPOSTA DE MELHORIAS PARA O AWC
Como extensao para AWC este trabalho propoe as seguintes melhorias:
Heurıstica para escolha do valor : Um dos pontos cruciais de qualquer algoritmo
de CSP e a escolha dos valores a serem atribuidos. Durante os experimentos foi
constatado que certos valores sao escolhidos repetidas vezes gerando avaliacoes des-
necessarias. Apesar de utilizar a tecnica de min-conflict, o AWC pode comecar
a favorecer sempre os mesmos valores. Levando isto em consideracao, uma nova
heurıstica chamada de valores menos utilizados e proposta. A heurıstica consiste
em: para cada valor no domınio associa-se um contador de escolhas. Cada vez que
o algoritmo escolhe um valor seu contador incrementa. Quando um valor estiver
sendo escolhido deve ser dar preferencia ao que possuir o menor contador.
Ordenacao das restricoes : Para cada restricao o algoritmo mantem um contador, este
contador e inicializado com zero e e incrementado cada vez que sua restricao violar
a consistencia do agente. A lista de restricoes e mantida ordenada pelo contador,
3.5 Resultados 33
logo, as restricoes que mais vezes geraram inconsistencias serao as primeiras a se-
rem analisadas. Desta forma existe maior probabilidade de menos restricoes serem
avaliadas para detectar uma inconsistencia.
Nao armazenamento dos nogoods recebidos : Para garantir a completude do algo-
ritmo, o AWC guarda todos os nogoods recebidos. Como os domınios utilizados
sao finitos, o numero de combinacoes de nogoods e finito tambem, logo, no pior
caso o algoritmo guarda todos os nogoods possıveis. Esta abordagem possui dois
problemas:
a) Se o domınio for muito extenso a quantidade de memoria necessaria para
guardar todos os nogoods pode ser insuficiente;
b) A pesquisa por nogoods conhecidos e um processo lento, pois e necessario
percorrer sequencialmente todos os nogoods armazenados, para tentar
achar um nogood compatıvel 3.
A partir dessas observacoes, uma melhoria proposta e eliminar o armazenamento de
nogoods em detrimento da perda da completude.
3.5 RESULTADOS
Para monitorar as execucoes dos algoritmos foram criadas versoes especializadas
dos algoritmos. Estas versoes modificadas possuem as seguintes informacoes:
a) Numero de mensagens recebidas e enviadas;
b) Numero de atualizacoes feitas ao agentview ;
c) Numero de checagens de consistencia;
d) Numero de colisoes com nogood conhecidos;
e) Tempo de resolucao do problema das CSP.
Os valores acima medem nao so o trafego gerado na rede, como tambem o quao exposto
o CSP esta e a eficiencia com que o algoritmo gera seus valores.
A configuracao do ambiente utilizado para os testes foi: Rede de 100Mbit com 40
computadores Pentium 3 1GHz, 256 RAM, Sistema Operacional (SO) Conectiva Linux
9. Cada algoritmo foi testado utilizando o problema das 40-Rainhas variando o numero
de computadores de 1 ate 40. Para a geracao dos graficos seguintes, foram realizadas
varias execucoes com o mesmo numero de maquinas, obtida a media aritmetica dos va-
lores e tracado uma linha desenhada por interpolacao por curva de Bezier com os pontos
3Um nogood e compatıvel se suas variaveis e valores estiverem contidas no agent view.
3.5 Resultados 34
resultantes.
O grafico da fig. 3.12 apresenta os resultados obtidos pelo algoritmo AWC como
definido pelo Yokoo (2001), permitindo as seguintes conclusoes:
a) O desempenho do algoritmo foi similiar ao descrito por (YOKOO, 2001);
b) Para este problema (40-Rainhas), a partir de 25 maquinas a inclusao de novas
maquinas nao apresenta melhorias significativas;
c) A partir de 38 maquinas o desempenho piora com a inclusao de novas maquinas,
em razao do custo de comunicacao em rede.
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 5 10 15 20 25 30 35 40
tem
po (
em s
egun
dos)
nro de hosts
Figura 3.12 - Tempo de execucao do AWC.
O algoritmo proposto utilizou o AWC original como base e adaptou a heurıstica
do valor menos utilizado e o nao armazenamento de nogoods. O prototipo desenvolvido
e identificado pela sigla AWC+ e como e ilustrado pelo grafico comparativo da fig. 3.13
as modificacoes propostas possibilitaram um aumento significativo no desempenho. O
fator que mais contribuiu para o aumento do desempenho foi o nao armazenamento de
nogoods. A heurıstica proposta (ordenacao dos valores menos utilizados) foi utilizada
com sucesso, auxiliando a heurıstica de min-conflict. Mesmo em problemas que possuıam
poucas variaveis por computador o ganho de velocidade foi perceptıvel. O impacto da
3.5 Resultados 35
ordenacao de restricoes nao pode ser medido com exatidao ou nao surtiu efeito, pois os
valores obtidos foram muito proximos.
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 5 10 15 20 25 30 35 40
tem
po (
em s
egun
dos)
nro de hosts
AWCAWC+
Figura 3.13 - Tempo de execucao do AWC e AWC+.
3.5.1 DIFICULDADES ENCONTRADAS
O desenvolvimento do algoritmo original AWC tomou uma grande parte do tempo
de implementacao do prototipo, parte disto deve-se a traducao do codigo especificado
em pseudo linguagem para Java. O fato do algoritmo ser distribuıdo e implementado
utilizando RMI inviabilizou a depuracao, tornando o desenvolvimento e a identificacao
de erros bastante demorados. Ocorreram pequenos problemas relacionados com o RMI
quando executado no sistema operacional Linux utilizando o Java Virtual Machine (JVM)
da IBM ou Sun (versao 1.4.2). Uma caracterıstica que dificulta a implementacao e sincro-
nismo entre as threads de um mesmo agente. Cada mensagem e tratada por uma thread
diferente, isto exige que dados modificados por estas mensagens, como agent view, por
exemplo, sejam sincronizados e protegidos contra modificacoes concorrentes.
36
4 CONCLUSOES
Uma das maiores contribuicoes deste trabalho e a especificacao e implementacao dos
algoritmos propostos por Yokoo (2001). O prototipo alcancou bons resultados e evidenciou
que a busca pela completude do algoritmo AWC, guardando os nogoods recebidos para
isto, causa grande perda de desempenho. Foi notado que a escolha de valores possui papel
importante na execucao, podendo diminuir o numero de tentativas, com isto aumentar o
desempenho e diminuir o grau de exposicao do problema.
4.1 EXTENSOES
Por ser um assunto atual e relativamente pouco explorado, a area de DCSP possui
diversas opcoes de pesquisa, como por exemplo:
a) Comunicacao dos dados, seguranca e privacidade (SILAGHI, 2002);
b) DCSP dinamico, onde as restricoes e variaveis do problema podem ser modifi-
cadas durante a execucao do algoritmo (MODI et al., 2001);
c) Novas heurısticas para escolha de valores (PETCU; FALTINGS, 2004);
d) Estudo de completude de algoritmos distribuıdos;
e) Novos algoritmos, como por exemplo Asynchronous Distributed Constraint Op-
timization with Quality Guarantees (ADOPT) (MODI WEIMIN SHEN; YOKOO,
2003) e Asynchronous Search with Aggregations (AAS) (SILAGHI, 2002).
Alem dos supra citados, o proprio framework onde este trabalho esta inserido possui
extensoes propostas:
a) Desenvolvimento de uma linguagem para especificacao de CSP;
b) Formalizacao e implementacao de uma aplicacao real que utilize DCSP.
Durante a confeccao deste trabalho, foi observado que os algoritmos estudados se
comportam como agentes puramente reativos, isto e, o algoritmo atua apenas quando um
de seus metodos e chamado, de maneira analoga a um objeto em OO, porem distribuıdo.
Esta e uma caracterıstica importante e pode ser utilizada para estudos futuros, como por
exemplo em um melhor uso do tempo ocioso ou tornando os agentes mais pro-ativos.
37
REFERENCIAS BIBLIOGRAFICAS
DynDCSP Project. Blumenau: [s.n.], 2004. Disponıvel em: <www.inf.furb.br/gia-/dynDCS>. Acesso em: 15 jul. 2004.
HUBNER, J. F.; SICHMAN, J. S. SACI: Uma ferramenta para implementacaoe monitoracao da comunicacao entre agentes. In: INTERNATIONAL JOINTCONFERENCE, 7TH IBERO-AMERICAN CONFERENCE ON AI, 15THBRAZILIAN SYMPOSIUM ON AI (IBERAMIA/SBIA 2000), 7/15., 2000, Atibaia, SaoPaulo, Brazil. Proceedings... Sao Carlos: ICMC/USP, 2000. p. 47–56.
MINTON, S. et al. Minimizing conflicts: A heuristic repair method for constraintsatisfaction and scheduling problems. Artificial Intelligence, v. 58, n. 1-3, p. 161–205,1992.
MODI, P. J. et al. A dynamic distributed constraint satisfaction approach to resourceallocation. Lecture Notes in Computer Science, v. 2239, p. 685, 2001.
MODI WEIMIN SHEN, M. T. P. J.; YOKOO, M. An asynchronous complete methodfor distributed constraint optimization. In: INTERNATIONAL JOINT CONFERENCEON AUTONOMOUS AGENTS AND MULTI-AGENT SYSTEMS (AAMAS’2003), 2.,2003, Melbourne, Australia. Proceedings... [S.l.]: ACM Press, 2003.
PETCU, A.; FALTINGS, B. A value ordering heuristic for local search indistributed resource allocation. Lausanne (Switzerland), Feb 2004.
RAYNALL, M. Distributed algorithms and protocols. Great Britain: John Wiley,1992. ISBN 0-471-91754-0.
RUSSEL, S.; NORVIG, P. Artificial intelligence: a modern approach. 2. ed. NewJersey: Prentice Hall, 2003. ISBN 0-13-790395-2.
SILAGHI, M. C. Asynchronously solving problems with privacy requirements.271 p. Tese (Doutorado em Ciencias da Computacao) — Swiss Federal Institute ofTechnology (EPFL), 2002. Disponıvel em: <www.cs.fit.edu/˜msilaghi/teza>. Acessoem: 8 jul. 2004.
TSANG, E. Foundations of constraint satisfaction. London: Academic Press, 1993.ISBN 0-12-701610-4.
YOKOO, M. Distributed constraint satisfaction. Berlin: Springer, 2001.
YOKOO, M. et al. Distributed constraint satisfaction for formalizing distributed problemsolving. In: International Conference on Distributed Computing Systems. [S.l.:s.n.], 1992. p. 614–621.