1- introdução - dei.isep.ipp.ptdei.isep.ipp.pt/~asilva/apontamentos_aisc.pdf · revistas,...

Agentes Inteligentes e Sistemas Cooperativos

1- Introdução Nos últimos anos o termo agente tem-se vulgarizado, pensando-se que constituirá um paradigma da programação tão importante como o foram no passado a Programação Estruturada e a Programação Orientada para Objectos. Foi nesse sentido, e com vista a que os alunos do ramo de Computadores e Sistemas da Licenciatura em Engenharia Informática do Instituto Superior de Engenharia do Porto pudessem entrar em contacto com essa nova tecnologia, que se resolveu introduzir a disciplina de Agentes Inteligentes e Sistemas Cooperativos (AISC) como disciplina obrigatória do 1º semestre do 5º ano desse curso e ramo. Sendo um tema em grande evolução, o conhecimento encontra-se disperso por vários livros, revistas, “sites”, etc. O objectivo destes apontamentos é o de tentar concentrar, num documento único, os temas mais importantes que serão leccionados no âmbito da disciplina de AISC. Claro que nenhuns apontamentos poderão ser completos, não dispensando, certamente, a consulta de outra bibliografia. Mas constituirão uma peça importante no ensino que se pretende ministrar sobre esse novo conceito. Ao longo destes apontamentos pretendemos desmistificar conceitos como o de Agente ou de Sistema Multi-Agente, tentando transmitir toda a envolvente ao novo paradigma que agora se começa a introduzir. 1.1- A origem dos Agentes No início da década de 80 a comunidade científica da Inteligência Artificial organiza uma série de encontros nos quais aparece a proposta de um novo ramo de actuação: a Inteligência Artificial Distribuída. Esse novo ramo de actuação resultava da junção de duas áreas: a Inteligência Artificial e a Computação Distribuída. Até então a comunidade científica da Inteligência Artificial concentrava as capacidades inteligentes dos sistemas numa única entidade, o Sistema Inteligente. Segundo Davis, a Inteligência Artificial Distribuída tem como objectivo a resolução de problemas para as situações nas quais um único resolvedor de problemas, uma única máquina ou uma única localização computacional não parecem apropriadas [Davis-1980].

Instituto Superior de Engenharia do Porto – Carlos Ramos -1-


Nilsson indicava que a Inteligência Artificial Distribuída estava relacionada com o tipo de resolução de problemas para o qual a computação ou a inferência estão distribuídas logicamente ou fisicamente [Nilsson-1981]. A Inteligência Artificial Distribuída engloba duas áreas: a Resolução Distribuída de Problemas e os Sistemas Multi-Agente. Na Resolução Distribuída de Problemas considera-se que o trabalho que visa resolver um problema pode ser dividido num dado número de módulos ou nós, que cooperam entre si, dividindo e partilhando conhecimento acerca do problema e da solução em desenvolvimento. Nos Sistemas Multi-Agente a atenção centra-se no modo de coordenação dos comportamentos inteligentes de uma comunidade de agentes (pré-existentes ou não, autónomos ou semi-autónomos) de modo a partilhar conhecimento, objectivos, capacidades e planos para que se tomem acções ou se resolvam problemas. Os agentes devem raciocinar acerca dos processos de coordenação entre agentes. O termo “Agente” atinge o seu auge a partir da década de 90, com o “boom” da Internet e da World Wide Web, devido ao facto de terem aparecido todo um novo conjunto de aplicações nas quais o conceito de agente aparece como a resposta mais adequada em termos tecnológicos. 1.2- As várias “visões” sobre os Agentes Outras “comunidades” (que não a da Inteligência Artificial) adoptam o termo “Agente”. Por vezes essa utilização é abusiva, limitando-se em muitos casos a uma mera questão de marketing onde um programa perfeitamente convencional recebe a designação de Agente, não se percebendo qual a diferença entre essa entidade e um programa ou processo convencional dotado de capacidade de migração entre recursos computacionais. Por vezes a comunidade científica da Programação Orientada por Objectos tende a dizer que os agentes não são mais do que Objectos Distribuídos, procurando indicar que tecnologias como CORBA, DCOM ou RMI são perfeitamente suficientes. Vejamos o que dizem Jennings e Wooldridge sobre o assunto: Um objecto encapsula algum estado, e tem algum controlo sobre esse estado devido ao facto de só poder ser acedido ou modificado pelos métodos que o objecto disponibiliza. Os Agentes encapsulam estados do mesmo modo. Contudo, pensamos que os Agentes encapsulam comportamentos, para além dos estados. Um objecto não encapsula comportamentos – não tem controlo sobre a execução dos métodos – se um objecto x invocar um método m num objecto y, então y não tem controlo sobre se m é executado ou não. Nesse sentido o objecto y não é autónomo e não tem controlo sobre as suas acções. Em contraste, o Agente tem esse controlo sobre as acções que realiza. Dada essa distinção não pensamos nos Agentes como “invocando métodos (acções) sobre agentes”, pensamos nos agentes como requerendo acções a serem realizadas. A decisão de como agir reside em quem recebe o pedido.



As características dos agentes a enaltecer dependem da comunidade em questão. Por exemplo, para a comunidade dos Sistemas Distribuídos a Mobilidade é uma característica vital, a comunidade da Robótica realça o comportamento reactivo e a interacção com um mundo físico, para a comunidade da Inteligência Artificial características como o raciocínio, a aprendizagem e as capacidades sociais são fundamentais. Alguns autores e defensores da tecnologia dos Agentes advogam que o conceito de Programação Orientada para Agentes ou Programação Baseada em Agentes será o novo paradigma da programação no século XXI e será tão ou mais marcante como foram a Programação Estruturada e a Programação Orientada por Objectos no passado. 1.3- Definições de Agente Se efectuarmos uma pesquisa no dicionário, o termo agente poderá aparecer com um dos três seguintes significados:

1) algo que produz ou é capaz de produzir um efeito; 2) algo ao alguém que age por, ou em lugar de, outrém, por autorização deste último; 3) um meio ou instrumento através do qual uma entidade inteligente obtém um resultado.

As definições 2 e 3 parecem ser interessantes, nomeadamente porque indicam as capacidades de representação (definição 2) e de inteligência (definição 3). Vejamos agora como os agentes podem ser definidos de um ponto de vista informático: (MuBot Agent) – Um agente deve envolver dois conceitos ortogonais: execução autónoma e raciocínio orientado pelo domínio. (AI a Modern Approach) – um agente é algo que sente o ambiente onde existe através de sensores e actua através de actuadores [Russell-1995]. (Maes) – os Agentes habitam ambientes dinâmicos e complexos, sentem e agem autonomamente nesses ambientes e realizam um conjunto de objectivos ou tarefas para as quais foram concebidos [Maes-1995]. (KidSim Agent) – um agente é uma entidade de software persistente, dedicada a uma tarefa específica. O conceito de persistência distingue o Agente de uma subrotina, os agentes têm as suas próprias ideias de como cumprir as tarefas e têm as suas próprias Agendas. Os agentes são entidades de finalidade específica e não multifuncionais [Smith-1994]. (Hayes-Roth) – um agente inteligente realiza continuamente 3 funções: percepção das condições dinâmicas do ambiente; acções para afectar as condições do ambiente; raciocínio



para interpretar o resultado da percepção, resolver problemas, inferir e determinar as acções a realizar [Hayes-Roth-1995]. (IBM Agent) – Os agentes inteligentes são entidades de software que realizam um conjunto de operações por um utilizador ou programa, com algum grau de independência ou autonomia, empregando algum conhecimento e representação dos desejos ou objectivos do utilizador. (Wooldrige-Jennings) – os agentes são sistemas baseados em hardware ou software que têm as seguintes propriedades [Wooldridge-1995]: • autonomia (operar sem intervenção directa de humanos e controlar as suas próprias

acções); • capacidade social (interagir com outros agentes, ou humanos, através de uma ACL – agent

communication language); • reacção (os agentes têm percepção sobre o ambiente, físico ou não, e respondem

atempadamente às alterações que ocorrem); • pró-acção (também são capazes de exibir comportamentos guiados por objectivos, tomam

a iniciativa). (SodaBot Agent) – os agentes de software são programas que estabelecem dialogos, negoceiam e coordenam a transferência de informação. (Brustolini) – os agentes autónomos são sistemas capazes de realizar autonomamente acções com sentido num mundo real [Brustolini-1991]. (Franklin & Gasser) – um agente autónomo é um sistema que está contido e faz parte de um ambiente e actua sobre esse ambiente ao longo do tempo, possuindo a sua própria agenda [Franklin-1996]. (Coelho) – para sobreviver os agentes são forçados a possuir capacidades de tomada de decisão, estratégica e previsional, de coordenar as suas acções entre si e de enfrentar tarefas complicadas de forma efectiva [Coelho-1994]. (Minsky) – chamarei Sociedade da Mente a um esquema no qual cada mente é feita com muitos processos pequeninos, chamados Agentes, cada Agente só pode fazer coisas simples que não exijam qualquer mente ou pensamento, no entanto, quando juntarmos tais agentes em sociedades e de modos especiais tal conduzirá à verdadeira inteligência [Minsky-1986]. (Newell) – as principais atribuições de um agente são: comportar-se flexivelmente em função do ambiente; exibir comportamento adaptativo; operar em tempo-real; operar num ambiente rico e complexo; perceber uma imensa quantidade de detalhes em mudança; usar vastas quantidades de conhecimento; conter um sistema motor com vários graus de liberdade; usar símbolos e abstracções; usar uma língua natural; aprender a partir do ambiente; adquirir capacidades através do desenvolvimento; viver autonomamente dentro de uma comunidade artificial; estar atento ao que o rodeia e também sobre si próprio. Se tomarmos em conta estas definições começam a ficar claras algumas das características que devem estar associadas a um agente, como, por exemplo, a capacidade sensorial sobre o



ambiente envolvente, a capacidade de agir e reagir sobre o mesmo ambiente, a autonomia, as capacidades sociais de modo a permitir a interacção com outros agentes, etc. Algumas definições são mais focalizadas no Agente enquanto entidade individual, ou seja, no tal agente que representa algo ou alguém (por exemplo, um agente que efectuaria pesquisas ou compras na Internet em nosso lugar). Podemos dizer que esta abordagem está mais focalizada sobre o conceito de Agente Inteligente. Outras definições são mais orientadas para as capacidades sociais dos agentes, nessas definições o centro não está no agente, mas sim na comunidade de agentes, dando-se maior importância as capacidades inteligentes de argumentação, negociação, tratamento de conflitos, etc. Podemos dizer que esta abordagem está mais focalizada sobre o conceito de Sistema Multi-Agente.



2 – Classificação dos Agentes A classificação dos Agentes pode ser elaborada em função de um conjunto de características ou propriedades que estes podem possuir. É difícil encontrarmos um agente que possua todas as propriedades que se podem citar, embora algumas destas pareçam ser determinantes no estabelecimento do conceito de Agente. O quadro I enumera as principais propriedades ou características que se podem atribuir aos agentes. Quadro I – Características/Propriedades dos Agentes Propriedade

Significado

Capacidade Sensorial Dispõe de sensores para captar informação sobre o meio envolvente

Reactividade Sente e age, responde ao longo do tempo às mudanças no ambiente

Autonomia Decide e controla as suas próprias acções Pró-actividade Orienta-se por objectivos, não age apenas para responder

ao ambiente Persistência Existe ao longo do tempo Capaciadade social Comunica e coopera com outros agentes e talvez

com pessoas, concorre, compete Aprendizagem Muda o seu comportamento com base na

experiência anterior Mobilidade Capacidade de movimentar-se de uma máquina para outra Flexibilidade Não necessita que as suas tarefas estejam pré-determinadas Agilidade Capacidade de aproveitar rapidamente novas

oportunidades não previstas Carácter Personalidade credível e comportamento emocional Inteligência Capacidade de raciocínio autónomo, planeia o que faz,

corrige os erros e reage a situações não esperadas, adapta-se e aprende

De seguida iremos descrever mais em detalhe cada uma destas propriedades.



2.1 – Capacidades Sensoriais Os agentes devem ser dotados de capacidades sensoriais. No caso de um agente que opera sobre um meio físico real, controlando um robot ou uma sala, as entradas sensoriais são fornecida por sensores físicos (sensor de proximidade ou tacto para o caso do robot, sensor de temperatura, humidade ou fumo para o caso de uma sala). Os sensores poderão ser meros sensores do tipo on/off ou permitirem a distinção em mais níveis digitais ou até serem analógicos. Desse modo os agentes podem “sentir” o ambiente que os rodeia, o qual poderá ser estruturado (já conhecido) ou não (por exemplo, um robot de exploração espacial que efectue o reconhecimento do terreno em outro planeta). Contudo, o conceito de capacidades sensoriais pode ser estendido para o caso dos agentes que não controlem dispositivos físicos externos a um sistema computacional, os quais são geralmente conhecidos como Agentes de Software. Um agente pode controlar a ocupação do disco de um computador ou procurar detectar um vírus. Podemos considerar tais capacidades como capacidades sensoriais, como se tivessemos um sensor virtual para o efeito. 2.2 – Agentes Reactivos e Agentes Deliberativos Os Sistemas Reactivos são originários da Robótica, onde Brooks introduz uma arquitectura reactiva a vários níveis. Anteriormente os robots “inteligentes” seguiam o ciclo “Sentir → Planear → Agir”, onde todas as acções eram planeadas, o que levava a que os tempos de resposta fossem elevados para certas situações. Brooks propõe o conceito de comportamento reactivo, segundo o qual o sistema reage a estímulos apresentando certos comportamentos reactivos, os quais não resultam de um planeamento aprofundado. Pode-se dizer que os comportamentos reactivos permitem simular os reflexos que o ser humano dispõe. Não é necessário replanear o trajecto que iremos fazer de casa para o trabalho por carro apenas porque o carro da frente travou ou um carro que vinha da esquerda entrou à nossa frente sem prioridade, apenas temos que travar ou guinar o carro ligeiramente para à direita para evitar o embate. A arquitectura de Brooks propõe que Sentir/Planear/Agir não seja um ciclo que se repete, mas sim tarefas que decorrem em paralelo. Enquanto travamos para evitar o embate com o carro da frente podemos em paralelo estar a planear outro trajecto para evitar o “engarrafamento” que originou a paragem do carro que está à frente e inspeccionar visualmente a situação de uma rua alternativa. Em ambientes físicos (robótica móvel) ou não (realidade virtual, software “puro”), com grande dinamismo, onde a realidade está em constante mutação, é desejável que os Agentes exibam comportamentos reactivos de modo a responder mais rapidamente às mudanças.



Contudo, as reacções nem sempre são as mais adequadas (por exemplo, largar um tacho com água a ferver porque as asas estão quentes ou travar um carro que começou a despistar-se no gelo), pelo que a completa inibição do raciocínio mais aprofundado pode trazer problemas. Geralmente, são identificáveis três alternativas para a Reacção: 1) Sistemas puramente reactivos: onde não há planeamento, apenas existem os comportamentos reactivos; 2) Sistemas reactivos monitorados e controlados pelo planeamento: onde o sistema de planeamento pode ter prioridade sobre o sistema de reacção no controlo dos actuadores em caso de conflito, numa situação futura idêntica esse conflito voltará a aparecer; 3) Sistemas Reactivos modificáveis: o sistema de planeamento pode alterar ou introduzir novos comportamentos reactivos, estes sistemas podem exibir algumas capacidades de adaptação e aprendizagem. O Planeamento considerando a reacção é designado Planeamento Reactivo, tendo também a designação de Planeamento Táctico. Está geralmente associado ao conceito de Planeamento On-Line, ou seja, planear durante a execução. O contrário do Planeamento Reactivo é o Planeamento puro feito à priori e não considerando possíveis alterações durante a execução. Recebe o nome de Planeamento Estratégico ou Planeamento Deliberativo. É feito em off-line. O contrário de um Agente Reactivo é um Agente Deliberativo. Os Agentes Deliberativos mantêm uma representação interna do mundo que os rodeia, através de um estado mental explícito que pode ser modificado através de raciocínio simbólico. Um agente hipotético puramente deliberativo não alteraria em nada um plano previamente traçado devido ao facto do meio envolvente se ter modificado. Contudo, na prática, os agentes não são 100% puramente reactivos nem 100% puramente deliberativos. 2.3 – Agentes Autónomos e Semi-Autónomos Quando dizemos que um Agente age por conta de outrém, estamos a admitir um grande grau de autonomia ao agente. Pode-se até dizer que a Autonomia é a característica marcante e plenamente aceite dos Agentes, embora não seja suficiente, por si, para a sua definição. Vamos relembrar a definição de Franklin e Gasser: (Franklin & Gasser) – um Agente Autónomo é um sistema que está contido e faz parte de um ambiente e actua sobre esse ambiente ao longo do tempo, possuindo a sua própria agenda.



Um Agente puramente autónomo é um agente que não necessita de outros que garantam a sua existência ou persistência. Não quer isso dizer que o Agente é capaz de fazer tudo, significa que o agente não bloqueia ou não pára apenas porque outros (agentes ou ser humano) não foram capazes de cumprir uma dada tarefa. A autonomia é fundamental em situações onde seja dificultada a intervenção “on-line” do ser humano (por exemplo, robots para exploração espacial ou naves espaciais). A autonomia pode ser fundamental em situações críticas em que se verifique o “bloqueio” dos seres humanos dada a natureza da situação (por ex. acidentes em centrais nucleares onde os operadores podem tomar decisões incorrectas que nunca tomariam noutra situação). Contudo, também se admite a existência de Agentes semi-autónomos, ou seja, de agentes que dependem de outros ou do ser humano. Um Agente semi-autónomo não faz sentido individualmente pois depende de outros, que cumprem geralmente funções diferenciadas ou que validam decisões do agente. A figura 1 dá-nos uma idéia de uma possível classificação dos Agentes Autónomos.

Agentes Autónomos

Agentes com/simulandovida Robots Agentes de Software

AgentesBiológicos

Agentes comVida Artificial

Humanos

Vírus Biológico

Cão

Vírus Computacional

Programa com VidaArtificial

AgentesEspecíficos

AgentesGenéricos

Agente Broker

Assistente Pessoal

Centro de Chamadas

Gestor de Tarefas

Mediador

Assistente de Compras

Agente de Diagnóstico

Agente de Explicação

Agente de Projecto

Agentes colaborativos

Agentes de Interface

Agentes Móveis

Agentes Informativos

Agentes Reactivos

Agentes Híbridos

Agentes Inteligentes

Fig. 1 – Classificação de Agentes Autónomos [Franklin-1996]



2.4 – Agentes Pró-Activos Um Agente Pró-Activo não reage apenas ao ambiente, tem uma visão própria, tem objectivos, é um agente interveniente capaz de alterar o rumo do ambiente no qual opera. Um Agente que se dedique apenas à pesquisa de informação na Internet ou na Web a pedido de alguém não é pró-activo pois não modifica o ambiente com o qual interage. Se, no entanto, esse agente for capaz de construir as suas próprias páginas, tentar convencer os gestores de outros “sites” que a informação que exibem está incorrecta ou incompleta então podemos dizer estarmos na presença de um Agente Pró-Activo. 2.5 – Agentes Persistentes e não persistentes Agentes Persistentes são Agentes que existem ao longo do tempo. Um processo computacional tem um nascimento (criação do processo), pode passar por vários estados intermédios durante a sua existência (em execução, suspenso, bloqueado à espera de algo, etc) até deixar de fazer sentido e desaparecer (morte ou fim do processo). Com grande parte dos Agentes passa-se o mesmo, ou seja, o Agente tem um ciclo de vida relativamente curto no qual pode fazer sentido, quando deixa de ter interesse é removido. Um Agente persistente tem uma duração muito mais ampla, em princípio deve existir sempre ao longo do tempo. Vejamos alguns exemplos:

1) Num sistema industrial de produção um agente que represente uma encomenda ou ordem de fabrico não é persistente. Nesse mesmo sistema um agente que represente uma máquina ou linha de fabrico é persistente; 2) Um Agente que efectue o processamento dos alarmes que chegam a um Centro de Controlo é um Agente persistente. Um Agente que planeie a recuperação ou reposição do sistema controlado por esse mesmo centro quando da ocorrência de uma falha grave não necessita ser persistente; 3) Um Agente de Comércio Electrónico que represente um dado vendedor deverá ser persistente. Um Agente de Comércio Electrónico que represente um comprador ocasional não é persistente.



2.6 – Agentes com capacidade social Geralmente, um Agente não existe isoladamente. É comum ter que interagir com outros Agentes idênticos ou diferentes. Tal como referimos sociedades de indivíduos também podemos referir sociedades ou comunidades de Agentes. Um exemplo é o conceito de Sistema Multi-Agente ou o conceito de Sistema Holónico. Os agentes necessitam de obter informação e conhecimento e para tal necessitam de comunicar entre si. Várias alternativas tecnológicas são possíveis para a comunicação: comunicação dirigida para um (peer-to-peer), comunicação para todos (broadcast), comunicação por zona de acesso comum (blackboard). As tecnologias poderão ser várias (sockets, memória partilhada, etc). Os Agentes devem definir uma linguagem através da qual se possam compreender. Os Agentes deverão ter vocabulários e taxonomias que permitam um diálogo consistente (ontologias). Também tornam-se necessários formatos de troca de conhecimento (KIF – Knowledge Interchange Format) e linguagens de interrogação do conhecimento (KQML – Knowledge Query Manipulation Language) de modo a definir linguagens de comunicação entre agentes (ACL – Agents Communication Language). Um conceito acima da comunicação é o conceito da cooperação, segundo o qual os agentes cooperam entre si com a finalidade de atingirem os seus objectivos ou obterem algum benefício. A cooperação implica comunicação. Um Agente cooperante necessita saber o que é capaz de fazer e ter ideia de quem é capaz de fazer uma dada tarefa (tal poderá estar pré-armazenado no agente ou ser obtido como resposta a um anúncio). A partilha é um aspecto determinante para os agentes cooperantes. Esta divide-se na partilha de tarefas e na partilha de resultados (informação e conhecimento). Os Agentes podem ser competidores entre si (por exemplo, empresas a vender produtos idênticos em Comércio Electrónico). Neste caso os agentes devem ser dotados de características mais desenvolvidas na observação do ambiente em que actuam, bem como devem ser capazes de “vigiar” com maior atenção os seus concorrentes. Os Agentes com capacidade social devem ser capazes de negociar entre si. A negociação baseia-se em anúncios, propostas, ofertas e decisões e pode englobar muitas restrições (custo, tempo, qualidade, etc), condições e penalizações. A negociação entre Agentes foi identificada nos primórdios da Inteligência Artificial Distribuída, cite-se, por exemplo, o Contract Net Protocol [Davis-1983]. Em comunidades de agentes é comum a ocorrência de conflitos. Alguns exemplos:



• Conflitos de Objectivos – os agentes não têm objectivos idênticos, podendo até ser contraditórios;

• Conflitos de Responsabilidade – há vários agentes que querem assumir a responsabilidade por uma dada tarefa ou cumprir um mesmo objectivo;

• Conflitos de Informação e Conhecimento – vários agentes têm leituras diferentes para uma dada situação ou realidade.

As comunidades de agentes cooperantes podem ser divididas em comunidades de agentes fortemente acoplados (tight coupled systems) e comunidades de agentes fracamente acoplados (loosed coupled systems). No primeiro caso os agentes são muito dependentes dos outros, se um falhar haverá uma grande hipótese do sistema multi-agente também falhar. No segundo caso os agentes detêm maior autonomia, se um agente falhar o sistema no seu todo deverá apresentar uma resposta, embora de pior qualidade. A Sociabilidade, ou capacidade do agente operar com outros agentes que constituem uma sociedade, estabelece a diferença entre um sistema de software inteligente e um sistema de agentes inteligentes. 2.7 – Agentes com Aprendizagem A aprendizagem é uma das características que a comunidade da Inteligência Artificial mais gosta de realçar nos Agentes. Assim como somos capazes de aprender ao longo do tempo à medida que vamos interagindo com o ambiente que nos rodeia e com outros seres e à medida que vamos acedendo a mais informação e conhecimento, também os Agentes deverão ser capazes de serem evolutivos, ou seja, capazes de condicionar o seu funcionamento em função da sua experiência anterior. Para além das capacidades de aprendizagem inerentes aos Sistemas Inteligentes, onde a atenção vai para a aprendizagem sobre o domínio (por exemplo, aprender a classificar um cliente que pede um empréstimo ou aprender a prever o consumo de água numa dada altura), os Agentes envolvem uma necessidade de aprendizagem nos níveis mais elevados como, por exemplo, aprender que um dado tipo de agente é pouco fiável no que respeita ao cumprimento de prazos de entrega de tarefas previamente contratadas. Imagine-se um Agente que perante uma dada situação toma uma decisão que acaba por ser incorrecta. Sendo consciente o agente apercebe-se que a decisão não foi a mais acertada. Se numa próxima ocasião a mesma situação se repetir e o Agente tomar a mesma decisão será pouco credível que se possa taxar tal agente como sendo verdadeiramente inteligente, pois não foi capaz de aprender. Algumas abordagens à aprendizagem automática são:

• Aprendizagem baseada em casos; • Aprendizagem baseadas na observação;



• Aprendizagem com recurso à explicação; • Classificação Simbólica; • Redes Neuronais.

2.8 – Agentes Móveis A comunidade científica mais relacionada com os Sistemas Distribuídos e com as Comunicações e Redes de Computadores realça a Mobilidade como uma característica fundamental dos Agentes. Note-se que a mobilidade é uma característica apontada para os Agentes de Software e não tem a ver com a mobilidade física (por exemplo, de um robot móvel). A mobilidade é a capacidade que o agente de software tem de se deslocar de uma localização computacional para outra. Não se deve confundir com o conceito de portabilidade do software. Com a mobilidade pretende-se que um Agente possa, num dado momento, abandonar o ambiente computacional sobre o qual operava para ir para outro ambiente computacional distinto. A computação baseada em Agentes Móveis tem sido proposta para a nova geração dos sistemas computacionais. Os Agentes Móveis são definidos como programas que podem migrar de uma máquina para outra num ambiente heterogéneo. O Agente escolhe quando e para onde migrar. Ele pode suspender a sua execução numa máquina num ponto arbitrário, passar para outra máquina e reactivar-se nessa máquina a partir do ponto em que foi suspenso. À medida que os agentes se movem através de uma rede eles consomem recursos. A questão que se põe é a de como evitar que tais agentes sobreutilizem ou desperdicem tais recursos. Um agente móvel realista deve ser capaz de ser efectivo num ambiente distribuído e heterogéneo. Durante a sua existência um agente pode visitar diferentes tipos de máquinas e sistemas operativos, que são usados por organizações como políticas e objectivos diferentes. Os agentes móveis devem estar preparados para lidar com tais situações. Um exemplo de um agente desse tipo é o agente que auxilia na gestão do parque informático de uma organização e que substitui a necessidade do gestor desse mesmo parque ter que “entrar” nas várias máquinas existentes ou lançar “deamons” em todas as máquinas. Um motor de pesquisa na Internet/web não é móvel na medida em que não abandona a máquina onde está, embora vá pesquisar informação em muitas máquinas. Um vírus tem qualidades de mobilidade, na medida em que é capaz de se alojar em diversas máquinas. Linguagens como o Java vieram realçar a importância da mobilidade nos Agentes.



Os utilizadores móveis põem um novo problema para as aplicações diferente dos problemas postos para utilizadores com agentes fixos. Os utilizadores móveis caracterizam-se pelo custo e fiabilidade das ligações que utilizam. A tecnologia dos Agentes Móveis pode ser usada para lidar com o problema dos utilizadores móveis. A computação móvel, tal como o nome sugere, é a área que lida com os aspectos móveis da computação. A mobilidade pode ser classificada segundo um dos seguintes tipos:

• apenas os utilizadores são móveis, os computadores são estáticos; • embora os computadores e os utilizadores sejam móveis, eles são estacionários no

âmbito de uma sessão de trabalho; • os utilizadores são móveis numa sessão de trabalho, levantando problemas como o

encaminhamento de mensagens e a gestão das conexões. As plataformas com agentes móveis põem maiores problemas no que se refere à tolerância a falhas. A mobilidade põe questões relacionadas com a prioridade de acessos e a segurança. Os Agentes Móveis podem ser vulneráveis no que se refere a ataques de sistemas hostis. Tais situações podem estar contidas num dos seguintes tipos:

• escutas para obter informação confidencial (com ou sem chaves de acesso); • falsa identificação; • clones de Agentes Móveis; • duplicação de transacções; • fraudes; • utilização indevida de informação dos utilizadores.

Alguns dos primeiros sistemas de agentes móveis foram o AgentTCL [Gray-1995], Concordia [Mitsubishi-1997] e Odyssey [Odyssey]. 2.9 – Agentes Flexíveis e Ágeis A Flexibilidade é a característica de um Agente comutar facilmente as tarefas que executa. Por exemplo, num Sistema Industrial de Produção após a chegada de uma nova encomenda de um produto conhecido pode ser dada prioridade à ordem de fabrico correspondente, mesmo que isso implique reescalonar outras ordens de fabrico. Um Agente que fizesse isso facilmente seria classificado como sendo Flexível. A agilidade é uma característica diferente e tem a ver com a capacidade que o Agente tem em responder rapidamente a uma nova solicitação ou oportunidade que apareça, mesmo que tal implique um trabalho que não estava previsto anteriormente.



Um exemplo típico de agilidade é o conceito de Empresa Virtual onde várias empresas se agregam para tirar partido de um nicho de mercado emergente que pretende um produto diferenciado. 2.10 – Agentes com Carácter ou Personalidade Os Agentes destinam-se, muitas vezes, a substituir o ser humano em determinadas tarefas. Será então oportuno questionar se a um Agente podemos atribuir um carácter, personalidade ou comportamento emotivo, tal como o fazemos para o ser humano? Se criarmos um agente para comprar em Comércio Electrónico podemos dotá-lo de pequenas partículas de carácter. O Agente pode, por exemplo:

• não comprar produtos oriundos de determinados países; • não comprar produtos de empresas que financiem uma dada organização desportiva,

política, etc…; • não estabelecer negócios com empresas cuja publicidade tenha determinadas

características; • não comprar produtos de empresas que não sejam “amigas” do ambiente.

Nos Agentes que se destinam a interagir com o ser humano é dada grande importância à interface. Por um lado tem sido feito algum esforço no desenvolvimento de personalidades computacionais antropomórficas que parecem exibir um comportamento emotivo, por exemplo, mudando de expressão quando falamos de algo que as agrada ou de algo que as repugna. Por outro lado, tem sido feito um esforço de identificação do estado emotivo do utilizador. Esse tipo de agentes, capazes de exibir ou reconhecer comportamentos emotivos, necessitam de tecnologias como o reconhecimento de voz, língua natural, visão por computador, computação gráfica, etc. As questões que se põe na introdução de agentes antropomórficos vão para além de questões tecnológicas. Que impacto terá um agente de interface com aspecto similar a uma face humana e que pareça exibir alguma personalidade e até sentimentos? A introdução de tal agente aumentará o conforto e satisfação relativamente à interacção? Tal agente poderá ser mais persuasivo? Mas os agentes de interface com aspectos antropomórficos são ainda raros, mais comuns no âmbito de projectos de investigação. Alguns investigadores sustentam que as tecnologias como o reconhecimento de voz, compreensão de língua natural ou aprendizagem automática ainda não atingiram a maturidade suficiente para que se atinja o sucesso pretendido com tais agentes de interface. Adicionalmente, alguns críticos sustentam que os agentes antropomórficos podem confundir os projectistas e utilizadores, criar ansiedade no utilizador, reduzir as capacidades de controlo do utilizador, contribuir para um menor sentido de responsabilização, diminuir o sentido de cumprimento do utilizador.



Mas este é um campo em grande desenvolvimento. Há quem defenda que as personalidades antropomórficas dos agentes podem ser vantajosas. Por exemplo, Walker estudou o modo como os utilizadores respondiam a questionários on-line convencionais e questionários envolvendo interfaces antropomórficas [Walker-1994]. Concluiu que as interfaces antropomórficas levavam a que os utilizadores dedicassem mais atenção aos questionários, cometessem menos erros e dessem mais sugestões. Nos últimos anos tem havido um grande debate sobre a Emocionalidade versus a Inteligência. Por exemplo, um ser com QI mais elevado ou com maior habilidade pode ser mais instável emocionalmente que outro menos inteligente ou menos hábil. Em situações críticas o comportamento emocional do ser humano é determinante (por exemplo, o piloto de um avião com problemas ou o operador que controla uma central nuclear numa situação complexa). O software é muitas vezes insensível a tais situações, o que pode ser bom ou mau. Há que ter algum cuidado com a passagem de comportamentos emotivos para os agentes. 2.11 – Agentes Inteligentes A inteligência é uma característica dos agentes que pode ser definida em função de outras características. Vamos ilustrar isso com as definições de Hayes-Roth e da IBM: (Hayes-Roth) – um agente inteligente realiza continuamente 3 funções: percepção das condições dinâmicas do ambiente; acções para afectar as condições do ambiente; raciocínio para interpretar o resultado da percepção, resolver problemas, inferir e determinar as acções a realizar (IBM Agent) – Os agentes inteligentes são entidades de software que realizam um conjunto de operações por um utilizador ou programa, com algum grau de independência ou autonomia, empregando algum conhecimento e representação dos desejos ou objectivos do utilizador Quase que poderíamos relembrar o Teste de Turing que pretenderia verificar se um sistema era inteligente ou não, procurando adaptar a terminologia à realidade actual. Quando não formos capazes de distinguir se algo provém de um ser humano ou não então teremos chegado à noção de Agente Inteligente. A definição da IBM refere o termo conhecimento, muito importante nos Sistemas Baseados em Conhecimento (por exemplo, Sistemas Periciais) há algumas décadas e na Gestão do Conhecimento na actualidade. De facto quanto mais conhecimento formos capazes de passar para o Agente maior será a possibilidade de chegarmos a algo similar a um Agente verdadeiramente inteligente. Uma clara diferença face aos Sistemas Inteligentes reside no facto de ao Agente Inteligente não bastar ser inteligente no domínio para que é destinado. O Agente Inteligente necessita de incorporar conhecimento sobre o modo através do qual deve interagir numa comunidade de agentes ou com seres humanos, em quais agentes ou pessoas deve confiar ou duvidar, como



deve negociar com agentes ou seres com culturas diferentes, como lidar com os conflitos, como conviver e partilhar os seus conhecimentos, etc. Na figura 2 procura-se indicar as características de Cooperação, Aprendizagem e Autonomia como as principais características de um Agente Inteligente.

Cooperação

Autonomia Aprendizagem

Agente Inteligente

Agente Colaborativo Agente Colaborativocom aprendizagem

Agente de Interface

Fig. 2 – Uma visão possível dos Agentes Inteligentes [Nwana-1996] Vários trabalhos têm-se centrado na análise da inteligência humana e na inteligência dos agentes. Como um ser humano avalia a inteligência de outro ser ou agente? Por exemplo, se questionarmos duas pessoas, ou dois agentes, com um conjunto de perguntas, mesmo que no final o número de respostas certas seja o mesmo, haverá a tendência para considerar o que acerta mais respostas a princípio como mais inteligente ou mais competente. De igual modo, confiaremos mais nas repostas de um ser humano ou agente que seja rotulado como perito. O nível de crítica a uma solução pode também interferir na nossa avaliação, temos a tendência a pensar que os analistas mais críticos são mais competentes. Todas as reflexões sobre o modo subjectivo através do qual, numa interacção com outro ser humano, julgamos a inteligência de alguém podem também ser feitas relativamente à inteligência dos agentes.



Os mesmos receios que existiram no passado relativamente aos robots e à Inteligência Artificial aparecem replicados agora relativamente aos Agentes. Quando se referem agentes inteligentes que podem emitir opiniões e pareceres ou decidir sobre compra e venda de produtos ou acções, torna-se claro que a automatização das tarefas humanas por parte da Informática vai na direcção das tarefas mais repetitivas e enfadonhas para as tarefas de maior valor, atingido tarefas que operam sobre o conhecimento.



3 – Breves exemplos de Agentes e Sistemas Multi-Agente Nesta secção vamos dar alguns breves exemplos de Agentes e Sistemas Multi-Agente de modo a que o leitor possa identificar melhor e mais em concreto os conceitos e características que têm sido definidas. Iremos abordar possibilidades de aplicação dos Agentes ao Comércio Electrónico, Robótica, Sistemas Produtivos e Controlo de Tráfego. 3.1 – Comércio Electrónico Os Agentes são entidades de software às quais foram dadas autonomia e inteligência suficientes para possibilitar a execução de tarefas específicas com pouca ou nenhuma supervisão humana. Um agente interage com um ambiente em contínua mutação, ao mesmo tempo que deve representar os interesses de alguém que é suposto representar. A convergência da computação e das telecomunicações tem levado a que o comércio passe a decorrer de um modo bastante diferente ao que tinhamos há apenas alguns anos atrás, sobretudo depois da generalização da Internet e WWW. O crescimento da Internet ultrapassou as previsões mais optimistas. De 17 milhões de utilizadores em 1992 o número cresceu para 195 milhões em 1999, 47 milhões apenas na Europa. Uma grande parte dos utilizadores da Internet já experimentaram comprar algo na Internet. Por exemplo, cerca de 40% dos utilizadores britânicos já encomendaram algo na Internet, 10% até se consideram consumidores frequentes de comércio electrónico. Em 1999 considerava-se que tinhamos 5,2 milhões de consumidores europeus usando a Internet para comprar produtos, a que correspondeu um valor de € 3032 milhões. Em 2002 estima-se que teremos 28,8 milhões de consumidores europeus usando a Internet para comprar produtos para um valor estimado de € 57210 milhões. Note-se que estes valores se referem apenas às compras directas de utilizadores da Internet, a parte mais significativa que é constituída pelo negócio entre empresas (B2B) não é contemplada nestes números. Embora não haja valores completamente certos e reconhecidos, estima-se que em 1999 o comércio electrónico no seu todo representou qualquer coisa como 95 mil milhões de dólares americanos e que em 2003 esse valor será multiplicado por 100 ou 200. Têm sido desenvolvidas várias ferramentas para facilitar a criação de negócios on-line, como o Merchant da Microsoft, o Net Commerce da IBM e o Dynamo da ATG. A introdução de agentes no Comércio Electrónico faz todo o sentido, na medida em que os Agentes podem automatizar uma série de funções (visitar “sites”, obter informação na Internet, etc) de um modo muito mais rápido e automático que qualquer ser humano. Isso é particularmente importante em mercados nos quais o preço dos produtos esteja em constante mutação (matérias primas, Bolsas de Valores, etc).



A questão da segurança põe-se para os Agentes de um modo diferente das aplicações convencionais de Comércio Electrónico. Nestas últimas o que se procura é garantir a segurança de uma transação (normas SET ou SSL). Claro que os agentes também devem permitir esse tipo de protecções. Mas quando referimos agentes que substituam pessoas ou organizações a questão de segurança que se põe é a de saber que “estragos” os agentes poderão fazer (serão demasiadamente gastadores, comprarão produtos supérfluos, comprarão produtos cuja comercialização é punida por lei, não terão cuidados em verificar se do outro lado estão vendedores com crédito no mercado, etc). Portanto, ao nível dos Agentes, a segurança põe-se de uma maneira diferente e a preocupação não é a da segurança das transações, que deve ser garantida a níveis diferentes, mas sim a confiança que temos no Agente (daremos o nosso número de cartão de crédito a um agente?). No Comércio Electrónico podemos estar a referir níveis bem diferentes como o de compras individuais ou de transacções entre empresas (B2B – Business to Business). No caso das compras individuais a dificuldade que se põe é a personalização do agente. Nas compras individuais é normal que o cliente, através de um computador ligado à Internet, efectue algumas pesquisas, com recurso a browsers, identificando produtos, comparando-os e efectuando as escolhas. Aqui temos que distinguir produtos claramente iguais (por exemplo, um livro, CD, etc) de produtos diferenciados (por exemplo, peças de roupa). No primeiro caso a introdução de Agentes é muito mais simplificada, um “script” do utilizador para o Agente poderia ser o seguinte:

Procure todos os sites que vendem o produto X Identifique aquele cujo custo do produto acrescido de portes de envio é mais barato Efectue a encomenda se o preço for inferior a PrX.

Claro que o utilizador poderá complicar mais a encomenda, considerando aspectos como o prazo de entrega, a confiança que tem no fornecedor, a possibilidade de benefícios (por exemplo, juntar mais pontos num dado cartão), as facilidades de pagamento, etc. O problema pode ainda ser tornado mais complexo se pretendermos encomendar um conjunto de produtos (podendo nem todos estar disponíveis em todos os fornecedores). Nesse caso o Agente terá de ser dotado de um maior nível de inteligência para proceder à escolha. No caso do Comércio Electrónico de compras individuais com produtos diferenciados a utilização de Agentes para tomada automática de decisões é muito mais complexa. A dificuldade reside no facto de nenhum consumidor pretender comprar um produto que não sabe bem o que é. Não seria de se imaginar que alguém desse uma ordem do tipo “comprar um par de sapatos castanhos nº 38”. Nesse caso os Agentes devem ser vistos apenas como entidades que procuram produtos que se encaixem na descrição dada pelo utilizador. De qualquer modo, aqui os agentes são entidades individuais, embora, possam estar a negociar com agentes vendedores do outro lado. Também podemos centrar o Comércio Electrónico no lado dos vendedores. Aqui os agentes deverão ter responsabilidades de divulgar adequadamente os seus produtos e garantir a



segurança das transacções. Um Agente evoluído poderá, ainda, efectuar tarefas mais evoluídas, como analisar as transacções efectuadas e “espionar” os concorrentes, podendo, por exemplo, concluir que as vendas de um determinado produto baixaram porque um concorrente introduziu no mercado um produto alterenativo ou reduziu o preço do produto correspondente. Desse modo serão possíveis reacções mais rápidas, que acarretarão menores perdas ou maiores ganhos. Outra tarefa que os agentes vendedores poderão fazer será a modelização do cliente através da identificação de um perfil. Por exemplo, se for sabido que quem compra o produto P1 e o produto P2 pertence geralmente a um determinado perfil que costuma comprar P3 então se alguém comprar P1 e P2 poderá ser questionado se pretende comprar P3. O uso de técnicas de Data Mining é adequado para tirar conclusões desse tipo, permitindo um melhor conhecimento do negócio e do perfil dos consumidores, o que poderá potenciar acções do tipo “marketing dirigido”. Note-se que ao convertermos uma loja real numa loja virtual perdemos a sensibilidade que os vendedores detinham no ramo em causa, as técnicas de Data Mining podem ajudar a recuperar alguma dessa sensibilidade de um modo automático, operando sobre as transacções prévias que foram efectuadas. Note-se que os agentes compradores devem saber como encontrar os vendedores dos produtos desejados e o modo como devem efectuar a encomenda. Isso pode ser feito armazenando uma lista de “sites” e de procedimentos de encomenda no Agente. Contudo, se for desejável um agente que procure novos “sites” vendedores estes últimos deverão ser munidos com uma linguagem que facilite a leitura automática dos conteúdos (por exemplo, usando XML). No caso do Comércio Electrónico entre empresas, os produtos a comprar têm características bem definidas. Cite-se o exemplo da Indústria Automóvel, onde o fabricante de viaturas compra componentes (por exemplo, pneus, cablagens, etc) e matéria prima (por exemplo, cola, chapa) a fornecedores. A cadeia de fornecimento pode estender-se, por exemplo, quem fabrica cablagens precisa comprar fio eléctrico e quem fabrica fio eléctrico precisa comprar cobre e PVC. Podemos então falar num Sistema Multi-Agente. Neste caso, os agentes compradores têm muito mais cuidado com os potenciais vendedores (fornecedores) do que no caso do comércio electrónico individual. Note-se que factores como a qualidade dos componentes a comprar e o cumprimento dos prazos de entrega são vitais. Por exemplo, se a empresa seleccionada para fornecer cablagens eléctricas atrasar as suas entregas então o fabricante dos carros também poderá ter que atrasar as entregas destes, se não tiver stock de cobertura conveniente. Desse modo, no comércio electrónico entre empresas há um cuidado muito grande na escolha dos parceiros fornecedores, em termos práticos, os Agentes já sabem com quem devem negociar, poderão é ter mais do que um fornecedor para os produtos, procurando reduzir preços e aumentar as garantias de entrega. Os agentes deverão ser dotados de inteligência suficiente para poderem fazer bons negócios (por exemplo, no que se refere à dimensão do lote a comprar), podendo ainda ser dotados de características de argumentação (por exemplo, para escalonar as entregas de modo a reduzir custos de armazenamento). Esses mesmos agentes poderão ter de monitorizar níveis de segurança e cobertura no stock de componentes e matéria prima. Um outro tipo de agentes que tem lugar no âmbito do Comércio Electrónico corresponde aos Agentes Intermediários que tentam estabelecer um compromisso entre potenciais compradores



e vendedores. Os agentes compradores e vendedores poderão ser dotados de capacidade de negociação do preço, prazos de entrega, prazos de pagamentos, etc. A negociação poderá não envolver agentes intermediários e ser directa, no caso de existirem intermediários, estes deverão ser da confiança de ambos os lados (compradores e vendedores). 3.2 – Robótica Vamos ilustrar o uso de Agentes em Robótica com alguns exemplos. O primeiro exemplo coresponde a um robot que identifica componentes individuais através de um sistema de Visão por Computador e sensores e efectua tarefas de manipulação e montagem. Poderemos ter agentes com funcionalidades diferentes, tais como o reconhecedor de componentes, o planeador das trajectórias para evitar colisões, o planeador das montagens e o controlador da execução. Poderemos, ainda, ter mais do que um robot a executar as tarefas, o que torna as necessidades de cooperação mais evidentes (por exemplo, para evitar que dois robots se choquem entre si), mas permitindo desempenhos adicionais, por exemplo, a cooperação e coordenação de dois robots no transporte de uma peça que cada um não conseguiria transportar sozinho. O segundo exemplo que iremos citar corresponde a uma comunidade de robots que esteja a efectuar o reconhecimento de uma zona geográfica nova (o solo num outro planeta, o fundo marítmo, etc). Cada robot deve ser dotado de autonomia e inteligência, podendo por exemplo, decidir para onde ir e como evitar colisões com obstáculos detectados pelos seus sensores, logo, tais robots aproximam-se do conceito de agente. Estes agentes podem comunicar entre si directamente, partilhando os seus dados/informações e conhecimentos, por exemplo, um robot informa os outros que numa dada posição encontra-se um obstáculo com determinadas dimensões. Note-se, que ao contrário dos agentes citados para o exemplo anterior aqui os agentes são funcionalmente idênticos. Note-se que nesse caso as possibilidades de conflitos podem ser superiores (por exemplo, outro robot responde ao que informara sobre o obstáculo indicando que já passara por aquela posição e que não tinha identificado nenhum obstáculo). Para finalizar vamos considerar um exemplo muito em voga que corresponde ao Futebol Robótico (RobotSoccer). Podemos imaginar uma equipa de robots, cada qual correspondendo a um agente, dotado de sensores e actuadores. Uma câmara recolhe uma imagem de topo, a qual é fornecida para outro agente (o treinador) que irá comunicando com os agentes jogadores instruções que permitam corrigir aspectos anteriormente delineados. Apesar dos agentes serem similares eles poderão desempenhar funções diferentes (guarda-redes, defesa, atacante). Estes agentes podem ser dotados de comportamentos reactivos (por exemplo, o que deve fazer o guarda-redes quando um avançado adversário aparece com a bola pelo seu lado esquerdo). Aqui, podemos esbelecer claramente as diferenças entre planeamento estratégico e planeamento táctico. Adicionalmente, os agentes não podem todos ser vistos como cooperantes, há os agentes da equipa adversária que são opositores.



3.3 – Sistemas Produtivos Os sistemas de produção caracterizam-se por um elevado grau de complexidade sendo naturalmente distribuídos do ponto de vista físico (várias máquinas, linhas de fabrico, fábricas, etc) e lógico (vários produtos, encomendas e ordens de fabrico a serem tratadas simultaneamente). Aqui é costume encontrarmos Sistemas Multi-Agente e haver algum realce para a componente de negociação. A cooperação e negociação podem ser vistas a diversos níveis, como por exemplo:

• Entre recursos de uma mesma linha de produção ou de uma mesma célula de fabrico; • Entre diversas linhas de produção ou células de fabrico; • Entre a empresa e os seus fornecedores ou clientes (empresa estendida); • Entre diversas empresas para tirar partido de uma nova oportunidade de negócio

(agilidade, empresa virtual). Vamos considerar um exemplo muito simples de escalonamento de tarefas num sistema produtivo constituído por diversos recursos (robots, máquinas CNC, armazéns automáticos, etc). Poderemos ter agentes que representem os recursos físicos do sistema e agentes que representem as tarefas a executar (ao nível da encomenda ou da ordem de fabrico). Um agente que represente uma tarefa que necessite de buscar peças ao armazém, usar robots para transportar tais peças e usar as máquinas CNC terá que negociar com cada um desses recursos de modo a obter uma solução que viabilize a execução da tarefa (por exemplo, garantindo prazos de entrega, níveis de qualidade e custos compatíveis). O problema é mais complexo na medida em que temos várias tarefas a negociar com os recursos ao mesmo tempo. Note-se aqui a noção de agente, temos um agente que representa cada tarefa, quase como se fosse o representante do cliente dentro da empresa, temos também um agente para cada recurso, que representará esse recurso, podendo, por exemplo, negociar a passagem de operações que lhe tenham sido atribuídas para outros recursos em caso de sobrecarga ou de falha. É uma abordagem claramente diferente de um sistema inteligente centralizado que pode usar herísticas de despacho das tarefas, mas que não representa adequadamente as entidades intervenientes. Com os agentes, o Sistema Produtivo pode ser visto como se fosse um Sistema Social. 3.4 – Controlo de Tráfego O controlo de trafego aéreo é uma aplicação crítica caracterizada pela complexidade, mas que tem uma natureza claramente distribuída. Podemos imaginar Agentes que representem vôos, filas de aviões, pistas, etc. Também podemos ter Agentes que considerem aspectos como, por exemplo, os factores climatéricos. O problema é claramente um problema de escalonamento e até podemos fazer uma comparação com um sistema produtivo:



Vôo ⇔ Ordem de Fabrico, Encomenda; Pista ⇔ Máquina; Tempos entre aviões na pista ⇔ Tempos de Activação (Setup).

Outro exemplo de aplicação de controlo de trafego corresponde ao controlo do tráfego urbano numa cidade. Poderemos ter agentes associados aos semáforos, com sensores que indiquem o fluxo de tráfego ou a dimensão de filas de espera. Desse modo os agentes podem negociar entre si, e num cruzamento onde esteja a ocorrer um fluxo muito maior numa direcção face a outra, poderá haver um ajuste das temporizações. Também poderá ser feita a coordenação de vários semáforos alinhados numa dada avenida, de modo a que os automobilistas não tenham que parar consecutivamente nos diversos semáforos.



4 – Limitações de Soluções baseadas em Agentes Vamos apontar algumas desvantagens das soluções baseadas em Agentes:

1) Não há um controlador total do sistema – As soluções baseadas em agentes podem não ser adequadas para problemas onde restrições globais tenham que ser mantidas, onde seja necessário um comportamento em tempo-real e onde devam ser evitados deadlocks; 2) Não há uma perspectiva global – Uma acção de um agente é determinada pelo estado local do agente. O conhecimento global completo não é possível pelo que os agentes apenas podem atingir globalmente decisões sub-óptimas; 3) Confiança e delegação de competências – para que alguém possa delegar tarefas aos agentes deverá, primeiro, confiar nesses mesmos agentes. As organizações necessitam de maior experiência com componentes de software autónomos. O processo de ganho de confiança nos agentes por parte dos utilizadores demora algum tempo. A personificação cuidada do agente é outro aspecto que se relaciona com a confiança no agente, como garantirmos que o Agente nos representa de facto?

As duas primeiras limitações das soluções baseadas em agentes advêm, directamente, do facto das comunidades de agentes serem sistemas distribuídos. Contudo, é a terceira limitação que mais condiciona a aceitação das soluções baseadas em agentes. Por exemplo, suponhamos que alguém nos fornece um agente que é capaz de ser configurado para efectuar compras na Internet em nosso lugar. Seríamos capazes de acreditar em tal agente a ponto de lhe fornecer os dados do nosso cartão de crédito e autorizá-lo a fazer encomendas? Tal parece apontar para a necessidade de um novo modo de desenvolver Agentes. Se a finalidade de um Agente for a de substituir um utilizador, o Agente deverá ser visto inicialmente como um Sistema de Apoio à Decisão, que não limite o utilizador, mas que lhe sugira decisões, aceite modificações nestas e seja capaz de aprender com a interacção do utilizador. Desse modo um Agente passa a ser uma entidade que se adapta ao utilizador e passa a exibir um comportamento cada vez mais próximo do deste, permitindo que o utilizador vá confiando cada vez mais no Agente, até que a confiança seja plena. A tal abordagem designa-se “Inteligência Escalável”, sendo o caminho de conversão de um Sistema de Apoio à Decisão rudimentar num Agente. Num Sistema de Apoio à Decisão com Inteligência Escalável o decisor pode usar tanta inteligência do sistema quanto queira. Tudo se passa como se houvesse uma escala, variando



no intervalo [0,1]. No limite inferior, o Sistema de Apoio à Decisão é apenas uma ferramenta rudimentar, sem capacidade de decisão. Com o tempo, o decisor vai experimentando algumas das funcionalidades mais inteligentes do sistema, podendo condicioná-las. À medida que o decisor verifica que tais funcionalidades têm o desempenho adequado, vai ganhando confiança nestas e poderá atribuir as competências correspondentes ao sistema, o que corresponde a aumentar o nível de inteligência na escala citada. Com o passar do tempo, mais competências vão sendo passadas para o sistema, nomeadamente se este for facilmente moldável ao decisor e se apresentar características mais inteligentes como a capacidade de estabelecer um diálogo inteligente e aprender com o decisor. Isso corresponde a aumentar ainda mais o nível de inteligência na escala até se atingir o limite superior (limite hipotético). Nessa situação, o decisor confia plenamente no sistema, ou seja, confia num Sistema Inteligente que o substitui adequadamente num conjunto, mesmo que limitado, de funções, para as quais o Sistema de Apoio à Decisão foi concebido. Logo, o sistema é passível de ser substituído por um Agente Inteligente desde que seja dotado de autonomia [Ramos-2001].



5 – Dificuldades no desenvolvimentode Agentes e Sistemas Multi-Agente

Apesar dos desenvolvimentos na Ciência dos Agentes, pouco esforço foi devotado à questão de como desenvolver tais sistemas (“Engenharia” dos Agentes). Michael Wooldridge e Nicholas Jennings identificaram várias categorias de problemas que limitam o desenvolvimento de sistemas orientados para Agentes, destacando-se as seguintes categorias de problemas [Wooldridge-1998]:

1) “Políticos”; 2) de Gestão; 3) Conceptuais; 4) de Análise e Projecto; 5) Micro-Nível (Agente); 6) Macro-Nível (Sociedade); 7) de Implementação.

5.1 – Problemas Políticos 5.1.1 - Optimismo na tecnologia dos Agentes (para “vender” o conceito) Os Agentes correspondem a um modo natural e poderoso de conceptualizar, projectar e implementar sistemas. Mas não são um paradigma “mágico”. As tarefas que estejam para além da “automação”, e para as quais foram tentadas técnicas não baseadas em agentes, não serão tratáveis apenas por se usarem agentes. Os agentes terão de ser capazes de efectuar as tarefas do domínio específico para o qual são usados, contudo as tecnologias para resolver tais tarefas continuam a ter as mesmas limitações que tinham anteriormente (por exemplo, explosão combinatória, falta de informação, etc). Os agentes não são capazes de apresentar raciocínio e actuação similares aos dos seres humanos, tal como na Inteligência Artificial a tecnologia dos agentes irá sofrer se se adoptar um optimismo desenfreado.



5.1.2- Agentes como um dogma Apesar de poderem ser aplicados uma vasta gama de tipos de problemas e aplicações, os agentes não são uma solução universal. Há muitos problemas e aplicações para as quais os paradigmas convencionais são suficientes (por exemplo, a POO). Há um grande risco em pensar que os Agentes são a solução correcta para qualquer problema. Por outro lado as definições de agentes são variadas e englobam características específicas que se procura realçar. Quem sobrevaloriza uma característica específica desenvolve soluções usando tal característica, mesmo quando tal não seja natural para a situação em causa (por exemplo, a mobilidade pode ser perfeitamente acessória, ou mesmo desadequada em muitas situações). 5.2- Problemas de Gestão 5.2.1- Não se sabe porque se necessita de Agentes As previsões optimistas fazem com que os gestores tentem colar-se à ideia, nomeadamente quando o conceito parece intuitivo (como se passa com os agentes) e passível de ser vendido facilmente (agentes que nos libertem de um grande conjunto de tarefas). Iniciam-se projectos sem se ter em vista objectivos claros, o que dificulta o controlo do próprio projecto. Contudo, continua-se a não se ter uma ideia clara de como os agentes poderão ser usados para dar valor acrescentado aos produtos. Como lição devemos entender as razões para o desenvolvimento de um projecto envolvendo agentes e sabermos o que poderemos ganhar com tal projecto. 5.2.2- Não se sabe para que servem os Agentes desenvolvidos Podemos cair no erro de desenvolver alguma tecnologia ou plataforma de agentes ou algum agente específico e só de seguida procurarmos a aplicação que tais agentes ou tecnologias poderão ter. Nessa situação o trabalho desenvolvido poderá estar totalmente desadequado (por exemplo, por não se integrar com outros componentes do sistema) ou de ser necessário apenas um reduzido subconjunto de funcionalidades (tornando perfeitamente descabida e encarecendo a solução desenvolvida). Devemos tentar compreender onde a tecnologia dos agentes é mais pertinente e não cairmos na tentação de aplicá-la a qualquer situação.



5.2.3- Tentativa de desenvolver solução genéricas para problemas específicos Muitos daqueles que gostam da tecnologia dos agentes gostam de referir-se a arquitecturas genéricas que possam ser aplicadas a qualquer domínio. Essa é uma reminiscência dos primeiros tempos da Inteligência Artificial, quando muitos entendiam que era possível desenvolverem-se resolvedores de problemas genéricos. 5.2.4- Confusão entre protótipos e sistemas Uma vez encontrada uma aplicação para a qual a tecnologia dos agentes parece adequada é simples desenvolver um protótipo (poucos agentes efectuando algumas tarefas úteis e simples). Contudo, a passagem de protótipo para sistema é muito complexa, e a prototipagem rápida que se efectuou pode ser enganosa. Os agentes lidam com aspectos complexos como:

• Resolução de problemas distribuída e concorrente; • Interfaces flexíveis e sofisticadas entre componentes; • Componentes individuais complexos com comportamento dependente do contexto.

5.3- Problemas Conceptuais 5.3.1- Acreditar que os agentes são a solução milagrosa Por vezes há a tendência em acreditar que uma dada tecnologia vai permitir um grande desenvolvimento (uma ordem de magnitude superior face as anteriores). Tal começa a ocorrer com a tecnologia dos agentes. Apesar de ser muito promissora e até apontada como o grande paradigma da programação que se segue, essa tecnologia continua a necessitar ser testada e dar provas. 5.3.2- Confusão entre Chavões e Conceitos Um dos aspectos positivos dos agentes tem a ver com o facto de serem um conceito intuitivo. Mas tal leva que muitos pensem que dominam o conceito, quando de facto não o dominam. O uso de chavões, muito usual na gestão, também acaba por ter efeitos ao nível da concepção de sistemas, numa tentativa de os tornar sistemas de “ponta”. 5.3.3- Esquecer que se está a desenvolver software Sendo uma área em investigação, ainda não há técnicas adequadas para auxiliar quem desenvolve o sistema. Os projectos de agentes acabam por envolver tarefas como: investigar arquitecturas de agentes, desenvolver protocolos de cooperação, melhorar a coordenação e coerência da actividade multi-agente, etc. Os processos de Engenharia de Software usuais como a análise de requisitos, especificação, projecto, verificação e teste são muitas vezes



esquecidos, sendo também verdade que não foram pensados para comunidades de agentes. Mas usar aquilo que existe é melhor do que não usar nada, e esquecer a Engenharia de Software pode levar a que um sistema falhe não por causa dos agentes mas por causa do esquecimento das boas práticas do desenvolvimento do software. 5.3.4- Esquecer que se está a desenvolver software distribuído Os Sistemas Distribuídos são há muito tempo reconhecidos como sistemas complexos de projectar e implementar. Os Sistemas Multi-Agente são distribuídos, pela sua própria natureza. Os problemas dos Sistemas Distribuídos não desaparecem apenas porque se usam agentes. Pelo contrário, os sistemas multi-agente são até mais complexos que os sistemas distribuídos. Quem projecta e desenvolve sistemas multi-agente deve ser competente nos fundamentos dos sistemas distribuídos (sincronização, exclusão mútua, partilha de recursos, deadlocks, etc). 5.4- Problemas de Análise e Projecto 5.4.1- Não explorar as tecnologias relacionadas No desenvolvimento de um Sistema Multi-Agente uma grande parte do esforço deverá ser devotada ao uso de tecnologias diferentes, mas que precisam funcionar bem para que o Sistema Multi-Agente também funcione. 5.4.2- O projecto não explora a concorrência É comum encontrarmos sistemas multi-agente nos quais um agente efectua algum processamento, produz resultados que são passados para outro agente e depois entra num estado de adormecimento, o agente que recebe os resultados efectua processamento, produz resultados que envia a outro agente e também fica adormecido, o processo repete-se até se chegar ao objectivo pretendido. Tais sistemas não envolvem concorrência e poderiam funcionar como um programa centralizado convencional, com vários módulos. A concorrência é uma das principais vantagens dos sistemas multi-agente. Permite lidar simultaneamente com várias perspectivas e objectivos, responder e reagir ao ambiente a diferentes níveis e considerar métodos complementares de resolução de problemas de um modo inter-relacionado.



5.5- Problemas Micro-Nível (Agente) 5.5.1- Queremos a nossa própria arquitectura de agentes Há a tentação de considerar que nenhuma das arquitecturas de agentes existentes atendem aos requisitos específicos do nosso problema e que é necessário especificar e projectar uma nova arquitectura. O complexo do “não inventado aqui”, no qual só se acredita em produtos desenvolvidos na própria instituição também leva a que se aposte no desenvolvimento de novas arquitecturas. Contudo, o desenvolvimento de uma nova arquitectura leva anos e não há a garantia que tal esforço seja recompensado e possa ser reusado. Aconselha-se a estudar as arquitecturas existentes e adquirir licenças ou implementar arquitecturas já testadas. 5.5.2- Pensar que a arquitectura que se usa é genérica Quem desenvolve uma arquitectura tem a tentação de acreditar que ela é genérica. Essa tentação é mais notória se a arquitectura teve sucesso num dado domínio de aplicação. Contudo, as características da arquitectura podem ser desadequadas a uma aplicação diferente. Se desenvolvemos um arquitectura que foi usada com sucesso numa aplicação específica devemos tentar compreender as razões que levaram tal arquitectura a ter sucesso nessa mesma aplicação. 5.5.3- Os Agentes usam muita Inteligência Artificial A leitura de artigos e relatórios que reportam exemplos de aplicações de técnicas de IA em Agentes pode fazer crer que quanto mais IA estiver embutida nos nossos agentes tanto melhor será o desempenho da comunidade de agentes. Muitas das técnicas referidas ainda não são suficientemente robustas, o que acabará por condicionar o sucesso do nosso projecto. É aconselhável usar a “máxima” “pensar em grande mas começar pequeno”. É preferível tentar uma primeira solução com pouca IA e ir incorporando IA com o tempo. 5.5.4- Os Agentes não têm inteligência Muitas vezes, e por uma questão de marketing, soluções que seriam bem classificadas como sistemas distribuídos aparecem designadas como sistemas multi-agente. É também comum ver simples páginas Web com algum processamento adicional classificadas como agentes. Tal é incorrecto porque tira completamente sentido ao termo agente. Por outro lado, tal prática leva a que os destinatários do software desenvolvido se sintam ludibriados por terem adquirido um software convencional com o nome de agente(s).



5.6- Problemas Macro-Nível (Sociedade) 5.6.1- Vemos agentes em todo o lado Uma vez assimilado o conceito, podemos acreditar que quase tudo pode ser visto como um agente. No limite teremos um agente que faz somas e outro que faz subtracções. Mas pensar dessa maneira vai acabar por originar tantos agentes e tanta necessidade de comunicação que as soluções criadas acabarão por ser ineficientes, se não forem mesmo impraticáveis. De um modo geral deveremos ter uma granularidade grossa para os agentes, atendendo a que um agente deve incorporar capacidades e funcionalidades coerentes e significativas. A ideia de decomposição de agentes em outros agentes pode ser interessante, mas pode corresponder a sobrecargas computacionais que nos acabem por desapontar. 5.6.2- Temos muitos agentes Um dos aspectos interessantes das comunidades de agentes corresponde ao aparecimento de comportamentos emergentes quando o número de agentes é significativo. Um comportamento emergente é algo que não estava previsto globalmente mas acaba por acontecer na prática como resultado do processamento e das interacções dos agentes. Tais comportamentos emergentes podem ser positivos e gerarem trabalho útil. Contudo, também podem originar situações caóticas. É difícil controlar-se a dinâmica de um sistema quando o número de agentes é muito elevado. Com muitos agentes temos o problema apontado anteriormente de excesso de comunicação. 5.6.3- Temos poucos agentes Muitas vezes aqueles que desenvolvem agentes não conseguem aperceber-se da vantagem da concorrência e tendem a desenvolver comunidades com poucos agentes, mas em que cada agente desempenhe uma grande quantidade de tarefas e funcionalidades. 5.6.4- Gastamos todo o tempo a implementar a infra-estrutura Sendo uma área emergente, só agora começam a aparecer as primeiras plataformas minimamente credíveis para o desenvolvimento de soluções baseadas em agentes. Contudo, no passado tais plataformas não existiam e qualquer projecto de Sistemas Multi-Agente tinha que prever um esforço e orçamento significativos no desenvolvimento da plataforma (tínhamos que lidar com as mensagens, controlo em run-time, monitoração, etc).



Mesmo agora, as plataformas existentes podem corresponder a apostas arriscadas pois aparecem e são descontinuadas com frequência. Algumas são muito boas para a visualização do que se está a passar, mas são ao mesmo tempo muito pesadas, enquanto que outras são “leves” mais pouco atractivas para quem desenvolve os sistemas. É comum encontrar infra-estruturas de comunicação implementadas por pessoas com bases em Inteligência Artificial, ao invés de pessoas da área dos sistemas distribuídos e das comunicações, o que poderá acabar por comprometer o futuro da infra-estrutura a usar. 5.6.5- O sistema é anárquico Por vezes pensa-se que basta juntar um conjunto de agentes desenvolvidos sem interacção uns com os outros para se obter uma comunidade de agentes. Contudo, a maioria dos sistemas multi-agente necessitam de alguma estruturação, definição de competências e controlo, de modo a que a comunidade de agentes possa efectuar trabalho útil e de modo a que os objectivos sejam cumpridos. 5.6.6- Confundir paralelismo simulado com paralelismo real Por vezes o projecto de uma comunidade de agentes começa num único computador, usando processos independentes ou threads. Mas o sistema não é desenvolvido sobre uma rede de computadores, o que pode ser vantajoso numa primeira fase. Mas a passagem para o paralelismo “real” está uma ordem de magnitude acima do que foi desenvolvido no protótipo, nomeadamente ao nível do controlo do sistema multi-agente. 5.7- Problemas de Implementação 5.7.1- Tábua rasa Quando se passa à fase de implementação comete-se o erro de admitir que tudo necessita de ser desenvolvido desde o princípio, mesmo os sistemas que efectuam as tarefas. Mas, muitas vezes não é possível criar novos sistemas para executar as tarefas, pois há situações críticas para as quais os componentes usados já foram testados e provaram ser robustos, mesmo que estejam obsoletos não será aconselhável substituí-los (correspondem a sistemas legados). A questão que se põe é a de como usar tais sistemas, na maioria dos casos sem poder intervir nesses mesmos sistemas.



5.7.2- Ignorar Normas A normalização ao nível dos agentes está muito atrasada. Há propostas, mas as normas não foram aceites na generalidade e acabam por não ser usados. Isso conduz a um problema complexo quando temos que juntar agentes desenvolvidos por grupos diferentes. Apesar da ausência de normalização convém tentar seguir algumas propostas relacionadas com a interacção entre agentes (KIF, KQML, ACL).



6 – Arquitecturas de Agentes e de Sistemas Multi-Agente A arquitectura de um agente determina a sua estrutura interna, definindo os módulos que estarão envolvidos nas várias tarefas cobertas pelo agente e o modo como tais módulos interagem entre si com vista a operarem no ambiente sobre o qual interagem. Geralmente, um agente está envolvido numa ou mais comunidades multi-agente. Também podemos referir arquitecturas de sistemas multi-agente, as quais definem o modo como os agentes se organizam com vista a resolverem em conjunto um dado problema. Se quisermos estabelecer uma analogia podemos dizer que o agente relaciona-se com a Psicologia de um indivíduo, enquanto que o sistema multi-agente relaciona-se com a Sociologia. 6.1 – Arquitectura de um Agente Nesta secção vamos estudar algumas arquitecturas básicas de Agentes, não procurando ser exaustivos, mas tentando dar uma ideia dos módulos principais de tais arquitecturas. A primeira arquitectura que iremos estudar é a Arquitectura BDI (Belief, Desire, Intention). A ideia básica dessa arquitectura, considerada como deliberativa, é a descrição do estado de processamento interno de um agente através de categorias mentais e estabelecer um modo de controlo através do qual um agente selecciona racionalmente as acções a tomar tendo em conta as suas representações. As categorias mentais são as crenças, desejos e intenções. Adicionalmente, há categorias de nível mais elevado, tais como os objectivos e os planos. De seguida iremos descrever melhor cada uma dessas categorias mentais:

• Crenças – são expectativas do agente acerca do estado actual do mundo que o rodeia, considerando a possibilidade de uma determinada acção causar certos efeitos;

• Desejos – correspondem a uma noção abstracta que indica preferências sobre os estados

futuros do mundo ou sobre o curso de acções a seguir, os agentes podem ter desejos inconsistentes nem têm que acreditar que os seus desejos são atingíveis;

• Objectivos – trata-se de uma definição mais “fraca” que a de desejos, visto que o agente

deve considerar os seus objectivos como plausíveis de poderem ser atingidos;



• Intenções – dado que um agente é limitado em termos de recursos, pode não ser possível cumprir todos os objectivos ao mesmo tempo, por essa razão torna-se necessário chegar a um compromisso sobre a quais objectivos deve ser dada prioridade, a tal processo chamamos formação de intenções;

• Planos – são implementações pragmáticas das intenções, as intenções podem ser vistas

como planos de acção parciais, efectuando o agente uma série de compromissos, no sentido de se executar tais intenções para cumprir os objectivos visados.

Dois trabalhos que consideram arquitecturas BDI são o IRMA [Bratman-1987] e [Rao-1991]. A segunda arquitectura que vamos considerar é uma arquitectura reactiva, a arquitectura de Brooks [Brooks-1986], também conhecida como “Subsumption Architecture”. Em meados dos anos 80, Brooks criticava a tendência dos sistemas inteligentes em considerar um conjunto de funcionalidades que trabalhavam essencialmente em série (por exemplo, sensores, planeador, módulo de aprendizagem, manutenção da verdade, executor). A proposta de Brooks assenta numa decomposição orientada por actividades, com produtores de actividade que operam em paralelo e que estão directamente ligados ao mundo externo do agente através dos sensores e actuadores. A terceira arquitectura que se irá ilustrar é a arquitectura ARCHON (Architecture for Heterogeneous On-Line Systems). Essa arquitectura foi desenvolvida no âmbito de um projecto europeu do programa ESPRIT-II [Wittig-1992] e encontra-se ilustrada na figura 3.

Módulo deComunicações a

Alto-Nível

Módulo deConhecimento da

Comunidade

Módulo dePlaneamento eCoordenação

Módulo de AutoConhecimento

Monitor

Sistema Inteligente

Camada ARCHON

Figura 3 – Arquitectura ARCHON



O princípio básico da arquitectura é que qualquer sistema já existente (Sistema Inteligente na figura) pode ser encapsulado por uma “Camada ARCHON” de modo a constituir um agente. Desse modo um Agente é sempre constituído por pelo menos dois processos computacionais (o Sistema Inteligente e a Camada ARCHON), claro que cada uma dessas partes pode envolver mais processos. Nada implica que ambos estejam no mesmo recurso computacional. O Sistema Inteligente é responsável pelo trabalho útil do Agente (por exemplo, reconhecer um objecto com recurso a um sistema de visão por computador ou efectuar uma tarefa de escalonamento de tripulações de uma companhia aérea) enquanto que a Camada ARCHON é responsável pela cooperação entre esse agente e os outros agentes da comunidade cooperante e pelo controlo do Sistema Inteligente associado. Os módulos da camada ARCHON são os seguintes:

• Módulo de Auto-Conhecimento; • Módulo de Conhecimento da Comunidade; • Módulo Monitor; • Módulo de Planeamento e Coordenação; • Módulo de Comunicação a Alto-Nível.

A finalidade do Modelo de Auto-Conhecimento é representar o que o Agente sabe acerca de si próprio e das tarefas que pode executar. O Modelo de Conhecimento da Comunidade reflecte aquilo que o Agente sabe acerca dos outros Agentes da Comunidade. Ambos contêm informação estática (por exemplo, no Modelo de Auto-Conhecimento está o que o Sistema Inteligente sabe fazer e no Modelo de Conhecimento da Comunidade está a informação de quem é capaz de fornecer uma dada informação) e dinâmica (no Auto-Conhecimento pode aparecer o que o Sistema Inteligente está a fazer nesse momento e no Conhecimento da Comunidade pode aparecer o que os outros agentes estão a fazer). O Monitor é responsável pela interacção e pelo controlo das actividades do Sistema Inteligente associado ao Agente. O Monitor recebe pedidos e informação vinda do módulo de Planeamento e Coordenação, ordena o lançamento de uma tarefa por parte do Sistema Inteligente, tem a capacidade de interferir no modo como essa tarefa é executada, recebe os resultados da tarfa (enviados pelo Sistema Inteligente) e faz a difusão desses resultados para o módulo de Planeamento e Coordenação. O Módulo de Planeamento e Coordenação decide quando e como o Agente deve entrar em cooperação com os outros agentes da comunidade. É o módulo responsável pela avaliação da situação global e pelo planeamento dinâmico de actividades do agente. É este módulo que decide a quem devem ser efectuados os pedidos e que restrições devem estar associadas a esses pedidos. O módulo de Comunicações a Alto-Nível define como será feito o diálogo entre o Agente e os outros membros da comunidade quer no que toca à informação que chega quer à que se pretende enviar. Era usada uma filosofia de passagem de mensagens (baseada em sockets) como base de comunicação, havendo três serviços adicionais: endereçamento inteligente, filtragem e escalonamento de mensagens.



Mais detalhes sobre a Arquitectura ARCHON podem ser encontrados em [Wittig-1992] e [Ramos-1993]. Finalmente, iremos detalhar a arquitectura proposta em [Sousa-2000] que se baseia no conceito de Holon [Koestler-1967]. O conceito de Holon foi introduzido pelo filósofo húngaro Arthur Koestler em 1967. O termo Holon resulta da combinação da palavra grega holos, que significa “todo”, com o sufixo on da língua inglesa, que sugere parte, como em proton ou neutron. Sendo assim, o termo holon passa a designar o todo e a parte, implicando que tenha uma natureza recorrente. Um holon pode ser constituído por outros holons e ser parte de outro holon. Adicionalmente, um holon pode pertencer a mais do que um holon ao mesmo tempo. Apesar de ser originário dos pensamentos de um filósofo, o conceito de holon foi adoptado pela comunidade científica dos Sistemas Inteligentes de Produção (Intelligent Manufacturing Systems) e adaptado como modelo que pode descrever de um modo muito adequado um Sistema Produtivo (ou outro tipo de sistemas) [Ramos-1996]. Podemos estabelecer grandes semelhanças entre o conceito de holon e de agente. Na secção seguinte, iremos voltar ao tema para introduzir o conceito de holarquia. Retomando a arquitectura proposta em [Sousa-2000], que é ilustrada na figura 4, podemos ver que o holon/agente é constituído por Sensores, Actuadores, Protocolos, Acções, Raciocínio e Base de Conhecimento. Este holon/agente é capaz de interagir com indivíduos, com o ambiente e com outros holons.

Protocolos Acções

Sensores Actuadores

Indivíduos

Ambiente

Holons

"Raciocínio"

Base de Conhecimento

Figura 4 – Arquitectura de um Holon/Agente [Sousa-2000] Os blocos Sensores e Actuadores representam a interface do sistema, possibilitando a interacção com seres humanos, ambiente ou outros holons. O bloco Protocolos representa o mecanismo de representação de informação recolhida pelos sensores (percepções), podendo os



protocolos ser identificados através de uma máquina de estados finitos de um protocolo de comunicação ou de interacção homem/máquina. Este bloco permite a execução directa de acções e/ou o tratamento do conhecimento através do bloco de Raciocínio. O Raciocínio do holon permite-lhe compor resultados tendo em conta o seu conhecimento (Base de Conhecimento) e a informação que chega via sensores. Este bloco faz parte da natureza de cada holon, definindo como o holon deve actuar de acordo com o seu estado mental e os objectivos que tem para atingir. O conhecimento do holon pode ter diversas origens: inerente à concepção do holon; por aprendizagem oriunda da experiência ou observação; por informação de outro holon. A Base de Conhecimento de cada holon deve conter um conjunto de axiomas gerais e específicos. 6.2 – Arquitecturas de Sistemas Multi-Agente Uma Arquitectura de um Sistema Multi-Agente vai descrever o modo como os agentes se relacionam de modo a resolver um determinado problema. As arquitecturas poderão ser orientadas a um problema específico ou genéricas, poderão ser mais centralizadoras (por exemplo, estrutura hierárquica com agente centralizador) ou mais distribuídas (por exemplo, estrutura “anárquica”). Os agentes envolvidos poderão ser funcionalmente diferentes (complementares) ou idênticos (concorrentes, com maior potencialidade de conflitos). A arquitectura poderá ser fixa ou reorganizável. Nesta secção vamos mostrar algumas arquitecturas de Sistemas Multi-Agente. A primeira arquitectura que ilustraremos será CIARC (Cooperative Intelligent Assembly Robotics Community) [Ramos-1993]. Essa arquitectura Multi-Agente destina-se a um sistema de montagem e manipulação de peças com recurso a um manipulador robótico com configuração em braço articulado. Eram posicionados objectos sobre uma mesa de trabalho e dado um objectivo final (montagem final) indicando as posições e orientações que os objectos deveriam ter no final. Foram desenvolvidos dois sistemas de visão por computador (VISION usando uma abordagem 2D e LASER usando uma abodagem 3D) que eram capazes de reconhecer e identificar a posição e orientação dos objectos. Havia um agente WD (World Descriptor) com capacidade de estabelecer relacionamentos simbólicos entre objectos (por exemplo, concluir que um objecto estava em cima de outro). Outro agente, TLP (Task Level Plan), era capaz de gerar planos simbólicos de alto nível para manipular objectos (por exemplo, inserir A em B). O controlo do robot era feito pelo agente ELP&TE (Execution Level Planner & Task Executor) que efectuava o raciocínio geométrico para tornar e execução das operações simbólicas de TLP viáveis, esse agente usava sensores de proximidade durante a execução da tarefa e era reactivo, podendo reagir a situações não esperadas, como, por exemplo, a detecção de um obstáculo, seguida do mapeamento e remoção do mesmo. Finalmente, existia um agente MODELS que armazenava modelos de vários tipos dos objectos, úteis para o estabelecimento de relacionamentos simbólicos e para a execução da tarefa de montagem ou manipulação.



Se excluirmos LASER e VISION, que tinham uma função idêntica de reconhecimento de objectos, todos os outros agentes eram funcionalmente diferentes, ou seja, o problema global era decomposto em subproblemas que eram resolvidos pelos agentes. A figura 5 dá uma melhor ideia do fluxo de pedidos entre agentes numa tarefa típica em sistema CIARC.

TLP

WD

ELP&TEMODELS

VISION

LASER

2a

2a

2b

2c2d

3a

3a3b

4b

4b4a

User1

Fig. 5 –CIARC: pedidos de execução de tarefas O utilizador, que pode também ser visto como um agente no processo, põe um pedido ao agente ELP&TE para que este execute uma tarefa de montagem (pedido 1). ELP&TE necessita de conhecer a localização dos objectos, através do seu posicionamento e orientação, (pedido 2a feito a VISION e LASER), os modelos de manipulação (pedido 2b feito a MODELS, os relacionamentos e restrições simbólicas (pedido 2c feito a WD) e o plano simbólico de alto-nível (pedido 2d feito a TLP). TLP necessita também conhecer a localização dos objectos (pedido 3a feito a VISION e LASER) e os relacionamentos e restrições simbólicas (pedido 3b feito a WD). WD necessita os modelos geométricos (pedido 4a feito a MODELS) e a localização dos objectos (pedido 4b feito a VISION e LASER). De seguida iremos descrever uma arquitectura holónica, que irá ser concretizada em termos de um Sistema de Produção para uma melhor compreensão. Nessa arquitectura teremos holons representando tarefas (HT), holons representando recursos (HR) e holons representando produtos (HP). Os holons tarefa mais básicos podem agrupar-se de modo a formar holons tarefa de maior dimensão, ou um holon tarefa pode decompor-se em holons tarefa mais básicos. Por exemplo, uma tarefa para fabricar 10 conjuntos de 1 mesa e 4 cadeiras (por exemplo, mobiliário de um



restaurante) pode ser decomposta em 2 holos tarefa, um para fabricar 10 mesas e outro para fabricar 40 cadeiras. De igual modo os holons recurso podem ser decomponíveis ou fazerem parte de outros holons recurso a um nível mais detalhado ou mais geral, respectivamente. Consideremos, por exemplo, uma célula de fabrico que envolve um torno, uma fresadora e um robot. A célula de fabrico pode ser um holon, e pode ter como componentes 3 holons (torno, fresadora e robot), por sua vez essa célula pode estar inserida num holon linha de produção, componto por várias células. Vários holons linhas de produção podem compor um holon fábrica. Uma característica idêntica passa-se com os holons produto. Neste caso os holons produto podem ser compostos por holons componentes (os componentes também são produtos). As várias fases do processo produtivo podem envolver holons diferentes. Por exemplo, o holon escalonamento (Hesc) é composto por holons tarefa e por holons recurso, o holon de Planeamento do Processo (HPP) é composto por holons recurso e holons produto. Tal como referimos uma organização com estrutura hierárquica, também podemos definir uma organização holónica como tendo uma estrutura holárquica (holarquia). A holarquia vai definir a forma de cooperação, tendo em vista objectivos pré-definidos, e limitando a autonomia dos holons (se não houver essa limitação teremos algo similar a um sistema anárquico). A figura 6 dá um exemplo de uma arquitectura holónica para sistemas produtivos.

HT

HTHTHT

HT

HT

HT HR

HRHRHR

HR

HR

HR

HP

HPHPHP

HP

HP

HP

HEsc

HPP

Fig. 6 –Arquitectura holónica de produção



7 – Tecnologias Básicas de Distribuição Esta secção pretende apresentar uma pequena introdução às tecnologias existentes para o desenvolvimento de aplicações distribuídas e/ou de computação paralela. O que será referido aqui irá ter como fonte um estudo sobre Tecnologias de Distribuição [Sousa-1999]. Serão focadas apenas algumas dessas tecnologias com especial ênfase para aquelas que podem de alguma forma ser consideradas como middleware, ou seja, que fornecem serviços de médio nível ao programador, abstraindo-o da complexidade dos níveis mais baixos, mas deixando liberdade para os níveis superiores. Assim sendo, não serão analisadas APIs de comunicações (por exemplo, sockets) que apenas tratam do aspecto de estabelecer e fechar conexões e envio/recepção de mensagens. No entanto, serão analisadas tecnologias que tendo como base estas APIs de comunicações, acrescentam um maior nível de abstracção, como por exemplo o RPC que permite escrever um programa, praticamente ignorando o facto de ser distribuído ou não. No campo da computação paralela, será analisado o PVM (Parallel Virtual Machine), que usa um conjunto de computadores heterogéneos como uma única máquina virtual, e o MPI (Message Passing Interface), que é uma especificação standard construída por vários especialistas em computação paralela. No que se refere ao desenvolvimento de sistemas distribuídos serão referidas as tecnologias DCOM, CORBA e RMI. Não se pretende aqui efectuar um estudo exaustivo destas tecnologias, que estarão no âmbito dos Sistemas Distribuídos, visto a atenção nestes apontamentos ser centrada no desenvolvimento de Agentes. Note-se que para o desenvolvimento de agentes há uma grande variedade de sistemas (ZEUS, AgentBuilder, OAA, JAFMAS, JatLite, etc) , que estão a um nível superior ao das tecnologias que aqui se referem. 7.1 – Tecnologia PVM (Parallel Virtual Machine) A ideia base do PVM é o conceito da reunião de um conjunto heterogéneo de computadores ligados em rede numa única máquina virtual. Este conceito deriva da necessidade cada vez maior de resolver problemas de grande dimensão, aliado ao elevado custo actual de plataformas assentes em arquitecturas paralelas de desempenho elevado (caso, por exemplo, dos supercomputadores). Assim, com o uso do PVM, é possível aproveitar as estações de trabalho existentes, ligadas em rede, obtendo uma quantidade apreciável de poder computacional. O



sistema foi desenvolvido por Jack Dongarra e Al Geist do Laboratório Nacional de Oak Ridge, Vaidy Sunderam da Universidade de Emory, Robert Mancheck e Weicheng Jiang da Universidade do Tennessee, e Adam Beguelin da Universidade de Carnegie Mellon [Geist-1994]. De uma forma geral pode definir-se o PVM como uma ferramenta de programação em rede ou em multiprocessadores para processamento paralelo. Nele estão incluídas ferramentas de software e bibliotecas que emulam um ambiente de computação concorrente de uso geral, flexível e heterogéneo, a partir de uma rede de computadores de arquitecturas diversas. O principal objectivo é permitir que este conjunto de computadores possa ser usado cooperativamente para a execução de programação paralela. Cada computador é vulgarmente designado por nó. A forma de comunicação entre os nós é através da passagem de mensagens, existindo rotinas para comunicação ponto-a-ponto e colectiva. Segundo [Geist-1994b], os princípios em que o PVM se baseia são:

existência de uma tabela de nós configurável pelo utilizador, alterável dinamicamente; acesso transparente ao hardware, o que permite explorar as capacidades de cada uma das

máquinas; computação baseada em tarefas, isto é, segmentos de código sequencial em que a

computação e a comunicação se alternam; modo explícito de passagem de mensagens; heterogeneidade em termos de máquinas, redes e aplicações; suporte de multiprocessadores, existindo alguns vendedores que fornecem a sua própria

versão optimizada do PVM.

Existem duas partes principais no PVM:

pvmd (PVM Deamon): corre em cada um dos nós da máquina virtual, encaminhando e controlando mensagens, controlando e autenticando os processos, e fazendo a detecção de falhas;

libpvmd: biblioteca que contém as primitivas necessárias à cooperação entre tarefas. Existem rotinas de suporte à passagem de mensagens, distribuição de processos, coordenação de processos e alteração da máquina virtual.

As linguagens suportadas pelo PVM são o C, C++ e Fortran. Cada tarefa é identificada pelo seu TID (Task ID por analogia ao PID). Desta forma, qualquer tarefa pode comunicar com outra desde que saiba o seu TID. A comunicação entre os deamons dos diferentes nós é feita através de sockets UDP (User Datagram Protocol), enquanto as tarefas comunicam com o seu pvmd através de uma ligação TCP (Tansmission Control Protocol). É de referir a existência de uma boa tolerância a falhas uma vez que as tarefas podem requerer uma notificação dos recursos disponíveis a qualquer momento. De referir ainda que as tarefas podem ser iniciadas e terminadas em qualquer nó, podem entrar e sair de um grupo em qualquer momento e que a conversão de dados (importante num conjunto heterogéneo de máquinas) é tratada pelo PVM.



7.2 – Tecnologia MPI (Message Passing Interface) A necessidade de obter um sistema standard para a passagem de mensagens esteve na base do aparecimento do MPI. Cada vendedor estava a produzir o seu próprio sistema, o que ia contra a necessidade dos programadores no desenvolvimento de bibliotecas. Assim surgiu o MPI Forum [MPI-1995] que reuniu aproximadamente 40 peritos em passagem de mensagens, vendedores de Massive Parallel Processors (MPP), investigadores, programadores de aplicações, durante 3 dias cada 6 semanas no espaço de ano e meio, criando a especificação MPI-1. Esta especificação inclui:

Comunicação ponto a ponto; Operações colectivas; Domínios de comunicação; Topologia de processos; Interface de perfil; Bindings para C e Fortran 77.

Alguns dos novos conceitos introduzidos no MPI foram:

Comunicadores: contexto de comunicação necessário para a concepção de bibliotecas paralelas seguras;

Tipos de dados derivados: tipos de dados definidos pelo utilizador para dados não homogéneos e não contíguos;

Grupos de processos: operações colectivas que podem operar sobre um conjunto de processos.

As reacções ao MPI-1 foram variadas, havendo quem considerasse que era demasiado extenso, enquanto outros achavam demasiado redutor. De qualquer forma, rapidamente apareceram implementações como MPICH, LAM e CHIMP. Os vendedores de MPP de uma forma geral consideraram ser possível obter bom desempenho usando o MPI. Os utilizadores rapidamente adoptaram o MPI e tomaram partido das suas capacidades. Como se achou necessário aumentar algumas capacidades surgiu a especificação MPI-2. Nesta especificação foram introduzidos:

extensões ao modelo de passagem de mensagens: administração dinâmica de processos; operações one-sided; I/O paralelo; Robustez; bindings para C++ e Fortran 90; interfaces e handlers externos; operações colectivas estendidas; interoperabilidade de linguagens.



7.3 – Tecnologia DCOM (Distributed Component Object Model) O Distributed COM (DCOM) é, como o nome indica, uma evolução distribuída do Component Object Model (COM). O COM é uma especificação proprietária (proposta pela Microsoft) para a interoperabilidade de componentes de software. O DCOM acrescenta uma camada de Object Remote Procedure Call ao RPC DCE para suportar objectos remotos. O DCOM surgiu com o Windows-NT 4.0. Um servidor COM pode suportar diversos interfaces, cada um representando uma vista sobre a funcionalidade do objecto. Um interface é um conjunto de métodos funcionalmente relacionados. Um cliente COM interage com um objecto COM adquirindo um ponteiro para um dos interfaces objecto e invocando métodos através desse ponteiro, como se o objecto residisse no espaço de endereço do cliente. O COM especifica que todas as interfaces devem seguir uma disposição padrão na memória, que é a mesma da tabela virtual de funções da linguagem C++. Como a especificação está ao nível binário, é possível a integração de componentes binários escritos em linguagens de programação diferentes tais como C++, Java e Visual BASIC. A empresa alemã Software AG trata da passagem para plataformas não-Windows.

As principais características do COM são as seguintes:

Plataforma de objectos da Microsoft; Muito difundido no mercado desktop (Windows); Standard binário complicado; Funcionalidade é fornecida na implementação de uma interface ; Ponteiro para um interface é semelhante a um ponteiro para uma função virtual em

C++; Cada objecto pode suportar várias interfaces ; Futuro: COM+ programação mais simplificada.

As principais vantagens do DCOM são as seguintes:

Base de utilizadores e mercado de componentes de grande dimensão ; Integração a nível binário ;

Reutilização em grande escala (sem código fonte) Suporte multi-linguagem Integração de ferramentas COTS (Custom Off The Shelf)

Actualização de componentes online permite a actualização de um componente sem recompilação da aplicação ou até mesmo sem reinicialização;

Múltiplas interfaces por objecto ; Selecção variada de ferramentas de programação automação do código standard.

As figuras 7 e 8 dão uma ideia geral da arquitectura DCOM.



Fig. 7 – Arquitectura de aplicação DCOM [Alho-1998]

Fig. 8 – Arquitectura DCOM [Chung-1997]

Relativamente à programação considerando DCOM devemos considerar o seguinte: Definir um interface utilizando IDL (Interface Definition Language) – todas as interfaces

derivam (directa ou indirectamente) da interface genérica IUnknown ; Gerar código proxy/stub ; Implementar o servidor através de "class factory" ;



Tratar de contagem de instâncias (quantas referências existem para um mesmo objecto COM) ;

O cliente utiliza CoCreateInstance() para criar um ponteiro para uma interface ; Utiliza QueryInterface() para aceder a outras interfaces ; Métodos são invocados através do ponteiro para a interface.

7.4 – Tecnologia CORBA O CORBA é uma arquitectura de objectos distribuídos proposta pelo consórcio Object Management Group (OMG), com mais de 700 companhias. O núcleo da arquitectura CORBA é o Object Request Broker (ORB) que age como o canal onde os objectos interagem de forma transparente com outro objectos locais ou remotos. Um objecto CORBA é representado ao mundo exterior por uma interface com um conjunto de métodos. Uma instância particular de um objecto é identificada por uma referência ao objecto. O cliente de um objecto CORBA adquire a sua referência ao objecto e utiliza-a para invocar métodos, como se o objecto estivesse situado no espaço de endereço do cliente. O ORB é responsável por todos os mecanismos requeridos para encontrar a implementação do objecto, prepará-la para receber pedidos, comunicar-lhe o pedido, e carregar a resposta (se alguma) ao cliente. A implementação do objecto interage com o ORB através de um Object Adapter (OA) ou através da interface do ORB.

As principais características do CORBA são as seguintes:

Arquitectura middleware orientada aos objectos para sistemas distribuídos heterogéneos ;

Controlada pelo OMG ; Especificação standard; Grande número de implementações comerciais e públicas; A revisão 2.0 (1995) especifica a interoperabilidade de implementações; Ligações a linguagens: C, C++, Smalltalk, Cobol, Ada, Java ; ORB para serviços básicos: interfaces standard para serviços; Interoperabilidade através dos protocolos GIOP e IIOP .

A figura 9 mostra uma possível arquitectura de aplicação CORBA, neste caso concreto usando sockets.



Fig. 9 – Arquitectura de aplicação CORBA [Chung-1997] As principais vantagens do CORBA são as seguintes:

Grande suporte para computação heterogénea (vendedores , sistemas operativos e linguagens de programação);

Modelo de programação simples ; Suporte para herança de múltiplas interfaces ; Interoperabilidade comprovada ; Especificação de serviços úteis:

Directório Eventos Persistência Transacções Concorrência Segurança Etc.

Relativamente à programação considerando CORBA devemos considerar o seguinte:

Definir uma interface usando IDL Gerar código stub/skeleton Derivar e implementar servidor Cliente liga-se ao objecto remoto e invoca os métodos



7.5 – Tecnologia RMI

As principais características do RMI são as seguintes:

Invocação remota de métodos para objectos Java ; Standard a partir da versão 1.1 ; Não é suportado por todas as licenças de Java (construtores de JVM); Serviços standard à semelhança do CORBA estão para aparecer; Utilizado para comunicação entre applets; Suporta callbacks dos servidores para applets; Preserva a segurança fornecida pelo ambiente Java.

A figura 10 mostra uma arquitectura de aplicação RMI.

Fig. 10 – Arquitectura de aplicação RMI [Alho-1998] As principais vantagens do RMI são as seguintes: Uma única linguagem ; Integração "suave" com Java ; Grátis; Modelo de programação simples ; Execução multi-plataforma; Múltiplas interfaces por objecto ; Mobilidade de código (o cliente pode transmitir código para executar no servidor).



Relativamente à programação considerando RMI devemos considerar o seguinte:

Definir interface em Java (estendendo a interface genérica java.rmi.Remote) ; Implementar objecto ; Estender java.rmi.server.RemoteObject ; implementar todos os métodos da interface ; instalar gestor de segurança ; criar uma ou mais instâncias do objecto ; registar o objecto remoto ; implementar cliente ; obter referência do objecto ; Compilar ; Gerar código stubs/skeletons.

De acordo com [Alho-1998] as arquitecturas CORBA, DCOM e RMI são arquitecturas muito similares. A adopção do CORBA por parte dos vendedores tem sido muito lenta. Existem áreas e mercados fortes para cada uma das tecnologias. O mercado forte do CORBA está ao nível empresarial, o DCOM tem como mercado forte o nível desktop e o RMI tem como mercado forte as aplicações sobre a Internet.



8 – Serviços de Suporte a Agentes e Sistemas Multi-Agente Uma infraestrutura de suporte a Agentes e Sistemas Multi-Agente deve disponibilizar um conjunto de serviços que libertem o utilizador de ter que construir todo o sistema de raiz, podendo concentrar-se na modelação, projecto e implementação dos agentes. Nesta secção iremos apresentar os principais tipos de serviços de suporte, que podem ser classificados da seguinte maneira:

• Comunicações; • Segurança; • Directório ou Informações; • Conversação.

O que será referido nesta secção terá como fonte a referência [Silva-1998]. 8.1 –Comunicações Nesta secção vamos discutir aspectos básicos como a troca de mensagens, o sincronismo, o Pooling e Encaminhamento. 8.1.1 – Troca de Mensagens Um aspecto básico de comunicação em Sistemas Multi-Agente corresponde à troca de mensagens. De seguida iremos dar uma noção dos principais mecanismos de troca de mensagens. 8.1.1.1 – Troca de Mensagens Ponto-a-Ponto A Comunicação Ponto-a Ponto corresponde a troca de mensagens bilaterais, a mensagem é enviada por um agente e recebida por outro e mais nenhum agente tem conhecimento que a comunicação se efectuou. No âmbito de um sistema multi-agente este tipo de comunicação aparece quando o agente sabe a quem se deve dirigir para pedir/fornecer uma dada informação.



8.1.1.2 – Troca de Mensagens em Grupo Neste caso há um agente emissor e um grupo de agentes destinatários que irão receber a mensagem. Este método também é conhecido como multi-cast. No âmbito de um sistema multi-agente este tipo de comunicação aparece quando o agente dispõe de um grupo de agentes aos quais se pode dirigir para pedir/fornecer uma dada informação. 8.1.1.3 – Troca de Mensagens em Broadcast O Broadcast corresponde ao envio não direccionado de mensagens. Todos os membros da comunidade vão ter a possibilidade de receber a mensagem enviada. Por norma este serviço não é garantido, ou seja, não há a garantia que todos os potenciais destinatários recebam a mensagem. Em sistemas multi-agente as mensagens em Broadcast ocorrem quando um agente não sabe a que outros agentes da comunidade faz sentido pedir/fornecer uma dada informação. 8.1.1.4 –Blackboard O conceito de Blackboard é bastante diferente da Troca de Mensagens convencional. Normalmente, ao invés de se usarem filas de mensagens e sockets, opta-se pelo uso de uma zona de memória partilhada. Todos os agentes têm acesso a essa zona de memória partilhada e é através dela que se comunicam. O Blackboard (quadro negro) é o local onde os agentes “afixam” os pedidos e as respostas. Qualquer agente pode aceitar pedidos que tenham sido efectuados ou usar respostas, ou informação, que tenha sido disponibilizada. A implementação será simples para o caso de agentes residentes no mesmo recurso computacional, que vêm a mesma zona de memória, e mais complicada para agentes residentes em diversos recursos computacionais, embora possa ser implementada por um servidor que efectue o encapsulamento do Blackboard. 8.1.2 – Sincronismo Há dois tipos de comunicação no que se refere à espera por uma resposta: a comunicação síncrona e a comunicação assíncrona.



8.1.2.1 – Comunicação Síncrona Entende-se por comunicação síncrona a forma de transacção de mensagens em que o receptor espera a recepção de mensagens num determinado momento. Dito de outro modo, o receptor pára o seu processamento de modo a aguardar a chegada de uma mensagem, a qual poderá chegar imediatamente ou demorar muito tempo. Para além das considerações de eficiência, na medida em que o agente fica a espera de algo e não realiza trabalho útil, ocupando recursos computacionais, devemos considerar que há a possibilidade da mensagem esperada não chegar (porque nenhum outro agente teve capacidade de enviar resultados para o pedido efectuado, porque houve falha nas comunicações, etc). Se tal acontecer o agente ficará bloqueado indefinidamente, o que certamente não é aconselhável. 8.1.2.2 – Comunicação Assíncrona Na comunicação assíncrona, as capacidades de comunicação e processamento são independentes, ou seja, o processamento não deverá afectar a recepção de mensagens e quando chega a mensagem o agente deverá ser notificado e a mensagem armazenada. As mensagens recebidas deverão ser colocadas numa fila para serem posteriormente processadas. Adicionalmente, o sistema de comunicação poderá, por si só, detectar o tipo de mensagem e disparar automaticamenteas as funções de processamento correspondentes. A utilidade deste tipo de processamento tem a ver com a incerteza dos processos. Não se sabe o momento em que um agente irá enviar uma mensagem para outro agente (por exemplo um agente cliente que faz uma encomenda a um agente vendedor). 8.1.3 – Pooling Infelizmente, a fiabilidade das comunicações nem sempre é a desejável. Por diversas razões podem ocorrer falhas. Como estas são prováveis é também desejável que os sistemas multi-agente passem a ser dotados de mecanismos que permitam alguma tolerância a falhas. É nesse sentido que aparece o serviço de pooling. Quando um agente fica inactivo por uma razão não prevista, o sistema de pooling irá permitir o armazenamento de mensagens e outra informação relevante que pudessem interessar ao agente em causa, essa informação será passada para o agente logo que seja possível o seu restabelecimento. Desse modo passamos a dispor de alguma capacidade de reposição. 8.1.4 – Encaminhamento Pelas mais diversas razões nem sempre é possível que um agente tenha a facilidade de comunicar directamente com qualquer outro agente da comunidade. Nessas situações deverá ser disponibilizado um serviço de encaminhamento, algo similar a um correio, que recebe a



informação do agente que pretende enviar e a indicação do destinatário e faz com que a informação pretendida chegue ao destinatário especificado. 8.2 –Segurança O requisito segurança coloca-se em qualquer sistema, nomeadamente nos Sistemas Distribuídos, pois não existe uma entidade única centralizada e responsável pela manutenção da consistência, objectividade e validade das intenções das partes que constituem o sistema. Trata-se de um sistema estrutural e organizacionalmente dinâmico, constituído por entidades distribuídas, autónomas e que se pretendem colectivamente responsáveis pelos objectivos globais. A segurança de um sistema é igual ao menor parâmetro de segurança de todos os constituintes do sistema. Por essa razão a segurança deve ser vista no sistema como um “todo”. Deveremos ter preocupações ao nível das comunicações e da informação. No âmbito de uma comunidade multi-agente o primeiro problema que se põe resulta do facto de alguém, através de um agente, tentar registar-se e ter acesso à comunidade indevidamente. Uma primeira validação poderá ser feita através da identificação usando um nome e uma palavra-chave, como em qualquer serviço convencional. Relativamente à informação que flui no sistema, poder-se-á adoptar alguma norma segura de encriptação dessa mesma informação. 8.2.1 – Serviço de Nomes Um Sistema Multi-Agente é constituído por entidades distribuídas e autónomas, onde a consistência e objectividade do sistema é muitas vezes posta em causa, devido aos diferentes objectivos e heterogeneidade dos agentes. Ou seja, o sistema é altamente dependente das intenções de cada entidade, da forma como se comporta socialmente e como cumpre um conjunto mínimo de protocolos. Sob um ponto de vista de comunicações, será necessário que antes de qualquer sociabilização, a entidade seja alvo de verificações mínimas. Uma possibilidade é a imposição da necessidade do registo do agente no sistema, através da validação do par (Identificação, Palavra Chave). Desse modo cada agente deverá fornecer a sua identificação e palavra chave ao serviço de nomes, que em função do resultado da autenticação irá aceitar ou não a participação do agente requerente à comunidade.



8.2.2 – Serviço de Encriptação de Mensagens Por vezes a informação que circula na rede, que pode ter sido enviada ou ser dirigida a agentes, corresponde a informação crítica (informações classificadas, números de cartões de crédito, transacções efectuadas, palavras-chave, etc). O serviço de encriptação de mensagens permite dar mais alguma segurança à informação que circula entre os agentes de uma comunidade. 8.2.3 – Serviço de Permissões Apesar de um agente pertencer a uma comunidade multi-agente, tal não implica que o agente tenha liberdade para fazer tudo aquilo que pretenda. Por exemplo, pode ser vedado a um agente o acesso a certos tipos de informação, o uso de certos tipos de recursos, a requisição de certos tipos de tarefas. É o serviço de permissões que irá definir “quem tem acesso a que”. É costume dividir os agentes em grupos e darem-se privilégios de acesso por grupos, de um modo similar ao que acontece com os utilizadores em sistemas operativos. 8.3 – Directórios e Informações O Serviço de Directórios, ou de Informações, é um serviço que informa um dado agente sobre quais os agentes que são capazes de realizar uma dada tarefa e o modo como tais agentes poderão ser acedidos. Essa informação poderia residir no próprio agente, mas tal seria uma solução que não facilitaria o dinamismo do sistema. Por exemplo, podemos ter passado a ter mais um novo agente na comunidade com uma determinada capacidade, basta que este se registe no Serviço de Directórios para que passe a ficar disponível para todos os outros agentes da comunidade. Podemos estabelecer alguma analogia entre o serviço de directórios e as Páginas Amarelas das companhias telefónicas, ou as YP (Yellow Pages) existentes em sistemas computacionais e operativos, ou o NIS (Network Information Service), ou ainda o NetBI e o X.500. O serviço de Directórios ou de Informações poderá assumir uma das duas seguintes formas:

• Facilitação (Facilitator); • Descoberta (Broker).

O serviço de facilitação é responsável pela publicação e distribuição da informação de “quem é capaz de fazer o que” e como encontrar tal ou tais agentes. O serviço de descoberta é diferente, indo a procura da informação quando esta é requerida, recorrendo a outros serviços de informação, ou interrogando agentes sobre as suas capacidades.



8.4 – Conversações Uma conversação é um conjunto ordenado, não necessariamente sequencial, de mensagens transmitidas entre dois ou mais agentes, que fazem sentido e são compreendidas mutuamente pelos intervenientes. A conversação sistematiza e define as ocorrências e tipos de mensagens de forma que o conjunto de mensagens possíveis num determinado momento da conversação seja limitado, mutuamente conhecido e correctamente utilizado. O tipo de conversação varia desde a simples troca de valores numéricos de controlo até negociações complexas e sujeitas a alguma incerteza, com múltiplas interacções e intervenientes, envolvendo conhecimento complexo. As necessidades actuais dos sistemas situam-se entre estes dois extremos. A conversação requer controlo e acompanhamento. De seguida indicam-se alguns mecanismos utilizados. 8.4.1 – Mecanismo de Time-out Um agente não poderá estar indefinidamente a espera da resposta de outro agente. O intervalo de tempo que deve ser esperado, aguardando a resposta de outro agente, é denominado de time-out. No entanto, o tempo de espera deve ser dependente do estado da conversação e dos seus intervenientes, razão pela qual não se englobou este mecanismo na componente de comunicações. 8.4.2 – Gestão da Informação da Conversação É necessário que exista armazenamento de informação associada à conversação. O estado da conversação, os intervenientes e valores de mensagens anteriores são elementos comuns em qualquer conversação, fazendo todo o sentido serem geridos pelo processo inerente à conversação e não à aplicação. 8.4.3 – Sincronização Entende-se por sincronização da conversação, as actividades de controlo da conversação que gerem o momento e a ordem de processamento das mensagens. Uma determinada conversação é composta por um conjunto de mensagens ordenadas, mas o facto dessa ordem não ser cumprida não é forçosamente sinónimo de erro fatal e motivo para que a conversação seja abortada. Podem ocorrer situações em que a chegada de mensagens ocorra antes do previsto pela conversação, contudo, se forem armazenadas e disponibilizadas para o uso no momento correcto, a conversação poderá continuar sem desvios.



9 – Negociação entre Agentes Tal como na negociação entre seres humanos, os Agentes deverão ser capazes de comunicar entre si e exibirem algumas capacidades sociais para que se estabeleça uma negociação. Definem-se protocolos de negociação entre agentes para reger o desenvolvimento do processo de negociação. Os tipos de negociação mais usuais são: • 1 potencial contratante para 1 potencial contratado; • 1 potencial contratante para N potenciais contratados; • N potenciais contratantes para 1 potencial contratado; • N potenciais contratantes para M potenciais contratados. Iremos, de seguida, detalhar melhor os três primeiros tipos de negociação, visto que o quarto pode ser obtido pela multiplicação do segundo ou terceiro casos. 9.1 – Negociação de 1 para 1 Podemos associar o caso do Cliente-Servidor como um caso particular deste tipo de negociação. A diferença reside no facto do potencial contratado, ao contrário do servidor, poder recusar-se a executar as tarefas que são pedidas. O protocolo começa com o anúncio (figura 11) por parte do potencial contratante (Ag) dirigido ao potencial contratado (Ag1).

Ag Ag1anúncio

Fig. 11 – Anúncio de Ag para Ag1



Ag1 analisa a intenção do anúncio de Ag e responde enviando uma proposta ou manifestando a impossibilidade de executar a tarefa pedida (figura 12).

proposta / impossibilidadeAg Ag1

Fig. 12 – Resposta de Ag1 a Ag No caso de impossibilidade Ag não pode contar com a execução da tarefa pretendida. Note-se que Ag deve ser suficientemente autónomo para saber lidar com tal situação, não devendo pura e simplesmente bloquear. Caso não haja impossibilidade, Ag analisa a proposta e procede à aceitação de Ag1 para executar a tarefa ou rejeita a proposta (figura 13). Tal depende do conteúdo dessa mesma proposta.

Ag Ag1aceitação / rejeição

Fig. 13 – Finalização da negociação entre Ag e Ag1 O processo pode ser mais complexo e exigir mais interacção entre Ag e Ag1, por exemplo Ag impor um preço mínimo e prazo de entrega e Ag1 tentar convencer Ag para uma solução que garanta o preço mas não o prazo, ou o contrário. Note-se que os Agentes devem estar providos de mecanismos tolerantes à falhas, nomeadamente no que se refere às comunicações, visto que qualquer das mensagens pode não chegar ao destinatário pelas mais diversas razões, novamente a questão da autonomia dos agentes aparece como uma questão vital. 9.2 – Negociação de 1 para n Vários protocolos de negociação de 1 contratante para n potenciais contratados têm sido propostos, geralmente baseados no “Contract Net Protocol” [Davis-1983]. Vamos considerar um Agente Ag que pretende ver satisfeita uma tarefa que pode ser realizada por Ag1, Ag2 e Ag3 (potenciais contratados). O processo começa com o anúncio feito por Ag e dirigido para Ag1, Ag2 e Ag3 (figura 14).



Ag Ag1anúncio

Ag2

Ag3

anúncio

anúncio

Fig. 14 – Anúncio de Ag para Ag1, Ag2 e Ag3 O anúncio dirigido implica que o Agente Ag saiba quem é capaz de fazer uma dada tarefa (metaconhecimento sobre as capacidades dos outros agentes da comunidade). Haveria outras alternativas, como, por exemplo, pedir essa informação a um agente informador, efectuar o “broadcast”, usar uma zona de memória partilhada para efectuar os anúncios (blackboard). Os agentes Ag1, Ag2 e Ag3 analisam o anúncio e respondem, enviando propostas ou indicando a impossibilidade em executar a tarefa ou simplesmente não respondendo (figura 15).

Ag Ag1

Ag2

Ag3

proposta / impossibilidade



Fig. 15 – Respostas de Ag1, Ag2 e Ag3 para Ag



O Agente Ag analisa as propostas que chegam e selecciona a melhor, se entender que alguma é viável, podendo ainda informar os agentes não seleccionados acerca da rejeição das respectivas propostas (figura 16).

Ag Ag1aceitação / rejeição

Ag2

Ag3

aceitação / rejeição

aceitação / rejeição

Fig. 16 – Finalização da negociação entre os agentes Quando as mensagens de impossibilidade ou de rejeição não são obrigatórias, é necessário que os agentes tenham isso em consideração no próprio protocolo, caso contrário o Agente corre o risco de ficar a espera de um evento que nunca ocorrerá. Mesmo quando as mensagens são obrigatórias podemos admitir que, por dificuldades associadas ao processo de comunicação, as mensagens podem não chegar, ou seja, o Agente deve ser concebido de modo a ser mais tolerante a falhas (uma solução é o mecanismo de timeout). Considere o seguinte problema: O Agente Ag pretende ver satisfeitas 3 tarefas (T1, T2 e T3) envolvendo as seguintes restrições: T1 deve preceder T2 T2 deve preceder T3 T3 deve estar concluído antes do instante 10 (10 unidades de tempo) As tarefas podem ser executadas pelos agentes que se seguem: T1 pode ser executada por Ag1 ou Ag3, a sua duração é de 2 unidades de tempo T2 pode ser executada por Ag2 ou Ag3, a sua duração é de 2 unidades de tempo T3 pode ser executada por Ag3 ou Ag4. A sua duração é de 3 unidades de tempo



As agendas de ocupação dessas agentes são as seguintes (em intervalos de unidades de tempo (t_in,t_fim)): Ag1: [(1,2)] Ag2: [(3,4)] Ag3: [(1,3),(5,8)] Ag4: [(4,5),(9,10)] Pretende-se uma possível sequência de negociação com vista a que Ag consiga escalonar as tarefas nos agentes que as podem executar. O problema enunciado envolve a necessidade de várias negociações de 1 para n, neste caso 3, ou seja, uma negociação por cada tarefa (T1, T2 e T3). Acresce a isso o facto dessas negociações serem dependentes entre si. Por exemplo, o agente Ag3 pode executar as tarefas T1 e T2, pode suceder que Ag3 fique com ambas as tarefas atribuídas, ou seja, ao negociar T2 haverá uma influência da negociação de T1. Isso cria alguns problemas na negociação simultânea de tarefas. Para resolver o problema vamos considerar que temos 3 protocolos de 1 para n, associados a T1, T2 e T3. Só iremos lançar a negociação de T2 quando a de T1 estiver terminada, de igual modo só iremos lançar a negociação de T3 quando a de T2 estiver terminada. Na negociação de T1 o agente Ag contacta os potenciais contratados, Ag1 e Ag3, pedindo que estes executem a Tarefa T1, por outro lado, se Ag sabe que as tarefas demoram ao todo 7 unidades de tempo (2 para T1, 2 para T2 e 3 para T3) então o prazo de conclusão de T1 não poderá ultrapassar o instante 5 (10-2-3), visto que o prazo de conclusão de todas as tarefas é de 10 unidades de tempo e as tarefas que se seguem têm a duração de 2 e 3 unidades de tempo, respectivamente. Note-se que pode não ser possível que Ag saiba a duração dessas tarefas, seria mais natural que fossem os Agentes Ag1, Ag2 e Ag3 a sabê-lo. Note-se, ainda, que certas tarefas podem ter uma duração que não se possa conhecer exactamente à priori, embora seja natural que se trabalhe com estimativas. Atendendo as agendas dos agentes Ag1 e Ag3, ambos respondem a Ag indicando que podem fazer a tarefa T1. Os intervalos possíveis para Ag1 e Ag3 são:

(2,4) para Ag1 (3,5) para Ag3.

Sendo assim, Ag tem que efectuar uma escolha, é natural que opte por Ag1, visto que este começa mais cedo. Mas a escolha poderia ser diferente se se optasse por uma filosofia JIT (Just in Time) ou se estivessem custos envolvidos e Ag1 tivesse custos superiores. Agora inicia-se a negociação de T2. O prazo de conclusão é de 7 (10-3) e os potenciais contratados são Ag2 e Ag3. Note-se ainda que não vale a pena começar antes do instante 4 (que corresponde ao final de T1), admitindo, ainda, que não há tempos de espera mínimos entre o fim de T1 e o início de T2. Fica, portanto, definida uma janela de oportunidade de execução de T2 no intervalo (4,7).



Atendendo às agendas apenas o agente Ag2 pode executar a tarefa no seguinte intervalo:

(4,6) para Ag2. Finalmente, segue-se a negociação de T3. A janela de oportunidade de execução dessa tarefa situa-se entre 6 (fim de T2) e 10 (prazo final). Os potenciais contratados são Ag3 e Ag4. Aqui, também, apenas o agente Ag4 é capaz de executar a tarefa com as restrições impostas, no seguinte intervalo:

(6,9) para Ag4. Fica, assim, concluída com sucesso a negociação. Note-se que poderia dar-se o caso de para cumprir todos os prazos haver a necessidade de retrocesso (backtracking) na negociação. Poderia até dar-se a situação de não haver solução possível para o problema que atendesse todas as restrições. Nesse caso poderíamos tentar relaxar algumas restrições. 9.3 – Negociação de n para 1 Não se trata de um tipo especial de contratação, resulta de vários processos de contratação idênticos aos anteriores, mas agora centrados no ponto de vista do contratado, ou seja, o potencial contratado tem que lidar ao mesmo tempo com a negociação de diversos contratos. Vamos considerar um exemplo em que 3 agentes (Ag1, Ag2 e Ag3) pretendem, todos e independentemente, estabelecer um contrato com Ag. Ag recebe 3 anúncios (figura 17).

Ag Ag1anúncio

Ag2

Ag3

anúncio

anúncio

Fig. 17 – Anúncios de Ag1, Ag2 e Ag3 para Ag



A questão que se põe ao potencial contratado (Ag) é a de como poderá comprometer-se com as propostas que envia se não tem a certeza destas serem aceites pelos destinatários. Note-se que Ag1, Ag2 e Ag3 podem rejeitar a proposta ou estar a negociar essa proposta simultaneamente com outros agentes. Vamos procurar ilustrar o problema com um exemplo: Considere que Ag recebe:

Um anúncio de Ag1 para executar uma tarefa T1 com duração de 3 unidades de tempo e com prazo até a unidade de tempo 4 Um anúncio de Ag2 para executar uma tarefa T2 com duração de 4 unidades de tempo e com prazo até a unidade de tempo 6 Um anúncio de Ag3 para executar uma tarefa T3 com duração de 2 unidades de tempo e com prazo até a unidade de tempo 5.

A agenda de Ag está completamente livre. Indique que propostas é que Ag deve enviar aos agentes Ag1, Ag2 e Ag3? Note-se que Ag consegue executar individualmente qualquer uma das três solicitações. Pode cumprir T1 ou T2 ou T3. Uma análise simples permitiria concluir que ainda seria possível ao agente Ag cumprir os pares T1-T3 ou T3-T2. Sendo assim o agente poderia concluir que em qualquer caso consegue cumprir T3 e que irá ter que se decidir entre T1 ou T2. Admita-se que opta por T2 por ser mais demorada e potencialmente mais rentável. Logo Ag responde a Ag2 e Ag3 indicando uma aceitação e proposta e rejeita a tarefa de Ag1. Mas pode acontecer que Ag2 e Ag3 optem por outro agente para executar T2 e T3 e que Ag1 até nem tenha nenhuma outra alternativa para T1. Nesse caso Ag teria sido infeliz na escolha, o que também não teria sido positivo para Ag1. Claro que Ag poderia ter sido menos “honesto” e aceitado todas as possibilidades, o que traria problemas se todos o escolhessem. Estamos claramente na presença de um Problema da Indecisão, que se pode enunciar do seguinte modo: Quando um agente está sujeito à negociação de vários contratos ao mesmo tempo nunca sabe se as propostas que envia serão aceites ou recusadas, o que condiciona o comportamento que terá. Um agente optimista e cumpridor admite que a proposta que envia será aceite e em negociações que ocorram posteriormente vai admitir que aquilo que foi em propostas anteriores é para ser considerado como indisponível (tempo ocupado, material ou serviços, etc). Esse agente vai tender a demonstrar-se indisponível para outras negociações. O risco que corre é o facto das propostas que envia serem rejeitadas, tendo perdido oportunidades de “negócio” devido a ter-se considerado indevidamente indisponível para outras negociações. Um agente pessimista e não cumpridor admite que não há garantia em que as suas propostas sejam aceites, logo em negociações futuras considera que aquilo que foi comprometido em propostas anteriores está livre pois os contratantes ainda não confirmaram a aceitação das



propostas. Esse agente aproveita melhor os negócios mas corre o risco de cair no descrédito pelo facto dos outros agentes começarem a não dar credibilidade as suas propostas (se estes tiverem aprendizagem!). Algumas alternativas para lidar com o problema:

• Efectuar as negociações uma a uma até ao final, ou seja, só após a aceitação ou rejeição é que se passa à proposta seguinte (será praticável no mundo real?);

• Incluir mais passos no protocolo de negociação, indicando que as propostas necessitam

ainda de uma reconfirmação após a selecção; • Avaliar a importância dos potenciais contratos em função dos clientes (contratantes),

usar heurísticas; • Avaliar o impacto do não cumprimento dos contratos (multas); • Tentar subcontratar outros agentes para o trabalho em sobrecarga; • Tentar renegociar contratos já assumidos.

Observe-se o grande conjunto de características que se podem associar ao carácter do agente (cumpridor ou não cumpridor, optimista ou pessimista, etc). Observe-se, ainda, toda a quantidade de “inteligência” e conhecimento que se deve pôr do lado do contratado para lidar com este tipo de problemas. Finalmente, note-se que características como a aprendizagem são importantes para que os potenciais contratantes não vejam sucessivamente defraudadas as suas expectativas. 9.4 – Renegociação A renegociação pode ser vista como um novo processo de negociação que se inicia devido a uma negociação estabelecida previamente ter sido rompida. Imagine-se que no exemplo da secção 9.2, que era uma negociação de 1 para n, o agente Ag selecciona o agente Ag1 para cumprir o contrato e que Ag2 e Ag3 recebem mensagens de rejeição. Vamos agora admitir que o agente Ag1 falha e que Ag toma consciência desse facto. O Agente Ag poderá retomar o processo de negociação com Ag2 e Ag3, enviando novos anúncios e repetindo-se o processo de negociação de 1 para n, descrito anteriormente, mas agora envolvendo apenas Ag2 e Ag3.



10 – Leilões Um tipo de negociação que se utiliza com frequência corresponde aos leilões. É comum a realização de leilões para venda de obras de arte, atingindo tais obras valores não previstos inicialmente. Os leilões podem ser usados para venda de itens individuais, tais como obras de arte, ou para venda de várias unidades de um item, tal como Títulos do Tesouro. Os leilões são úteis em circunstâncias em que os bens não têm um valor de mercado fixo ou pré-determinado, ou, por outras palavras, quando o vendedor não tem a certeza do preço que pode conseguir. Os leilões são úteis em países que estão a adoptar uma economia de mercado, uma vez que possibilitam a avaliação de bens cujo valor não se consegue estimar com certeza. Vender uma mercadoria em leilão é mais fléxivel que estabelecer-lhe previamente um preço é menos demorado e dispendioso que negociar um preço. Ao negociar um preço, cada proposta ou contra-proposta é considerada separadamente, num leilão as propostas concorrentes são feitas quase simultaneamente. Um leilão é um método de atribuição de bens, um método que é baseado em competição. É o mais puro dos mercados: um vendedor pretende obter o maior lucro possível e o comprador pretende pagar o menos possível. Um leilão oferece uma forma simples de estabelecer o preço com base no mercado. É eficiente no sentido em que um leilão normalmente assegura que os recursos ficam para quem os valoriza mais e assegura que os vendedores recebem o valor de avaliação do item. Uma característica particular é que o preço não é imposto pelos vendedores, mas pelos licitantes. No entanto, é o vendedor quem define as regras ao escolher o tipo de leilão a ser usado. Outra particularidade, em relação a outros métodos, é o facto de o leiloeiro normalmente não ficar com os bens, mas actuar como agente para alguém que o vai comprar. Frequentemente os compradores sabem mais sobre o valor do produto do que os próprios vendedores. Os vendedores, não querendo sugerir previamente um preço com medo que a sua ignorância saia cara, promovem muitas vezes um leilão de forma a obter informação que doutro modo seria difícil de conseguir. Existem diferentes modos de classificar os leilões. Existem leilões abertos e de propostas secretas. Existem leilões em que o preço vai subindo, e leilões em que o preço desce em intervalos regulares. Existem leilões unilaterias e bilaterias. Leilões unilaterais são aqueles em que apenas são feitas propostas de negócio por parte dos compradores, e em que os vendedores aceitam os negócios mas não podem fazer ofertas. Os leilões unilaterais podem também ser de ofertas, no caso de serem os vendedores a fazer as propostas. Este tipo de leilões tende a favorecer as entidades silenciosas, compradores (vendedores) esperam até que as propostas (ofertas) estejam abaixo (acima) do preço de equilíbrio competitivo. Nos leilões bilaterais vários vendedores e compradores submetem as suas ofertas e licitações.



Uma observação importante diz respeito ao tipo de motivações que leva à participação em leilões. Um dos motivos é a aquisição de bens para consumo pessoal. Neste caso o objecto de leilão tem um valor que é privado a cada licitante. Outra das motivações é adquirir bens para revenda ou uso comercial. Neste caso o valor da proposta depende não só da avaliação privada mas da futura avaliação dos próximos compradores. Cada licitante deste tipo tenta estimar qual irá ser o preço final do produto. O comportamento das pessoas varia consoante o tipo de motivação que têm. William Vickrey [Agorics - URL] estabeleceu a taxonomia básica de leilões com base no modo como os preços são cotados e na maneira como as licitações são tratadas. Foram estabelecidos quatro tipos normalizados de leilões unilaterias, são eles o Leilão Inglês (English auction), o Leilão Holandês (Dutch auction), o Leilão do Preço da Primera Proposta Secreta Aceite (First price sealed-bid auction) e o Leilão da Segunda Proposta Secreta (Second price sealed-bid auction). O quadro II mostra as regras básicas e o estabelecimento de preços nos 4 tipos básicos de leilões que foram citados. Quadro II – Regras e estabelecimento de preços em leilões

Tipo Leilão Regras Preço do negócio Inglês (aberto oral, ascendente)

Vendedor anuncia preço de reserva. Licitações sobem até que ninguém faça mais licitações. Licitantes podem fazer novas avaliações.

Valor da licitação mais elevada.

Holandês Vendedor anuncia preço elevado. Preço desce até que alguém aceite o negócio.

Valor da melhor proposta.

Primeira Proposta Secreta Aceite

Licitantes submetem propostas secretas, sem conhecimento das outras propostas. O vencedor paga a quantia que propôs.

Preço da melhor proposta, mais elevado.

Segunda Proposta Secreta

Licitantes submetem propostas secretas. Vencedor é o que fez melhor proposta, mas paga a quantia estabelecida na segunda melhor proposta. Note-se que o comportamento dos licitantes é diferente do caso anterior.

Preço da Segunda melhor proposta.

Sendo um tipo de negociação que é usado com frequência, também os agentes podem usar os leilões nas suas negociações, havendo agentes vendedores (licitadores) e agentes compradores (licitantes). Note-se que estes agentes deverão ser dotados de uma inteligência e astúcia consideráveis. A abertura de alguns mercados que eram monopolizados, como o caso do Mercado da Electricidade, pode ser implementada através do funcionamento em leilão (produtores e compradores de energia eléctrica), fazendo todo o sentido a existência de agentes que



representem tais empresas. Também na Internet/Web há muitos artigos que são vendidos em leilões (por exemplo, viagens) e a presença de agentes torna-se evidente. Uma melhor descrição sobre os vários modelos de leilões pode ser encontrada na referência [Praça-2001], onde se baseou a presente secção.



11 – Conflitos Tal como numa sociedade convencional, a ocorrência de conflitos pode aparecer num Sistema Multi-Agente. Já anteriormente descrevemos os principais tipos de conflitos que são os seguintes: • Conflitos de Objectivos – os agentes não têm objectivos idênticos, podendo até ser

contraditórios • Conflitos de Responsabilidade ou de Interesses – há vários agentes que querem assumir a

responsabilidade por uma dada tarefa ou cumprir um mesmo objectivo • Conflitos de Informação e Conhecimento – vários agentes têm leituras diferentes para uma

dada situação ou realidade. O primeiro exemplo, conflito de objectivos, ocorre quando dois ou mais agentes vêm um problema segundo perspectivas diferentes, que no limite podem ser contraditórias. Vamos considerar um exemplo no qual a compra de um equipamento informático será efectuada com base nos pareceres de dois agentes: um efectua uma avaliação económica e outro efectua uma avaliação técnica. Os agentes recebem propostas de equipamento informático e emitem um parecer sobre o equipamento que deverá ser adquirido. São definidas plataformas mínimas (processador, quantidade de memória, monitor, quantidade de disco, placa de rede, placa gráfica, etc) e um orçamento máximo para o efeito. O agente que efectue a avaliação económica terá a tendência em optar pelo computador que atendendo as especificações mínimas ofereça o preço mais reduzido. O agente que efectue a avaliação técnica terá a tendência para optar pelo computador que tenha melhores características e que não ultrapasse o orçamento máximo (por exemplo, prefere memória RDRAM ao invés de SDRAM). Há um conflito devido ao facto dos objectivos não serem idênticos (económico versus técnico). Claro que os agentes ganhariam bastante se tivessem poder de argumentação das soluções que encontram e se pudessem estabelecer um diálogo com os potenciais fornecedores (convencendo-os a baixar preços ou a melhorar as características). Os agentes devem ser dotados de capacidades de estabelecimento de compromissos de modo a que possam assegurar que parte daquilo que pretendem é obtido. Apesar dos objectivos serem diferentes não podemos dizer que são contraditórios. Uma situação diferente seria a de termos políticas diferentes que pudessem ser seguidas e termos que optar exclusivamente por uma ou pela outra. Por exemplo, um avião guiado autonomamente parte de um aeroporto e tem uma missão que visa efectuar vigilância numa determinada área na qual há nas proximidades outro aeroporto onde pode pousar. Admita-se que as condições climatéricas junto à area que se pretende investigar não são as melhores. Num determinado momento há que fazer a escolha entre voltar para o aeroporto de origem, por restrições de combustível, ou avançar correndo o risco, visto que a partir desse ponto já não haverá combustível suficiente para voltar para trás. Se considerarmos dois agentes: um que tenha como



objectivo que as missões sejam efectuadas o mais rapidamente possível e outro que se preocupe com questões de segurança do avião, chegaremos a uma situação na qual estes dois agentes podem chegar a um conflito de objectivos que não possa ser ultrapassado. Há que optar por um ou pelo outro. Nesta situação o sistema deve ser dotado de um esquema de prioridades que permita optar pela sugestão do agente mais prioritário, em casos onde não há possibilidade de consenso. Nos conflitos de responsabilidade ou de interesses, os objectivos individuais dos agentes podem até ser os mesmos, mas como geralmente concorrem por um mesmo bem único e indivisível, não será possível atender a mais do que um pretendente. O exemplo típico corresponde à compra de um bem único num leilão, os agentes concorrentes até têm o mesmo objectivo, mas nunca irão cooperar para o efeito, visto que só um poderá ver o objectivo cumprido. Outro exemplo surge no caso de várias empresas que vendem o mesmo tipo de produtos. Aqui para lidar com a situação os agentes devem prever o que os seus concorrentes irão efectuar, ou até espiá-los. Por exemplo, um agente, antes de definir os seus preços pode consultar os preços dos agentes concorrentes. Finalmente temos o caso dos conflitos em dados, informação e conhecimento. Vários agentes fornecem-nos diversas leituras diferentes para uma mesma realidade. Por exemplo, os sistemas de identificação de objectos VISION e LASER, descritos na secção 6.2 e que aparecem na figura 5, podem entender que numa dada posição encontram-se objectos diferentes. Essa situação pode ser resolvida definindo níveis de credibilidade que temos nos agentes relativamente ao fornecimento dos dados/informação/conhecimento pretendidos. Pode também existir a capacidade de efectuar fusão dos dados/informação/conhecimento, tentando-se aproveitar parte dos resultados de um lado e parte de outro. Para o efeito é necessário definir os itens de dados/informação/conhecimento e verificar se os vários agentes fornecem tais itens. Se apenas um fornecer um determinado item então teremos que aceitar a veracidade do mesmo. Se vários agentes forem concordantes num determinado item então a credibilidade da ocorrência do mesmo virá aumentada. Se houver itens contraditórios então teremos que verificar a credibilidade de cada um dos agentes no fornecimento do respectivo item. O processo poderá ser ainda mais elaborado se para além da credibilidade que temos nos agentes estes indicarem factores de certeza nas suas conclusões (por exemplo, um agente no qual acreditamos mais só tem 60% de certeza no item que nos apresenta enquanto que outro no qual acreditamos menos tem 90% de certeza naquilo que nos diz).



12 – Interacção entre Agentes 12.1 – Ontologias Para que 2 agentes se comuniquem e se percebam mutuamente é necessário que sejam capazes de usar uma linguagem comum ou de usar linguagens que possam ser traduzíveis uma na outra. Mas isso não basta para que os agentes possam entender-se mutuamente. É também necessário que sejam capazes de partilhar uma dada organização do conhecimento, ou seja, devem partilhar uma Ontologia. Uma Ontologia especifica um vocabulário de representação para um domínio, domínio esse do qual são utilizados termos no diálogo entre os agentes. Mas a Ontologia não é apenas o vocabulário, pois deve efectuar um tratamento a mais alto nível dos conceitos desse mesmo vocabulário, definindo classes, relações, funções, etc. O termo Ontologia gera alguma controvérsia na área de Inteligência Artificial e em outros domínios técnicos. Contudo, o termo tem sido usado desde há muitos anos no âmbito da Filosofia, sendo definido como o “tema da existência”. Por vezes há a tendência em confundir Ontologia com Epistemologia, este último conceito tem a ver com o conhecimento e com o saber. Tom Gruber define o termo Ontologia no âmbito da partilha do conhecimento com o sentido de “especificação de uma conceptualização”. Isto é, uma Ontologia é entendida como a especificação de conceitos e relações que existem para um agente ou comunidade de agentes, tal como ocorre na especificação formal de um programa computacional [Gruber-1993]. As Ontologias ganharam uma grande importância dentro das comunidades científicas relacionadas com a Gestão do Conhecimento e dos Agentes Inteligentes e Sistemas Multi-Agente. Na Gestão do Conhecimento a importância da Ontologia deriva da necessidade em efectuar a partilha e reutilização do conhecimento no âmbito de uma organização. No que se refere aos Agentes Inteligentes e aos Sistemas Multi-Agente as Ontologias são fundamentais para que vários agentes possam estabelecer uma plataforma comum sobre a qual assente a troca de conhecimento entre agentes. Caso contrário cada um interpretará os termos com o significado que bem entenderem, no limite chegaremos a Idealectos segundo os quais os agentes enfatizam perspectívas puramente próprias, o que de todo não é desejado.



Logo, é importante definir compromissos ontológicos entre agentes. Um compromisso ontológico é um acordo no sentido de um conjunto de agentes usar um vocabulátrio comum de modo a que seja consistente com a teoria especificada pela ontologia. Uma Ontologia pode ser representada por uma Base de Conhecimento estruturada hierarquicamente em classes. Contudo, não é obrigatório que a estruturação seja feita dessa maneira. Há vários critérios que devem ser considerados na concepção de uma nova ontologia, tais como:

• Clareza – uma ontologia deve descrever de um modo efectivo o significado pretendido para os termos definidos. As definições devem ser objectivas. Sempre que possível as definições devem ser completas (através de condições necessárias e suficientes) e não parciais;

• Coerência – se uma frase que pode ser inferida dos axiomas da ontologia vier a contradizer uma definição da ontologia então esta é incoerente, o que não é desejável;

• Estensibilidade – Devemos poder definir novos termos para usos especiais com base no vocabulário existente sem que tal implique a necessidade de alterar as definições;

• Codificação mínima – A conceptualização deve ser feita ao nível do conhecimento, sem envolver codificações particulares ao nível dos símbolos. Note-se que os agentes podem estar implementados com estilos ou sistemas de representação diferentes;

• Necessidade mínima de compromissos lógicos – Dado que os compromissos ontológicos se baseiam no uso consistente do vocabulário, estes compromissos podem ser minimizados usando a teoria mais fraca (que cabe em todas as teorias) e definindo apenas os temas que são essenciais para a comunicação de conhecimento consistente segundo tal teoria.

O Ontolingua é um sistema que define ontologias que são portáveis entre vários sistemas de representação. Há também outras alternativas como o KADS, Conceptual Graphs, IDEF5 e BSDM. 12.2 – Formatos de Troca de Conhecimento O KIF (Knowledge Interchange Format) define um formato através do qual se poderá dar a troca de conhecimento entre agentes. O KIF tem uma semântica declarativa, ou seja, o significado das expressões pode ser compreendido sem recorrer a um interpretador que manipule essas expressões O KIF é logicamente compreensível, é possível exprimir realidades representáveis pela lógica de 1ª ordem. O KIF pode ser visto como uma versão prefixa do cálculo de predicados de 1ª ordem, com várias extensões para enriquecer a sua expressividade. O KIF permite representar metaconhecimento.



Vejamos alguns exemplos de conteúdos de mensagens KIF:

• Notificação: (tell ( > 5 3)) • Pedido: (perform (print “Hello!” t) • Resposta: (reply available) • Pergunta: (ask-if ( > (lucro produto_1) (lucro produto_2))) • Subscrição: (subscribe (coordenadas ?x ?y ?z))

Vejamos agora alguns outros exemplos usando KIF. O exemplo que se segue mostra como se pode expressar que o salário de um determinado trabalhador identificado pelo seu número de contribuinte de um determinado departamento assume um valor especificado. (salario 123456789 contabilidade 1500) (salario 132547698 aprovisionamentos 1200) (salario 143276598 marketing 1800) Podemos, ainda, fazer a comparação e cálculos. Por exemplo, para compararmos a área de dois terrenos: (> (* (largura t1) (comprimento t1)) (* (largura t2) (comprimento t2))) Podemos expressar que a potência par de um número real qualquer é positiva do modo que se indica a seguir: (=> (and (real-number ?x) (even-number ?n)) (> (expt ?x ?n) 0)) O uso do operador ‘ e das vírgulas permite que o agente indique que está interessado em receber os três valores associados à relação do salário do seguinte modo: (interested joe ‘ (salario ,?x ,?y ,?z )) O KIF também pode ser utilizado para descrever programas ou scripts para agents. Dada a natureza prefixa da sintaxe do KIF, tais programas lembram linguagens como o Lisp ou o Scheme. Segue-se um exemplo: (progn (fresh-line t) (print “Hello”) (fresh-line t))



12.3 – Linguagens de Manipulação e Interrogação de Conhecimento O KQML (Knowledge Query and Manipulation Language) é um protocolo de troca de informação e conhecimento entre agentes e uma linguagem declarativa. Foi proposto como parte de um projecto designado Knowledge-Sharing Effort da US Defense Advanced Research Projects Agency no final dos anos 80 [Labrou-1988]. Uma mensagem KQML tem os 3 seguintes componentes:

• Conteúdo: uma expressão num formato acordado, por exemplo em KIF (Knowledge Interchange Format);

• Envolvente: exprime a lógica da comunicação, indicando a linguagem usada no

conteúdo, o tipo de expressão do conteúdo, a qualificação, etc; • Envelope de Comunicação: estabelece como se vai dar a comunicação, quem envia,

quem é o destinatário, o tipo de comunicação usada, sincronismo, etc. O KQML é indiferente ao conteúdo e formato da informação e conhecimento que manipula. O KQML é constituído por várias primitivas reservadas (“performatives”). Vejamos algumas dessas primitivas básicas:

• Informativas: tell, achieve, untell, unachieved; • Pedidos: perform; • Perguntas: ask-if, ask-one, ask-all, evaluate; • Respostas: reply, sorry; • Definição de capacidades: subscribe, monitor, advertise, unsubscribe; • Comunicações: forward, register, unregister, broadcast, route.

Uma expressão KQML completa inclui, para além da primitiva do discurso, uma lista de pares atributo-valor com elementos do seguinte tipo:

:language <linguagem> :content <conteúdo> :ontology <ontologia> :from <agente_origem>



:to <agente_destino> Podemos inserir pré-condições, pós-condições e condições de finalização num diálogo entre agentes usando KQML. O exemplo que se segue ilustra como o agente A poderá informar que acredita em X para o agente B usando pré-condições (Pre(A) e Pre(B)), pós-condições (Post(A) e Post(B)) e condições de finalização (Completion):

tell (A, B, X) Pre(A): BEL(A,X) ∧ KNOW(A, WANT(B, KNOW(B,S))) Pre(B): INT(B,KNOW(B,S)) Post(A): KNOW(A, KNOW(B,BEL(A,X))) Post(B): KNOW(B,BEL(A,X)) Completion: KNOW(B, BEL(A,X))

S pode ser BEL(B,X) ou ¬BEL(B,X)). Vejamos mais alguns exemplos de diálogos entre os agentes A e B. No primeiro desses diálogos A informa B que 3 é maior que 2: A para B: (tell (> 3 2)) No segundo diálogo A pede para B escrever “Hello” e B confirma a escrita: A para B: (perform (print “Hello!” t)) B para A: (reply done) No terceiro diálogo A põe uma questão a B para saber se o custo do produto p1 é superior ao de p2 e B informa que sim: A para B: (ask-if (> (custo p1) (custo p2))) B para A: (reply true) Finalmente, o agente A pede ao agente B que lhe informe as temperaturas mínima e máxima de cidades no dia anterior, à medida que tem conhecimento de tais temperaturas: A para B: (subscribe (temperatura ?a ?b ?c)) B para A: (tell (temperatura porto 12 20)) B para A: (tell (temperatura lisboa 13 23)) B para A: (tell (temperatura faro 15 23))



A para B: (unsubscribe (temperatura ?a ?b ?c)) 12.4 – Linguagens Comunicação entre Agentes A normalização de linguagens de comunicação facilita a interoperabilidade do software, na medida em que liberta a necessidade de implementação e tradução na interface. Hoje em dia a normalização atinge uma grande variedade de domínios. Como exemplos podemos citar o SMTP no correio electrónico, os formatos GIF e JPEG em termos gráficos e o PostScript nos programas de formatação de texto e nas impressoras. Uma Linguagem de comunicação entre agentes fornece aos agentes os meios que permitem a troca de informação e de conhecimento. Vamos abreviar o conceito de linguagem de comunicação entre agentes por ACL (Agent Communication Languages). A comunidade científica dos Agentes Inteligentes e dos Sistemas Multi-Agente atacam o problema de duas maneiras diferentes: através de uma abordagem procedimental ou através de uma abordagem declarativa. Na abordagem procedimental parte-se do princípio que a comunicação entre agentes pode ser modelizada através de directivas procedimentais. As linguagens de Script (TCL, Apple Events ou Telescript) baseiam-se nessa abordagem. É uma abordagem ao mesmo tempo simples e poderosa. Permite transmitir comandos individuais ou programas. As desvantagens são as que se identificam com as abordagens procedimentais. Por vezes é necessária informação sobre o destinatário que não está em posse do remetente. Adicionalmente, os procedimentos são unidireccionais, Muita da informação que os agentes devem partilhar deve fluir em ambos os sentidos. Além disso os scripts são de fusão complexa, esse problema não aparece quando a conversação é estabelecida de um para um, mas nos casos em que a conversação é de vários para um, este último agente tem alguma dificuldade na fusão dos scripts. Na abordagem declarativa a concepção da linguagem considera que a comunicação é melhor modelada através da troca de declarações (definições, assunções). A linguagem declarativa deve ser suficientemente expressiva. Ao mesmo tempo, a linguagem deve ser compacta. As ACL´s resultam do esforço do grupo KSE (Knowledge Sharing Effort) do DARPA-DoD (Defense Advanced Research Projects Agency of the US Department of Defense) no início dos anos 90, tomando como base a abordagem declarativa. Também no início dos anos 90 a France Telecom desenvolveu o Arcol, que continha um conjunto de primitivas inferior ao considerado no KQML. As primitivas do Arcol, tal como no KQML, são assertivas ou directivas, mas ao contrário do KQML as primitivas podem ser compostas. O Arcol tem uma semântica formal, que pressupõe que os agentes têm crenças e intenções e que podem representar as suas incertezas sobre os factos.



Uma linguagem de comunicação entre agentes muito conhecida é a FIPA ACL (FIPA – Foundation for Intelligent Physical Agents – http://www.fipa.org/) que se baseou consideravelmente no modelo e semântica do Arcol. A ACL pode ser melhor descrita como sendo constituída por três partes: o seu vocabulário, a sua “linguagem interna” (o KIF) e a sua “linguagem externa” (o KQML). Uma mensagem em ACL é uma expressão em KQML na qual os argumentos são termos ou “frases” em KIF formados por palavras do vocabulário ACL. Mas o que distingue uma ACL de tecnologias como RPC (Remote Procedure Call), RMI (Remote Method Invocation) ou CORBA e object request brokers? Uma ACL deve: • manipular proposições, regras e acções ao invés de objectos, ou seja, uma ACL

preocupa-se com aspectos mais relacionados com a semântica ou significado; • descrever estados desejados numa linguagem declarativa ao invés de procedimentos ou

métodos. Os agentes não se resumem a trocar mensagens, eles estabelecem conversações (por exemplo, num processo de negociação). Nas ACL’s é costume referirmos “actos de conversação” ao invés de troca de mensagens. As ACL´s podem suportar-se ainda no modelo BDI (beliefs, desires, intentions), ou seja, um modelo baseado em crenças, desejos e intenções. Os actos de conversação podem cair em diversas categorias. Vejamos exemplos dessas categorias:

• Assertivas: a porta está fechada; • Directivas: fechar a porta;

• Questões: A porta está fechada?;

• Comprometimentos: Eu irei fechar a porta;

• Permissivas: Ele pode fechar a porta;

• Proibitivas: Ele não pode fechar a porta;

• Declarativas: Designarei esta porta como porta de saída;

• Expressivas: Gostaria que esta fosse a porta de saída.



O diálogo pode basear-se em atitudes proposicionais. Uma atitude proposicional é uma relação com 3 partes (o agente, o conteúdo da proposição e um elemento de um conjunto finito de atitudes proposicionais). Vejamos um exemplo:

Agente : Ag Conteúdo: diminuição da taxa de juro Conjunto de atitudes proposicionais: {acredita, deseja, impõe, recomenda, evita}

Uma atitude proposicional poderia ser: <Ag, acredita, diminuição_taxa_juro> que indica que o Agente Ag acredita que vai ocorrer uma diminuição da taxa de juro.



13 – Aplicações de Agentes e Sistemas Multi-Agente Nesta secção iremos referir algumas áreas e tipos de problemas tratados pelos Agentes e Sistemas Multi-Agente. 13.1 – Comércio Electrónico O Jango (http://www.jango.com/) da Excite o Bargainfinder (http://bf.cstar.ac.com) da Andersen Consulting são exemplos de agentes que pesquisam na Internet à procura do melhor preço para um dado produto. Também podemos considerar agentes que operam em negócios entre empresas, B2B, tais como o FairMarket e no mercado de derivados, como o E-Trade e o OptiMark. O Michigan Internet AuctionBot [Wurman-1998] é um projecto do Laboratório de Inteligência Artificial da Universidade de Michigan, nos Estados Unidos da América. É visto como um serviço de recolha de informação, que recolhe ofertas, determina os preços resultantes (usando regras próprias de leilões) e notifica os participantes. Não suporta transações de nenhum tipo específico, contudo o AuctionBot dispõe de uma API que está disponível para uso. O Fishermarket [Rodrígues-1998] é outra abordagem de recriação de leilões on-line através da tecnologia dos agentes. Originalmente o Fishermarket suportava o modelo holandês de leilões, mas agora já suporta os outros modelos mais conhecidos (inglês, primeira e segunda propostas). O MAGMA [Collins-1998], posteriormente conhecido como MAGNET, foi desenvolvido na Universidade de Minnesota e permite o estabelecimento de negociações entre agentes. O KASBAH é um sistema da AmEC Initiative [Chavez-1996] ligada ao Massachusetts Institute of Technology que assenta num leilão duplo. Actualmente o sistema recebe o nome de MarketMaker. O Tete-a-Tete [Guttman-1998] é outro projecto do Massachusetts Institute of Technology que assenta no conceito de comparação de valores, ao invés de comparação de preços. É usada uma função multi-atributo de modo a representar melhor as necessidades dos utilizadores. A negociação consiste na resolução distribuída de um problema sujeito à satisfação de restrições. O CASBA [Vetter-2000] é um projecto que visa o desenvolvimento de um mercado electrónico e que segue as seis etapas do modelo CBB (Consumer Buying Behaviour).


http://www.jango.com/

http://bf.cstar.ac.com/


A proposta de um modelo para um mercado electrónico que considera o modelo CBB é também feita em [Viamonte-2000], tendo a particularidade de envolver técnicas de Data Mining no processo. O MarketSpace é uma infraestrutura de mercado aberta e baseada em agentes desenvolvida pela Universidade de Uppsala e pela empresa de telecomunicações sueca Telia. É um mercado aberto no qual a pesquisa, negociação, contratos e interacção com os utilizadores é feita recerrendo a agentes. O ODB (On-Line Dynamic Bargaining) é um sistema que tenta encontrar um compromisso entre o preço que o vendedor pretende e o preço que o potencial cliente pretende oferecer. O preço vai variando de modo a que comprador e vendedor assentem num preço comum ao longo de um processo iterativo no qual o preço do vendedor vai baixando e o do comprador vai subindo [Lin-2001]. 13.2 – Sistemas Produtivos Os sistemas de produção caracterizam-se por um elevado grau de complexidade, sendo naturalmente distribuídos do ponto de vista físico (várias máquinas, linhas de fabrico, fábricas, etc) e lógico (vários produtos, encomendas e ordens de fabrico a serem tratadas simultaneamente). Aqui é costume encontrarmos Sistemas Multi-Agente e haver algum realce para a componente de negociação. A cooperação e negociação podem ser vistas a diversos níveis, como por exemplo: • Entre recursos de uma mesma linha de produção ou de uma mesma célula de fabrico; • Entre diversas linhas de produção ou células de fabrico; • Entre a empresa e os seus fornecedores ou clientes (empresa estendida); • Entre diversas empresas para tirar partido de uma nova oportunidade de negócio (agilidade,

empresa virtual). O sistema YAMS foi talvez a primeira aplicação dos Sistemas Multi-Agente à área de sistemas de produção. Utiliza um protocolo de negociação entre agentes baseado no Contract Net [Parunak-1987]. A General Electric Power Generation utilizou o protocolo Contract Net no processo de negociação entre 35 estações de trabalho de um sistema job shop. O cliente faz pedidos de produtos, os agentes decompõem o produto em partes e fazem pedidos aos fornecedores e o processo repete-se até que a cadeia de fornecimento venha a emergir e os agentes podem desse modo enviar as suas propostas para os clientes que podem confirmá-las. O FLAVORS é um sistema instalado num computador com arquitectura paralela que controla a célula de pintura de uma fábrica de camiões [Morley-1993]. Há 7 estufas de pintura, menos



que as cores possíveis, e a mudança de côr numa estufa leva um tempo considerável de activação (setup) durante o qual a estufa não pode ser usada, para além de algum desperdício de tinta. Contudo, se não se efectuarem suficientes trocas de côr haverá encomendas que não cumprirão os seus prazos de entrega. Estabelece-se um protocolo de negociação que atribui carrocerias de camião às estufas. Este sistema levou a poupanças consideráveis na empresa. A LMS (Logistics Management System) é uma empresa de semicondutores do grupo IBM [Fordyce-1992]. Há uma parte do sistema que usa um protocolo de votação entre 4 agentes que representam “assessores” com responsabilidade de garantir um objectivo cada: • completar cada lote tão próximo quanto possível dos prazos de entrega; • atingir quotas de produção diárias; • satisfação de pedidos para centros subaproveitados; • reduzir tempos de setup e incrementar a utilização das máquinas. Desse modo consegue-se uma função global de avaliação que considere vários critérios. O ADS da Hitachi é uma arquitectura guiada por dados (data driven) para controlo em tempo real que suporta Agentes heterogéneos. O ADS foi usado pela Kawasaki Steel. As mensagens não são dirigidas, mas postas num “data field” que contém um código de conteúdo de modo que os agentes saibam se lhes são destinadas [Mori-1988]. O sistema AARIA foi construído de modo a demonstrar que juntando um grupo de agentes represerntando habilidades de produção é possível criar uma empresa de produção cujo desempenho e funcionalidades suplantem a dos sistemas convencionais [Parunak-1997]. O sistema tem funcionalidades ERP (Enterprise Resouce Planning) e MES (Manufacturing Execution Planning), nomeadamente na recepção de encomendas, compras, gestão de inventários, gestão de recursos, gestão de pessoal, contabilidade, escalonamento de capacidade finita e simulação. No sistema AARIA existem agentes separados (com igual grau de inteligência e responsabilidade) que representam Partes (componentes), Recursos e Processos Unitários (operações), não havendo um controlo centralizado. As partes movem-se de processo unitário em processo unitário, através de buffers. Cada processo unitário tem como entrada um ou mais componentes (vindos de um ou mais buffers) e produz como saída um ou mais componentes (colocando-os num ou mais buffers). Cada agente efectua um escalonamento local e a política de escalonamento é baseada em janelas temporais dinâmicas, sendo estabelecida com base num acordo com o cliente e o fornecedor com base numa função que considera o custo e a data de entrega. Este sistema foi ainda estendido, de modo a cobrir a cadeia de fornecimento, ligando clientes, fornecedores e instalações fabris distintas. O HMS Testbed foi desenvolvido na Universidade Católica de Leuven, Bélgica, consistindo num protótipo de uma estação de montagem holónica. Os recursos físicos do sistema envolvem várias estações de trabalho para maquinação e montagem, bem como um sistema de transporte (todos representados por holons). Além desses holons (hardware + software) existem três outros holons (apenas software) para escalonamento, planeamento e controlo.



Neste trabalho o escalonamento não é elaborado por vários holons, mas por um só, sendo o objectivo do trabalho analisar a cooperação entre o elemento de controlo e o de escalonamento. O holon de controlo assume a escala de tarefas enviada pelo holon de escalonamento como sendo uma proposta, tentando cumprir tal proposta se isso for viável. Em situações não previstas o holon de controlo decide autonomamente o que fazer, enviando também um pedido para o holon de escalonamento no sentido de que este gere uma nova escala [Valckenaers-1994]. 13.3 – Controlo de Tráfego O controlo de trafego aéreo é uma aplicação crítica caracterizada pela complexidade, mas que tem uma natureza claramente distribuída. Podemos imaginar Agentes que representem vôos, filas de aviões, pistas, etc. Também podemos ter Agentes que considerem aspectos como, por exemplo, os factores climatéricos. O problema é claramente um problema de escalonamento e até podemos fazer uma comparação com um sistema industrial:

Vôo ⇔ Ordem de Fabrico, Encomenda; Pista ⇔ Máquina; Tempos entre aviões na pista ⇔ Tempos de Activação (Setup).

O OASIS é um Sistema Multi-Agente implementado usando a plataforma dMARS da AAII e que foi usado com dados do Aeroporto Internacional de Sidney, na Austrália. O OASIS mistura agentes que representam funções (coordenador, sequenciador, definidor de trajectórias, analisador de ventos, interface) com agentes gerados dinamicamente e que representam os aviões que se apresentam para pousar ou levantar vôo. Outro exemplo relacionado com o tráfego é a arquitectura ADS da Hitachi, já citada anteriormente, que já foi usa para o sistema de controlo de tráfego dos comboios Shinkansen no Japão. Outro exemplo típico de controlo de tráfego corresponde à coordenação entre semáforos numa cidade. O sistema DVMT usa uma rede de sensores distribuídos espacialmente para o controlo de semáforos, obtendo-se vantagens relativamente a um controlo centralizado.



13.4 – Filtragem de Informação As aplicações são muito variadas, indo desde os sistemas de processamento inteligente de alarmes que se encontram com frequência em sistemas industriais até a filtragem de informação recebida por um utilizador (por exemplo, via email). No primeiro caso estamos geralmente na presença de sistemas críticos que se caracterizam por gerarem uma grande quantidade de informação nas situações mais problemáticas (por exemplo, no caso de avaria), a maioria dessa informação corresponde a “side-effects” (efeitos colaterais), pouco importantes para a classificação ou diagnóstico do problema, mas que acaba por complicar muito a tarefa de um operador que tente compreender em tempo útil aquilo que ocorreu. Aqui o Agente é visto como um assistente do operador (designado, muitas vezes como um Sistema de Apoio à Decisão), e em certos casos há a confiança suficiente para passar o controlo para o Agente de modo a que este possa tratar da resolução do problema. O Sistema Pericial SPARSE é um caso típico de um sistema inteligente que se encontra em evolução para um Agente desse tipo [Vale-1997]. Hoje podemos claramente ver o binómio Internet/WWW como a maior fonte de informação que alguém pode aceder. Muitos dos utilizadores dessa enorme fonte de informação debatem-se com o problema de serem claramente inundados com informação proveniente de diversos meios de acesso ou colecção de informação (mensagens recebidas via correio electrónico, pesquisas usando um browser, etc). É exactamente para facilitar a vida destes utilizadores que faz todo o sentido o uso de Agentes que efectuem a filtragem de informação. O MAXIMS é um Agente de filtragem de mensagens de correio electrónico que usa aprendizagem automática sobre as actividades que o utilizador efectua sobre as mensagens (apagar, re-enviar, arquivar, responder, etc), efectuando uma aprendizagem por observação do utilizador. Por exemplo, o sistema pode concluir que o utilizador apaga sempre as mensagens de outro utilizador específico sem sequer as ler. O NEWT é um sistema que aconselha um dado utilizador sobre quais os artigos que deve ler. O sistema baseia-se num processo de exemplos de treino, no qual o utilizador indica artigos que leria e artigos que não leria. Além disso o utilizador pode dar ordens precisas, do género “forneça todos os artigos que tenham no título o termo agente”. 13.5 – Agentes de Interface e de Obtenção e Classificação de Informação A visão de um Agente como elemento de interface com o utilizador que visa facilitar a execução de tarefas de obtenção e de classificação de informação parece uma das aplicações com mais potencial dos agentes, nomeadamente porque tais tarefas são, muitas vezes, desempenhadas de um modo repetitivo e enfadonho.



A obtenção de informação (information gathering) distingue-se da filtragem de informação pelo facto de existir um objectivo mais claro e do Agente providenciar pela procura da informação requerida, mesmo que para tal tenha que se socorrer de diversas fontes. Hoje em dia grande parte dos sistemas de obtenção de informação baseiam-se na procura de palavras-chave que caracterizem os documentos. Relativamente a escrita de documentos na WWW tem sido reconhecida a necessidade de dar uma maior ênfase ao conteúdo (XML) que ao aspecto (HTML). Estão em maturação muitas técnicas que permitirão em breve uma melhor compreensão dos textos com base em técnicas de Língua Natural e Text Mining. A classificação de informação pode ter como base a observação do comportamento de um utilizador na execução de uma tarefa de classificação, agindo posteriormente o sistema por imitação. Contudo, a classificação de informação pode requerer técnicas elaboradas de reconhecimento de padrões, usuais em reconhecimento de voz e de imagem. De seguida iremos descrever alguns sistemas de interface com o utilizador para obtenção e classificação de informação. O GALAXY é um sistema distribuído e descentralizado com uma interface por voz que permite o acesso a informação sobre um vasto leque de domínios. Este sistema permite, por exemplo, que o utilizador possa obter informação sobre voos para um dado destino, saber quais as condições climatéricas nesse destino, quais os hotéis, como chegar a um dado ponto da cidade, etc. As fontes de conhecimento podem ser várias e como se imagina a Internet serve de hospedeira ideal para este tipo de sistemas [Zue-1995]. A ZDL (Zuno Digital Library) é uma biblioteca digital que fornece uma colecção de dados organizados e serviços para o utilizador fazer uso desses dados. É um sistema multi-agente que fornece ao utilizador uma vista coerente de conjuntos de dados que podem estar desorganizados ou incoerentes (como na WWW). Os agentes podem estar classificados nas seguintes classes: • Consumidores de informação • Fornecedores de informação • Facilitadores que estabelecem a ligação entre os fornecedores e consumidores. O ARIA é um agente de interface que ajuda o utilizador na tarefa de anotação e acesso a imagens [Lieberman-2001]. Foi desenvolvido em conjunto pelo Massachusetts Institute of Technology e pelos laboratórios da KODAK. Não visa a substituição do utilizador, mas a simplificação e auxílio nas tarefas que este tem de executar. 13.6 – Aplicações Aeroespaciais Em 1998 foi lançado o DS-1 (Deep Space One) a primeira missão do novo programa da NASA, designado NMP (New Millennium Project). O DS-1 teve como missão a aproximação ao asteróide McAuliffe, a Marte e ao cometa West-Kohoutek-Ikemura. Esta nave, com apenas 100 quilos, foi a primeira a usar o sistema de propulsão iónica. Para além dessa tecnologia, o



DS-1 testou 12 outras novas tecnologias, incluindo a operação e navegação autónoma baseada em Inteligência Artificial e tecnologia de agentes. Para o efeito foi desenvolvido o Remote Agent e o AutoNav. O Remote Agent consiste num conjunto de 3 módulos independentes para planeamento, execução de planos e monitorização, estando implementado em LISP sobre um processador RS6000 especial. O AutoNav é o sistema de navegação óptico, usando uma arquitectura idêntica a de um sistema pericial. Com base no sucesso alcançado na navegação autónoma com o Remote Agent, a NASA lançou o CASPER (Continuous Activity Scheduling, Planning Execution, and Replanning) para o comando de uma missão de 3 sátelites que irá decorrer em 2002. Serão controlados parâmetros de navegação dos satélites e tomadas decisões sobre quais as imagens a tomar e quais deverão ser enviadas para terra. 13.7 – Aplicações no Mercado da Energia Eléctrica As ferramentas utilizadas e decisões tomadas pelas empresas do sector num ambiente competitivo dependem da estrutura e regras do mercado. Em qualquer tipo de mercado o objectivo é maximizar o lucro. As regras de operação devem ser previamente definidas por entidades independentes, para serem completas e “justas”. Justas, neste caso, para não haver conspiração, para a informação no mercado ser aberta a todos, para o acesso à transmissão e distribuição não ser discriminatório, e para que os preços sejam apropriados. Alterar os regulamentos afecta todas as empresas e o seu modo de negociar. Para se manterem competitivas são necessárias novas ferramentas capazes de ajudar as empresas a transitarem do ambiente antigo para o novo e competitivo mundo do futuro. Em [Sheblé-99] é possível encontrar vários métodos e ferramentas capazes de serem úteis na indústria eléctrica competitiva. Actualmente os governos encorajam a abertura do mercado, para criar um ambiente competitivo em que a geração e serviços de suporte são comprados e vendidos face à procura do mercado. O mercado irá consistir em Produtores (PROD), Distribuidores (DIST), Transmissores (TRANS), uma unidade central coordenadora para promover o funcionamento independente do sistema (OIS), e negociadores entre compradores e vendedores (NEG). Os serviços que suportam a entrega fiável de energia, tendo em conta aspectos como as perdas de transmissão, potência reactiva, gestão de congestionamentos, entre outros, têm também que ser considerados como parte integrante do sistema (AUX). As diversas entidades referidas podem ser vistas como agentes (figura 18).



PROD NEG

AUX DIST

OIS

Fig. 18 – Nova Estrutura Organizacional do Mercado da Energia Eléctrica

O Operador Independente do Sistema (OIS) é independente das outras entidades, e embora o seu papel ainda não esteja completamente definido, é responsável por coordenar os participantes no mercado de modo a promover o funcionamento fiável do sistema. O OIS necessita de novos algoritmos de optimização para funcionamento baseado no preço. Em [Sheblé-99] propõe-se um modelo de negociação de energia, utilizado no desenvolvimento de ferramentas de análise e simulação para estudar aspectos de implementação de vários contratos num mercado aberto. Em [Praça-2001b] é feita a proposta de modelar o mercado da Energia Eléctrica através de um Sistema Multi-Agente. Tal sistema tem como finalidade efectuar a simulação de tal mercado e a análise dos vários cenários possíveis é feita com recurso à Teoria de Jogos, os intervenientes no mercado são vistos como potenciais jogadores e a aplicação de um método similar ao MINIMAX serve para que se definam quais os cenários que interessa analisar de modo a que se possa suportar alguém (comprador ou vendedor) na tomada de decisões.



Referências Bibliográficas

[Agorics-URL] Agorics, Inc., “Auctions”, 1996, http://www.agorics.com/new.html.

[Alho-1998] K. Alho (1998) A Comparison of CORBA, DCOM and RMI. Helsinki University of Technology HeCSE Winter School. Janeiro de 1998. http://wwwseg.cs.hut.fi/~kta/corba-comparison/

[Bratman-1987] M. Bratman, D. Israel, M. Pollack; Toward an architecture for resource-bounded agents; Technical Report CSLI-87-104; Center of the study of Language and Information; SRI and Stanford University; 1987

[Breiter-1996] P. Breiter, M. Sadek; A Rational Agent as a Kernel of a Cooperative Dialogue Systems: Implementing a Logic Theory of Interaction; Proceedings of ECAI’96 Workshop on Agent Theories, Architectures and Languages; Springer-Verlag, Berlin, pp. 261-276; 1996

[Brooks-1985] R. Brooks; A robust layered control system for a mobile robot; Technical Report AIM-864, MIT AI Lab., Cambridge MA, 1985

[Brustolini-1991] J. Brustolini; Autonomous Agents: characterization and requirements; Carnegie Mellon Technical Report CMU-CS-91-204; Pittsburgh; 1991

[Chavez-1996] A. Chavez, P. Maes; Kasbah: An Agent Marketplace for Buying and Selling goods; Proceedings of the First International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology, Londres (Reino-Unido), 1996

[Chung-1997] P. E. Chung, Y. Huang, S. Yajnik, D. Liang, J. C. Shih, C.-Y. Wang, and Y. M. Wang (1997) DCOM and CORBA Side by Side, Step By Step, and Layer by Layer. C++ Report Magazine, Setembro 1997.

[Coelho-1994] H. Coelho; Inteligência Artificial em 25 lições; Fundação Calouste Gulbenkian; 1994

[Collins-1998] J. Collins, B. Youngdahl, S. Jamison, B. Mobasher, M. Gini; A market architecture for Multi-Agent contracting; 2nd International Conference on Autonomous Agents; Minneapolis, Estados Unidos da América; 1998

[Davis-1980] R. Davis; Report on the Workshop on Distributed Artificial Intelligence; SIGART Newsletter, n. 73, pp. 42-52; October 1980

[Davis-1983] R. Davis, R. Smith; Negotiation as a metaphor for Distributed Problem Solving; Artificial Intelligence, vol. 20, n. 1, pp. 63-109; 1983


http://wwwseg.cs.hut.fi/~kta/corba-comparison/


[Fordyce-1992] K. Fordyce, R. Dunki-Jacobs, B. Gerald, R. Sell, G. Sullivan; Logistics Management System: an advanced Decision Support System for the Fourth Decision Tier Dispatch on Short-Interval Schedulling; Production and Operations Management; vol. 1, n. 1, pp. 70-86; 1992

[Franklin-1996] S. Franklin, A. Graesser; Is it an Agent or just a Program?: A Taxonomy for Autonomous Agents; Third International Workshop on Agent Theories, Architectures and Languages; Springer-Verlag; 1996

[Geist-1994a] A. Geist, A. Beguelim, J. Dongarra, W. Jiang, R. Mancheck, PVM 3 User's Guide and Reference Manual, Technical Report ORNL/TM - 12187, Oak Ridge National Laboratory, Maio 1994.

[Geist-1994b] A. Geist, PVM: A User's Guide and Tutorial for Networked Parallel Computing, MIT Press 1994. http://www.netlib.org/pvm3/book/pvm-book.html

[Gray-1995] Gray, Agent Tcl: Alpha release 1.1, Computer Science Department, Dartmouth College, USA

[Gruber-1993] T. Gruber; A translation approach to portable ontologies; Knowledge Acquisition; vol. 5, n. 2, pp 199-220; 1993

[Guttman-1998] R. Guttman, P. Maes; Agent mediated integrative negotiation for Retail Electronic Commerce; Proceedings of the Workshop on Agent Mediated Electronic Trading, Minneapolis, Estados Unidos da América, 1998

[Hayes-Roth-1995] B. Hayes-Roth; An Architecture for Adaptive Intelligent Systems; Artificial Intelligence; Special Issue on Agents and Interactivity, 72, pp. 329-365; 1995

[Koestler-1967] A. Koestler; The Ghost in the Machine; Hutchinson & Co. Ltd., 1967

[Labrou-1988] Y. Labrou, . Finin; Semantics and Conversations for an Agent Communication Language; em Readings in Agents; M. Huhns, M. Singh; Morgan Kaufmann, San Mateo CA, pp. 235-242; 1988

[Lieberman-2001] H. Lieberman, E. Rosenzweig, P. Singh; Aria: An Agent for annotating and retrieving images; IEEE Computer, vol. 34, n. 7, pp. 57-62; July 2001

[MPI-1995] MPI: A Message-Passing Interface Standard. Message Passing Interface Forum Junho 1995.

[Maes-1995] P. Maes; Artificial Life meets Entertainment: life like Autonomous Agents; Communications of the ACM, 38, 11, 108-114; 1995

[META-1998] META Group Consulting (1998) CORBA vs. DCOM - Solutions for the Enterprise; Março de 1998;

http://www.sun.com/swdevelopment/news/CORBA.shtml

[Minsky-1986] M. Minsky; The Society of Mind; Simon and Schuster;1986

[Mitsubishi-1997] Mitsubishi Electric ITA, Concordia: an infrastructure for collaborating Mobile Agents, First International Workshop on Mobile Agents, 1997


http://www.netlib.org/pvm3/book/pvm-book.html

http://www.netlib.org/pvm3/book/pvm-book.html

http://www.sun.com/swdevelopment/news/CORBA.shtml


[Mori-1988] J. Mori, H. Torikoshi, K. Nakai, K. Mori, T. Masuda; Computer Control System for Iron and Steel Plants; Hitashi Review; vol. 37, n. 4, 251-8; 1988

[Morley-1993] R. Morley, C. Schelberg; An analysis of Plant-specific Dynamic Scheduller; NSF Workshop on Dynamic Schedulling; 1993

[Nilsson-1981] N. Nilsson; Distributed Artificial Intelligence; Report SRI International; Menlo Park CA; 1981

[Nwana-1996] H. Nwana; Software Agents: an overview; Knowledge Engineering Review; vol. 11, n. 3, pp. 205-244; 1996

[Odyssey] Odyssey at General Magic Inc., http://www.genmagic.com/agents/

[Praça-2001a] I. Praça, M.J. Viamonte; Mecanismos de Negociação em Leilões; Relatório Interno, ISEP; 2001

[Praça-2001b] I. Praça, C. Ramos, Z. Vale, Modelling and Simulation of Electricity Markets: Game Theory to improve Decision Support, 15th European Simulation Multiconference, pp.419-421, Praga (República Checa), 2001

[Parunak-1987] H. Parunak; Manufacturing experience with Contract Net; em Distributed Artificial Intelligence; M. Huns; Pitman; pp. 285-310; 1987

[Parunak-1997] H. Parunak, A. Baker, S. Clark; The AARIA Agent Architecture; Proceedings of the 1st International Conference on Autonomous Agents; Marina del Rey, CA, 1997

[Ramos-1993] C. Ramos; Planeamento e Execução Inteligente de Tarefas em Robótica de Montagem e de Manipulação; Tese de Doutoramento; Faculdade de Engenharia da Universidade do Porto; 1993

[Ramos-1996] C. Ramos, A Holonic Approach for Task Scheduling in Manufacturing Systems, IEEE International Conference on Robotics and Automation, pp. 2511-2516, Minneapolis (Estados Unidos da América), 1996

[Ramos-2001] C. Ramos; Sistemas de Apoio à Decisão com Inteligência Escalável; Lição apresentada no âmbito das Provas de Agregação; DEEC – Faculdade de Engenharia da Universidade do Porto; 2001

[Rao-1991] A. Rao, M. Georgeff; Modeling rational agents within a BDI-architecture; Technical Report 14; Australian AI Institute; Carlton, Australia, 1991

[Rodrígues-1998] J. Rodrígues-Aguilar, F. Martín, P. Noriega, P. Garcia, C. Sierra; Towards a testbed for Trading Agents in Electronic Auction Markets; AI Communications; IOS Press; 1998

[Russell-1995] S. Russell, P. Norvig; Artificial Intelligence a modern approach; Prentice-Hall International Editions, 1995

[Sheblé-1999] G. Sheblé, “Computational Auction Mechanisms for Reestructured Power Industry Operation”, Kluwer Academic Publishers, Londres, 1999

[Silva-1998] N. Silva; Sistemas Holónicos de Produção; Tese de Mestrado; Faculdade de Engenharia da Universidade do Porto; 1998



[Smith-1994] D. Smith, A. Cypher, J. Spohrer; KidSim: Programming Agents without a Programming Language; Communications of the ACM, 37, 7, 55-67; 1994

[Sousa-1999] P. Sousa, J. Morais, Análise de Tecnologias de Distribuição, relatório técnico, ISEP, 1999

[Sousa-2000] P. Sousa; Agentes Inteligentes em Sistemas Holónicos de Produção; Tese de Doutoramento; Universidade do Minho; 2000

[Valckenaers-1994] P. Valckenaers, F. Bonneville, H. Van Brussel, L. Bongaerts, J. Wyns; Results of the Holonic Control System Benchmark at the University of Leuven; Proceedings of the International Conference on Computer Integrated Manufacturing and Automation Technology; pp. 128-133, RPI, Troy, NY, Estados Unidos da América, 1994

[Vale-1997] Z. Vale, A. Moura, M. Fernandes, A. Marques, C. Rosado, C. Ramos; Sparse: An Intelligent Alarm Processor and Operator Assistant; IEEE Expert - Intelligent Systems and Applications, vol. 12, n. 3, pp. 86-93, May/June 1997

[Vetter-2000] M. Vetter, S. Pitsch; Towards a Flexible Trading Process over the Internet; The European AgentLink Perspective, Lecture Notes in Artificial Intelligence 1991, Frank Dignum, Carlos Sierra, Springer, pp. 148-162, 2000

[Viamonte-2000] M.J. Viamonte, C. Ramos, A model for an Electronic Market Place, em Agent Mediated Electronic Commerce – The European AgentLink Perspective, Lecture Notes in Artificial Intelligence 1991, Frank Dignum, Carlos Sierra, Springer, pp. 115-125, 2000

[Walker-1994] J. Walker, L. Sproull, R. Subramani; Using a human face in an interface; Proceedings of Computer-Human Interaction; pp. 85-91; Boston (Estados Unidos da América); 1994

[Wittig-1992] T. Wittig; ARCHON – An architecture for Multi-Agent Systems; Ellis Horwood Ltd; 1992

[Wooldridge-1995] M. Wooldridge, N. Jennings; Agent Theories, Architectures, and Languages: a Survey; Intelligent Agents; M. Wooldridge, N. Jennings; Springer-Verlag, 1-22; 1995

[Wooldridge-1998] M. Wooldridge, N. Jennings; Pitfalls of Agent-oriented Development; 1998

[Wurman-1998] P. Wurman, M. Wellman, W. Walsh, The Michigan Internet AuctionBot: A configurable auction server for human and software agents; 2nd International Conference on Autonomous Agents; Minneapolis, Estados Unidos da América; 1998

[Zue-1995] Zue V.; Navigating the Information Superhighway using Spoken Language Interfaces; IEEE Expert Intelligent Systems and their Applications, vol. 10, n. 5, pp. 39-43, October 1995


1- introdução - dei.isep.ipp.ptdei.isep.ipp.pt/~asilva/apontamentos_aisc.pdf · revistas,...

Documents