Sistema MultiAgente Para Informação Geográfica (Novas Funcionalidades)

Relatório do Seminário/Projecto da Licenciatura em EngŠ Electrotécnica e de Computadores (Ramo de Informática e Sistemas), Faculdade de Engenharia da Universidade do Porto, Julho 1998.

Executado por: Jorge Cunha de Sequeira Amaral

Orientador: Professor Doutor Eugénio da Costa Oliveira


Índice:

1. O que é o SMAPInG

2. Motivação e objectivos do projecto

3. Editor - um editor do conhecimento dos agentes
3.1. Funcionalidades
3.2. Estrutura modular do programa
3.3. Esquema de representação do conhecimento
3.4. Ambiente de desenvolvimento
3.5. Avaliação do resultado e possíveis melhoramentos
3.6. Exemplo de uma execução

4. Interface Web
4.1. Funcionalidades
4.2. A Web e paradigmas utilizados
4.2.1. As novas possibilidades do HTML
4.2.2. Os CGIs (Common Gateway Interfaces)
4.2.3. Os Daemons
4.2.4. Comunicação por sockets
4.3. Estrutura modular
4.4. Ambiente de desenvolvimento
4.5. Avaliação do resultado e possíveis melhoramentos
4.6. Exemplo de uma execução

5. O Daemon de edição do conhecimento dos agentes
5.1. Funcionalidades
5.2. Estrutura modular do programa
5.3. Esquemas de representação do conhecimento
5.4. Ambiente de desenvolvimento
5.5. Avaliação do resultado e possíveis melhoramentos
5.6. Exemplo de uma execução

6. O Daemon de interface com os agentes
6.1. Funcionalidades
6.2. Estrutura modular do programa
6.3. As comunicações com os agentes
6.4. Ambiente de desenvolvimento
6.5. Avaliação do resultado e possíveis melhoramentos
6.6. Exemplo de uma execução

7. Visão geral do SMAPInG

8. Conclusão

9. Bibliografia

Apêndice A. Dados de referência sobre o SMAPInG


1. O que é o SMAPInG

O Sistema MultiAgente Para Informação Geográfica foi desenvolvido, como projecto de final de curso, por Nuno Malheiro, sob a orientação do Professor Doutor Eugénio Oliveira.

Este projecto consiste num sistema que responde a questões sobre a construção em zonas territoriais. O sistema contém dados geográficos sobre a área a analisar, bem como conhecimento relativo a várias disciplinas, de modo a poder fundamentar escolhas que resultem numa final escolha das áreas mais adequadas a um certo tipo de construção.

A implementação deste sistema é do tipo multi-agente, tendo sido distribuído o conhecimento pelos vários agentes, ficando cada um destes com as tarefas relativas ao seu próprio conhecimento. Os agentes são os seguintes:

- Agente inteligente dedicado à construção e economia;
- Agente inteligente dedicado ao ambiente e sociologia;
- Agente inteligente de controlo de operações;
- Agente de interface com o utilizador;
- Agente do sistema de informação geográfica;
- Agente do sistema de base de dados;

O estudo da localização da construção escolhida é dividido em duas fases. A primeira tratará da eliminação de todos os locais em que não é possível qualquer construção, e a segunda vai encontrar, dentro dos permitidos, aqueles que mais se adequam ao objectivo. Ambas as fases se baseiam na cooperação entre os diversos agentes, sendo a segunda ainda baseada num processo de optimização global de optimizações locais dos vários agentes.

Para uma melhor compreensão do sistema, é aconselhável uma leitura do relatório do projecto [SMAPInG, Malheiro '97].

Voltar ao índice


2. Motivação e objectivos do projecto

O sistema SMAPInG, como projecto em curso, apresentava vários pontos nos quais melhorias ou alterações se demonstraram necessárias:

- Alteração da interface gráfica: o sistema fora totalmente escrito em Prolog, utilizando Prolog (YAP e o Ytoolkit) para realizar a interface, sendo visível uma inadequação em termos de velocidade e facilidade de utilização desta linguagem; é necessário, assim, tornar a interface mais rápida e menos "pesada" em termos de recursos do sistema.
- Implementação de interfaces gráficas para a edição de todo o conhecimento dos agentes (base de conhecimento, autoconheci-mento, e conhecimento dos agentes cooperantes): esta questão implica um interface de aquisição de dados baseados em lógica difusa, de modo a facilitar a edição.
- Possibilidade de utilização do sistema via Web: de modo a permitir a utilização do sistema por via remota, quer em intranet ou através da internet, é necessário a implementação de um novo agente que receba pedidos através de páginas Web e as transmita as sistema, recolhendo posteriormente os resultados e apresentando-os em formato Web ao utilizador.
- Implementação de tratamento de pedidos de explicações: o sistema apresenta as comunicações entre agentes de uma maneira pouco clara e não fornece indicações sobre o funcionamento interno do sistema; torna-se importante dar a possibilidade ao utilizador de avaliar as acções do sistema, o que é importante para a aceitação dos resultados deste.

Numa primeira aproximação a estas questões, foi concluído que o objectivo mais proeminente era a possibilidade de edição do conhecimento dos agentes. Era necessário um software que, de uma maneira simples, apresentasse a um perito numa dada área, uma visão do conhecimento contido nos agentes e ferramentas para a alteração deste. Foi assim decidida a implementação do Editor, que, funcionando de maneira independente em relação ao restante sistema, oferece todas estas funcionalidades.

Posteriormente, e de maneira a tornar todo o sistema acessível através da Web, procedeu-se à implementação de um interface agentes - servidor Web que possibilita, além de todas as funções do já existente agente do utilizador, uma função de explicação do funcionamento do sistema, bem como à escrita de uma versão do editor de conhecimento que funciona com o servidor Web.

Desta maneira deu-se resposta às necessidades previstas dos utilizadores, criando um sistema que funciona a partir de qualquer computador ligado à internet, apresentando praticamente todas as funcionalidades do sistema original, num formato mais acessível e facilmente utilizável, bem como adicionando funcionalidades indispensáveis a qualquer sistema pericial que não tinham sido ainda desenvolvidas.

Voltar ao índice


3. Editor - um editor de conhecimento dos agentes

Uma das lacunas em termos de funcionalidades do SMAPInG é a ausência de mecanismos, outros que não a escrita de código Prolog, para a criação / alteração dos conhecimentos dos vários agentes que cooperam neste sistema.
Para preencher esta falta foi criado este Editor, que permite de uma forma mais "amigável" observar, editar ou criar o conhecimento que irá reger os agentes no funcionamento geral do sistema.

Como parte constituinte do sistema, este Editor será uma parte indispensável no caso de uma possível utilização não académica deste sistema. É importante realçar que nos tempos actuais, não se pode requerer do utilizador de um sistema uma aprendizagem muito longa prévia à utilização do mesmo. Todo o sistema informático deve ser de fácil utilização pelo público alvo, que neste caso será um perito em informação geográfica com conhecimentos gerais do funcionamento do SMAPInG.

O Editor é, assim, uma instrumento poderoso, mas fácil de utilizar, que permite a alteração dos conhecimentos dos agentes já existentes, bem como (e esta será talvez a maior inovação introduzida) a criação dos conhecimentos para possíveis novos agentes, facilitando a expansão do sistema (1).

Voltar ao índice

3.1. Funcionalidades

O Editor permite ao utilizador a visualização, alteração ou criação de todo o conhecimento necessário ao funcionamento dos agentes do SMAPInG. Cada agente deste sistema tem três tipos de conhecimento:

- Autoconhecimento: dados relativos ao próprio agente, como nome, tipo, bem como informações quanto ao conhecimento que ele próprio pode possuir;
- Conhecimento dos agentes cooperantes: informações necessárias à cooperação entre os vários agentes, como conhecimentos que possuem, nome e dados para a comunicação entre agentes;
- Base de conhecimento: dados pormenorizados dos conceitos, atributos e valores utilizados para a chegada à solução por parte dos agentes, assim como as regras que permitem o chegada a novas conclusões.

Este conhecimento está descrito em linguagem Prolog, dividido em três ficheiros por agente, correspondentes a cada um dos tipos de conhecimento. O Editor permite ao utilizador seleccionar os ficheiros alvo prosseguindo à leitura e integração da informação na sua própria estrutura de informação interna.

Após a integração desta informação (no caso de se pretender alterar conhecimentos já existentes) ou partindo do nada, o utilizador pode utilizar o interface gráfico para facilmente navegar através de toda a informação, construindo ou destruindo informação que ache relevante.
Talvez as partes mais críticas para o bom funcionamento do Editor sejam a apresentação gráfica da informação baseada em lógica difusa assim como a possibilidade de editar as regras quase exclusivamente através do rato, que passarei a descrever:

A apresentação dos valores possíveis de um certo atributo, que neste sistema se baseia em utilização de lógica difusa como também de lógica "crisp" (2), torna-se bastante mais óbvia quando representada graficamente, uma vez que seria bastante trabalhoso para o utilizador a introdução directa das variáveis necessárias à definição das funções utilizadas para descrever este tipo de lógica.
As funções possibilitadas para a descrição dos graus de pertença de um certo elemento a um valor de um atributo (grupo) são "crisp" (isto é: sim ou não), função gaussiana, hiperbólica superior e hiperbólica inferior.
Através da alteração das variáveis referentes a estas funções, o utilizador apercebe-se imediatamente das implicações das suas alterações, uma vez que está representado num gráfico grau de pertença / elemento do conjunto a função que está a utilizar.

A edição de regras do Editor foi prevista para uma fácil utilização, não sendo necessário por parte do utilizador muito mais do que uns cliques no rato para construir uma regra. Como se mostrará posteriormente num exemplo da utilização do software, o utilizador tem a seu dispor uma lista de todos os atributos que o agente tem conhecimento, de onde pode seleccionar o necessário à construção da regra em causa, sendo-lhe automaticamente apresentados os valores que esse atributo pode tomar.
O Editor converte essa informação, apresentada em dados que possam ser utilizados na descrição das regras de forma legível pelo SMAPInG, mostrando a regra a ser construída. É também possível editar directamente a regra.

Faz parte também do programa uma ajuda on-line, assim como uma indicação constante dos ficheiros que estão a ser utilizados.


Voltar ao índice

3.2. Estrutura modular do programa

O Editor pode-se dividir em quatro partes distintas:

1. Módulo de leitura (parser) e escrita dos ficheiros em Prolog;
2. Base de dados de informação;
3. Módulo de interacção com o utilizador;
4. Módulo de processamento dos dados.
Represento de seguida as interacções entre módulos e entidades exteriores:

Imagem 1

Num tom azul estão representados os módulos que fazem parte do Editor e a negro os intervenientes exteriores. Note-se a independência funcional do Editor em relação ao restante SMAPInG, uma vez que a única ligação é feita através dos ficheiros relativos aos agentes que o Editor altera a comando do utilizador.

Em contraste, e uma vez que o Editor foi desenhado para ser utilizado em conjunção com o restante SMAPInG, mostro de seguida a influência nos restantes módulos sistema, isto é as repercussões da alteração do conhecimento dos agentes ao nível mais superior da totalidade do sistema.

Imagem 2

Voltar ao índice

3.3. Esquema de representação do conhecimento

O esquema de representação de conhecimento não foi escolhido aquando da realização do Editor mas sim definido anteriormente pelo SMAPInG, sendo forçosa a utilização do mesmo esquema. De qualquer forma não é dispensável uma descrição deste:

A base de conhecimento dos agentes usa o triplo conceito-atributo-valor. Assim, um determinado domínio (neste caso a informação geográfica) é definido por conceitos que definem o conhecimento desse domínio, respectivos atributos e valores possíveis que cada atributo pode tomar.
As regras de produção utilizadas pelo SMAPInG baseiam-se na definição de um conceito para a regra, premissas que inferem num determinado atributo um valor ou resultado de um cálculo matemático, sempre aliado a um factor de certeza da própria regra.
O restante conhecimento (autoconhecimento e agentes conhecidos) é representado por simples indicação de dados relativos ao próprio agente e aos agentes cooperantes como sejam conhecimentos que detêm, tipo de agente, nome e dados para comunicações.

Voltar ao índice

3.4. Ambiente de desenvolvimento

Tendo o SMAPInG sido desenvolvido para correr numa máquina UNIX sobre X-Windows, o Editor terá também de funcionar sobre esta plataforma. No entanto e ao contrário do SMAPInG (que foi desenvolvido no YAP - Yet Another Prolog), achei necessária a utilização de um interface gráfico mais poderoso que o permitido pelo Ytoolkit. Assim, surgiu a hipótese de utilizar o Xforms, uma biblioteca de funções em C para criação de formulários, que pareceu adequada aos propósitos do Editor.
Explorando a particularidade de toda a informação relativa ao conhecimento dos agentes residir em ficheiros separados do restante sistema, pareceu-me preferível a utilização total de C, não recorrendo ao Prolog.
Assim, todo o programa está escrito em C, tendo sido utilizado o Form Designer do Xforms para criar uma primeira imagem do interface gráfico. No entanto, uma vez que este não é uma programa que permita uma programação visual (como o VisualC++ ou VisualJ++), praticamente todo o programa teve de ser escrito directamente em C.

Voltar ao índice

3.5. Avaliação do resultado e possíveis melhoramentos

À parte da satisfação total dos requisitos essenciais, como sejam a leitura dos ficheiros em Prolog e escrita dos mesmos, parece-me que o ponto mais relevante neste Editor é a facilidade de utilização, uma vez que foi feita uma séria tentativa de fazer que o programa fosse o mais fácil de utilizar possível.

Melhoramentos possíveis no programa seriam:

- alteração das estruturas de informação para aumento da rapidez de procura de informações;
- alteração dos algoritmos de leitura dos ficheiros Prolog;
- melhorar a escrita de regras, possibilitando nesta uma visualização gráfica semelhante à executada na edição dos valores possíveis para os atributos;

Voltar ao índice

3.6. Exemplo de uma execução

Ao iniciar o Editor o utilizador é confrontado com o menu inicial (janela Editor) em que pode, entre outras funcionalidades, ler um ficheiro de conhecimento do SMAPInG (botão Ler Ficheiro). Carregando neste botão, é-lhe apresentado um menu de leitura de ficheiros, em que pode navegar através da estrutura de ficheiros acessíveis, onde pode escolher os dados a serem introduzidos na memória pelo Editor.

O Editor reconhece como ficheiros do SMAPInG todos os ficheiros com ACQ, KB e SM no seu nome, verificando assim o tipo de informações que estes contêm. Se o programa não detectar o tipo de ficheiro, é dada ao utilizador a hipótese de decidir o tipo de informação que está contida no ficheiro, de modo que o Editor funcione correctamente.

É mostrado o caminho dos ficheiros correntemente utilizados pelo SMAPInG na janela Editor, nos locais referentes ao Autoconhecimento, Agentes conhecidos e Base de conhecimento, para facilidade do utilizador.

Imagem 3

Após a leitura dos ficheiros, o utilizador pode seleccionar da janela Editor, através de um selector vertical qual o conhecimento a ver/editar (selector Dados: ).
As quatro janelas correspondentes aos quatro diferentes tipos de conhecimento funcionam de maneira semelhante, sendo apenas a introdução de valores na janela BaseConhecimento e a introdução de regras na janela Regras algo diferentes.

Imagem 4

Imagem 5

No caso da introdução de valores, é mostrado ao utilizador um gráfico representante da função grau de pertença / elemento do grupo, de maneira a ser mais fácil observar as repercussões das alterações das várias variáveis destas funções.

Na introdução de regras, é mostrada uma lista de atributos de onde o utilizador pode escolher os necessários para escrever a regra, sendo mostrado em baixo todos os valores possíveis para esse atributo, de modo a que o utilizador possa convenientemente completar a regra sem ter que recorrer à consulta de outras informações.

Após todas as alterações completadas o utilizador pode gravar o conhecimento (botão Gravar Ficheiro) sendo-lhe perguntado o tipo de dados a gravar e sendo-lhe mostrado uma janela equivalente à utilizada para a leitura de ficheiros de modo a que este possa escolher um ficheiro para gravar.


Imagem 6

Imagem 7

Resta referir a janela de ajuda on-line, acessível carregando no botão Ajuda da janela Editor que contém o manual transcrito no apêndice anterior deste texto.

Voltar ao índice


4. Interface Web

A Internet tem crescido a um ritmo extraordinário durante os últimos anos. Desde o tempo em que era apenas utilizado pela comunidade académica e pelas agências estatais americanas até à data presente, apenas um punhado de anos se passaram. Talvez a maior responsável por este crescimento seja a World Wide Web. A sua linguagem é simples, o interface é atractivo e amigável, e pode ter múltiplas utilizações.
As mais recentes evoluções nos "browsers" e na linguagem HTML permitem uma solução relativamente boa aos problemas de incompatibilidades de hardware e acessibilidade de software. É possível, neste momento, desenvolver interfaces gráficos Web que permitam a um utilizador, colocado em qualquer ponto do mundo e ligado à Web por um browser, utilizar um programa localizado noutro qualquer local. Resolvem-se assim questões de portabilidade (3) e de conveniência de utilização.

De modo a trazer estas facilidades ao SMAPInG, e dentro de algumas restrições, optou-se pela integração total de um interface Web com o restante sistema.

Voltar ao índice

4.1. Funcionalidades

Este interface oferece todas as funcionalidades do interface utilizador do sistema original, bem como o acesso às explicações e a quase todas as funcionalidades do editor de conhecimento dos agentes:

- escolha da camada de fundo para a visualização no GIS; (4)
- escolha de tipo de construção;
- execução de perguntas referentes a regras e factos;
- listagem de explicações;
- alteração das áreas;
- edição do autoconhecimento dos agentes;
- edição do conhecimento dos agentes cooperantes;
- edição da base de conhecimento (algumas funcionalidades possíveis no Editor não se encontram disponíveis através da Web, por dificuldades de implementação do interface gráfico)

Voltar ao índice

4.2. A Web e paradigmas utilizados

No desenvolvimento de interfaces Web, questões tão simples (para um programa que corre localmente) como introdução de dados, execução de menus pull-down, e outros métodos de interface, tornam-se mais complexas. É necessário recorrer, para a escrita das "páginas" Web, para além do HTML (HyperText Markup Language) ao JavaScript, e para passar a informação até ao sistema (aos agentes que executam as operações), é necessário recorrer à comunicação através de CGI, bem como a criação de daemons e utilização de sockets para a comunicação entre estes e os CGIs.
Foi posta de parte a utilização de applets Java ou outros plug-ins para os browsers, uma vez que essas opções trazem prejuízos em rapidez de utilização (principalmente nos downloads) e na portabilidade, bem como algumas questões de segurança nas comunicações, não dando a liberdade de utilização necessária.

Voltar ao índice

4.2.1. As novas possibilidades do HTML

A HyperText Markup Language começou por ser uma forma simples de transmissão de informação através da internet, baseando-se em apenas texto, permitindo a definição do estilo por meio de "tags" delimitadoras. Pode-se comparar esta primeira encarnação do HTML aos primeiros processadores de texto, que utilizavam o mesmo sistema.
Desde essa altura que o HTML sofreu inúmeras alterações, desde a introdução das "forms" (formulários para envio de informação), a utilização de gráficos, até à introdução de "scripts" e das "style sheets". Estas duas últimas adições ao HTML formam os que se denomina de Dynamic HTML (DHTML), e que permite a criação não só de páginas mais atractivas, mas também de melhores e mais poderosos interfaces.

Foram utilizados, nesta interface, scripts JavaScript, Cascading Style Sheets e forms (quer visíveis quer "escondidas") para possibilitar a interação do interface com o sistema em si.
Assim, a interface Web desenvolvida para o SMAPInG tirou partido destas inovações, tentando facilitar ao máximo a utilização. No entanto, nem todos os utilizadores da Web têm ao seu dispor as últimas versões dos browsers, pelo que se teve também de executar uma versão menos complexa, sacrificando o aspecto gráfico e facilidade de utilização.

Voltar ao índice

4.2.2. Os CGIs (Common Gateway Interfaces)

De forma a que os dados introduzidos pelo utilizador nas páginas Web cheguem ao restante sistema, é necessário utilizar CGIs, programas desenhados para receber a informação codificada vinda do servidor Web.

A função principal dos CGIs, neste sistema, é de servir de elo de ligação entre o servidor e os daemons (discutidos à frente), sendo portanto responsáveis pela descodificação da informação vinda do servidor, interacção com o daemon através de sockets e produção de páginas em HTML dependentes da informações recebidas dos daemons, criando-se páginas Web dinâmicas.
Os CGIs foram escritos em C++, de modo a tirar partido das implementações de interface de sockets já executadas para os daemons. Claro está, que o resultado apresentado pelos CGIs é em HTML, muitas vezes contendo JavaScript.

Pode-se talvez pensar que é um método um pouco arcaico e complexo para executar o efeito pretendido, e que se poderia utilizar outros métodos, como applets em Java ou ActiveX, mas como facilmente se pode observar na World Wide Web em geral, os CGIs ainda são o método mais seguro e mais utilizado pela comunidade da internet.


Não fazendo parte integrante do interface Web, é importante referir neste momento os daemons e a comunicação por sockets, de modo que seja de mais fácil compreensão a interacção entre a Web e o sistema restante.

Voltar ao índice

4.2.3. Os Daemons

Os daemons são programas desenhados para residir num computador, só sendo activados quando recebem sinais dos utilizadores, executando uma tarefa apenas quando são necessários.

Neste sistema, foram implementados dois daemons, um para a edição do conhecimento dos agentes (executa quase todas as funções do Editor) e um para a comunicação com estes (os dois daemons são analisados em detalhe posteriormente). Ambos operam através de sockets TCP, recebendo pedidos e retornando resultados apenas por este meio.

Voltar ao índice

4.2.4. Comunicação por sockets

Praticamente toda a comunicação no SMAPInG é feita por meio de sockets. À excepção das chamadas por parte do servidor Web aos CGIs, a informação, que contém pedidos e respostas dos vários agentes, interfaces e daemons, é transmitida e recebida utilizando tanto Stream Sockets (usando protocolo TCP) como Datagram Sockets (usando protocolo UDP).
É usado o protocolo TCP para as comunicações entre CGIs e Daemons e entre o utilizador e o interfaces Web (comunicação assegurada pelo browser do utilizador e o servidor Web), e o protocolo UDP para as comunicações entre os agentes e entre o daemon do interface utilizador.
Pode-se considerar este daemon também como um agente, do mesmo modo que o interface utilizador já desenvolvido, mas continuarei a chamá-lo daemon para melhor os diferenciar.

Voltar ao índice

4.3. Estrutura modular

O interface web está dividido em várias páginas e CGIs, que aqui se listam:

- Apresentação e escolha de versão (dependente do browser utilizado);
- Escolha do modo (utilizador ou perito) para Internet Explorer 4;
- Escolha do modo (utilizador ou perito) para outros browsers;
- Interface utilizador para Internet Explorer 4;
- Interface utilizador para outros browsers;
- CGI de início do sistema;
- CGI de interrogação de factos;
- CGI de interrogação de regras;
- CGI de explicações;
- CGI de autenticação do perito;
- Interface de edição de conhecimento;
- CGI de edição de autoconhecimento;
- CGI de edição de base de conhecimento;
- CGI de edição de conhecimento sobre agentes cooperantes;
- CGI de edição de regras;

Segue-se um esquema gráfico para uma melhor compreensão das interligações dos vários módulos:

Imagem 8

Voltar ao índice

4.4. Ambiente de desenvolvimento

A maior parte do código, tantos das páginas HTML como dos CGIs, foi escrito directamente, sem auxílio de software de construção de páginas Web. Isto deve-se ao facto de que praticamente todo o software shareware de escrita HTML não estar actualizado às novas alterações no HTML, contendo erros e inconsistências na execução de código executável nos vários browsers.

Quanto à escrita dos CGIs, não tenho conhecimento de qualquer software que permita facilitar a escrita destes, tendo sido talvez esta a parte em que se sentiu mais necessidade de uma ferramenta deste tipo. Como já foi referido, os CGIs estão codificados em C++, de modo a simplificar a utilização dos sockets, uma vez que já tinham sido implementado o código para estes na construção dos daemons.

Em relação aos gráficos, todos eles foram criados de raiz utilizando o Adobe PhotoShop 4.0 e o PaintShop Pro.

Voltar ao índice

4.5. Avaliação do resultado e possíveis melhoramentos

O objectivo para esta parte do SMAPInG foi atingido, sendo construído um interface Web para a utilização de quase todas as funcionalidades possíveis ao utilizar o sistema localmente. É assim, apenas necessário ao utilizador ter um computador ligado à internet e um browser para usufruir do sistema. Não é necessário qualquer software adicional ou o download demorado de plug-ins.

Como já foi apontado, o melhoramento mais necessário será a implementação de uma interface que possibilite a visualização do ecrâ do GIS GRASS ao utilizador via Web. Esta melhoria facilitará a utilização global do sistema.

Voltar ao índice

4.6. Exemplo de uma execução

Apresenta-se de seguida uma sequência de imagens referentes a uma utilização do interface, obtida num PC remoto ligado à internet:

Em primeiro lugar, uma imagem da página Web inicial, onde há alguma informação sobre o SMAPInG e é possível escolher o tipo de browser utilizado.

Imagem 9

Depois da escolha do browser, é apresentado a opção de prosseguir como utilizador normal ou perito, opção esta que necessita da introdução de uma password.

Imagem 10

Escolhendo a opção de utilizador, e com o Internet Explorer 4, temos o ecrã de interface com o SMAPInG, onde se pode interagir directamente com o sistema:

Imagem 11

Neste imagem, está seleccionada a camada de fundo "relevo", o tipo de construção é "construção escolar" e o perito "ambiente e sociologia", e o utilizador está a utilizar a função de questões sobre factos.

Na imagem seguinte, a camada de fundo foi alterada para "geologia" (a imagem no canto superior direito indica essa escolha), o tipo de construção para "indústria poluente", e o perito para "construção e economia". O utilizador fez uma alteração no tamanho das áreas, e está a utilizar o menu de camada de fundo, para fazer uma alteração neste valor.

Imagem 12

Imagem 13

Utilizando a opção de questionar um perito sobre determinada regra, a resposta é apresentada numa janela à parte, como se mostra, possibilitando manter no ecrã várias operações simultâneamente, como por exemplo, fazer uma questão sobre uma regra, um facto, e iniciar o sistema.



Para um utilizador que não possua o Internet Explorer 4, o interface tem este aspecto, que embora não seja de tão fácil utilização e de compreensão tão imediata, apresenta todas as possibilidades do anterior.

Imagem 14

Nesta imagem o utilizador questionou o perito em relação ao seu conhecimento de um determinado facto, sendo a resposta apresentada também neste caso numa janela exterior:

Imagem 15

Abordado o interface utilizador, mostra-se agora o interface do perito.

Como se pode ver pela imagem seguinte, o perito introduziu correctamente a sua password, sendo-lhe possibilitada, numa nova janela, a escolha de um dos vários agentes para posterior alteração do conhecimento:

Imagem 16

Escolhendo o perito de construção e economia, é dada a escolher o tipo de conhecimento que se pretende visualizar, de entre autoconhecimento, agentes conhecidos, base de conhecimento e regras.

Na imagem seguinte mostram-se estas opções.

Imagem 17

Escolhendo, por exemplo a base de conhecimentos, as alterações são efectuadas por meio de forms, de maneira semelhante ao que acontece no Editor, permitindo inserção, alteração, eleminação, e funções de movimentação através de todos os dados.

Imagem 18

De maneira a não sobrecarregar o texto com imagens, só algumas utilizações foram mostradas, uma vez que o funcionamento e apresentação de outras funcionalidades é semelhante.

Voltar ao índice


5. O Daemon de edição do conhecimento dos agentes

Com funções semelhantes ao Editor, focado em detalhe no ponto 3, o daemon tem uma grande diferença em relação a este: a sua interface não é gráfica, mas sim ao nível de comandos, possibilitando tanto a utilização directa pelo utilizador (correndo um telnet à porta utilizada pelo daemon) como através de qualquer outro software que se encarregue de transmitir os pedidos ao deamon e de apresentar os resultados ao utilizador (como é o caso do interface Web apresentado no ponto anterior).
Assim, este daemon pode ser um base para o desenvolvimento de outros possíveis interfaces, quando se apresentar essa necessidade.

Voltar ao índice

5.1. Funcionalidades

Uma vez que o programa é gerido por comandos, lista-se todas as funcionalidades oferecidas, bem como os comandos correspondentes:

- kill : termina o daemon, desligando-o da porta que ocupa
- hold : desliga a ligação mas não termina o daemon
- load : lê o conhecimento de um determinado agente, que pode ser:
- ambsoc : agente inteligente do ambiente e sociologia
- coneco : agente inteligente de construção e economia
- conope : agente inteligente de controlo de operações
- gis : agente geográfico
- user : agente utilizador
- get : lista o conhecimento das seguintes áreas possíveis:
- auto : autoconhecimento
- conh : agentes conhecidos
- base : base de conhecimento
- regr : regras
- put : altera o conhecimento nas seguintes áreas possíveis:
- auto : autoconhecimento
- know : conhecimentos do agente
- me : dados sobre o agente
- conh : agentes conhecidos
- know : conhecimento do cooperador
- wind : dados das janelas
- coop : dados sobre o cooperador
- base : base de conhecimento
- conc : conceitos
- rast : rasters
- atri : atributos
- valu : valores
- valo : valores possíveis
- regr : regras
- regr : regra
- linh : linha da regra
- back : segue para o conhecimento anterior de um dos possíveis:
- auto : autoconhecimento
- know : conhecimentos do agente
- conh : agentes conhecidos
- know : conhecimento do cooperador
- wind : dados das janelas
- coop : dados sobre o cooperador
- base : base de conhecimento
- conc : conceitos
- rast : rasters
- atri : atributos
- valu : valores
- valo : valores possíveis
- regr : regras
- regr : regra
- linh : linha da regra
- forward : segue para o conhecimento seguinte de um dos possíveis:
- auto : autoconhecimento
- know : conhecimentos do agente
- conh : agentes conhecidos
- know : conhecimento do cooperador
- wind : dados das janelas
- coop : dados sobre o cooperador
- base : base de conhecimento
- conc : conceitos
- rast : rasters
- atri : atributos
- valu : valores
- valo : valores possíveis
- regr : regras
- regr : regra
- linh : linha da regra
- insert: insere um novo conhecimento de um dos possíveis:
- auto : autoconhecimento
- know : conhecimentos do agente
- conh : agentes conhecidos
- know : conhecimento do cooperador
- wind : dados das janelas
- coop : dados sobre o cooperador
- base : base de conhecimento
- conc : conceitos
- rast : rasters
- atri : atributos
- valu : valores
- valo : valores possíveis
- regr : regras
- regr : regra
- linh : linha da regra
- delete : apaga o conhecimento nas seguintes áreas possíveis:
- auto : autoconhecimento
- know : conhecimentos do agente
- me : dados sobre o agente
- conh : agentes conhecidos
- know : conhecimento do cooperador
- wind : dados das janelas
- coop : dados sobre o cooperador
- base : base de conhecimento
- conc : conceitos
- rast : rasters
- atri : atributos
- valu : valores
- valo : valores possíveis
- regr : regras
- regr : regra
- linh : linha da regra

A diferença principal entre este daemon e o editor é a impossibilidade de criar novos ficheiros de conhecimento, uma vez que só está desenhado, por questões de segurança (5), para alterar os ficheiros já existentes. No entanto, esta falta não é muito importante, uma vez que a criação de novos agentes implica um processo local, não possível através da internet.

Voltar ao índice

5.2. Estrutura modular do programa

A estrutura interna, bem como a relação com o restante sistema é muito semelhante á do Editor, sendo a única diferença o tipo de interface:

Imagem 19

Voltar ao índice

5.3. Esquema de representação do conhecimento

Ver secção 3.3.

Voltar ao índice

5.4. Ambiente de desenvolvimento

Todo o daemon foi desenvolvido em C++, utilizando o compilador g++ da Gnu, podendo ser compilador em qualquer máquina UNIX que suporte este compilador.


Voltar ao índice

5.5. Avaliação do resultado e possíveis melhoramentos

Foram satisfeitos todos os requisitos necessário neste programa.

À semelhança do que acontece com o Editor, os melhoramentos possíveis no programa seriam:

- alteração das estruturas de informação para aumento da rapidez de procura de informações;
- alteração dos algoritmos de leitura dos ficheiros Prolog;

Voltar ao índice

5.6. Exemplo de uma execução

Executando um telnet ao computador e porta correcta, podemos interagir directamente com o daemon através de comandos. Uma sequência destes e respectivas respostas é agora apresentada como exemplo:

Imagem 20

O utilizador começa por ler os dados do agente ambiente e social (load [enter] ambsoc [enter]). Pede depois uma listagem do autoconhecimento do agente (get [enter] auto [enter]), o que mostra informações sobre o agente e o primeiro dado sobre o seu autoconhecimento. De seguida faz o mesmo para a base de conhecimentos (get [enter] base [enter]).

Imagem 21

Neste próximo exemplo o utilizador começa por introduzir novos conhecimentos, não lendo dados de nenhum agente. O processo é como o descrito anteriormente. O utilizador desliga depois a ligação (hold [enter]).

Voltar ao índice


6. Daemon de interface com os agentes

Com uma interface de comandos, e possibilitando tanto uma interacção com o interface Web como com qualquer outro interface que possa ser posteriormente executado, este daemon recebe através de sockets TCP os pedidos e da mesma maneira que o interface utilizador local do sistema, envia os pedidos aos agentes, esperando as respostas. Ao contrário deste, no entanto, o daemon organiza todas as informações na memória (não as mostrando apenas no ecrã) para as poder operar e a partir delas poder apresentar uma explicação do funcionamento do sistema.

Voltar ao índice

6.1. Funcionalidades

Apresenta-se agora uma listagem dos comandos possíveis e funcionalidades correspondentes:

- kill : termina o daemon, desligando-o da porta que ocupa
- hold : desliga a ligação mas não termina o daemon
- fact : pergunta dados relativos a um facto (é necessário introduzir o metaconceito, conceito requeridos e o perito a questionar)
- regr : pergunta dados relativos a uma regra (é necessário introduzir o nš da regra e o perito a questionar)
- expl : mostra a explicação relativa à última conclusão do sistema
- area : permite escolher a área máxima e mínima que o sistema deve ter em conta
- cama : permite escolher a camada de fundo a apresentar no GIS, de entre as seguintes:
- relevo
- uso
- geologia
- textura
- florestal
- cons : permite escolher a construção pretendida, de entre as seguintes:
- escolar (escola)
- poluente (indústria poluente)
- npoluente (indústria não poluente)
- cimento (indústria de cimento)
- peri : permite escolher o perito de entre os seguintes:
- ambsoc (ambiente e sociologia)
- coneco (construção e economia)
- conope (controlo de operações)
- basdad (base de dados)

Voltar ao índice

6.2. Estrutura modular do programa

Pode-se dividir este daemon em quatro módulos distintos:

- Interface TCP (que permite a comunicação com o utilizador)
- Interface UDP (que trata das comunicações com os agentes)
- Base de dados das informações recebidas dos agentes
- Processamento de dados (responsável pela tradução das mensagens recebidas e enviadas para os agentes para interacção com a base de dados)

Imagem 22

Voltar ao índice

6.3. As comunicações com os agentes

Os agentes do SMAPInG interactuam utilizando sockets UDP, sendo por isso necessário que este daemon utilize também este tipo de comunicação para poder fazer pedidos e receber respostas.
No entanto, e dado os agentes terem sido escritos em Prolog, utilizam um formato de mensagens adequada a essa linguagem, mas pouco eficiente para o C++. Foi necessário, assim, analisar a fundo as comunicações efectuadas, bem como o código Prolog que leva à construção e leitura das mensagens, de modo a de certa maneira "filtrar" as comunicações, tentando encontrar as partes importantes e as redundantes destas.

Voltar ao índice

6.4. Ambiente de desenvolvimento

Tal como o daemon anterior, todo o programa foi implementado em C++ e compilado com o g++ da Gnu.

Voltar ao índice

6.5. Avaliação do resultado e possíveis melhoramentos

No que diz respeito à substituição do interface original do SMAPInG, todas as possibilidades foram tidas em conta e reproduzidas (excepto no que toca à interacção com o GIS). Algumas melhorias se podem fazer em relação às explicações fornecidas pelo daemon, sendo esta, no entanto, uma questão mais relacionada com os próprios agentes e não com o daemon.
Assim, seria necessário incorporar nos agentes mecanismos que dessem uma visão mais clara do seu funcionamento, do modo a que pudessem transmitir esses dados ao daemon para posterior visualização.

Voltar ao índice

6.6. Exemplo de uma execução

Através de um telnet ao computador e porta correcta, podemos interagir directamente com o daemon através de comandos. Uma sequência destes e respectivas respostas é agora apresentada como exemplo:

Imagem 23

O utilizador começa por escolher o perito "ambiente e sociologia" (perito [enter] ambsoc [enter]), fazendo depois uma questão relativa à regra nš1 deste mesmo perito (regr [enter] 1 [enter] ambsoc [enter]), ao que o sistema responde com a descrição da regra.
Depois, faz de maneira semelhante uma questão em relação a um facto, perguntando dados sobre o metaconceito environmentRaster e conceito bugsites ao perito ambsoc. A resposta é dada pelo perito, indicando não conhecer nada sobre os estragos na ecologia (isto indica que o perito tem conhecimento deste metaconceito e conceito, mas neste momento o sistema não tem qualquer dados sobre estes). Os comando utilizados são: fact [enter] environmentRaster [enter] bugsites [enter] ambsoc [enter].
O utilizador realiza depois uma mudança nas áreas: area [enter] 2500000 [enter] 50000 [enter].

Imagem 24

Neste caso, o utilizador inicia o sistema (start [enter]) e depois pede explicações (expl [enter]), desligando depois a ligação.
( É de referir que as explicações vistas deste modo não são utilizáveis; todo o trabalho de apresentação das explicações é realizado por CGIs ).

Voltar ao índice


7. Visão geral do SMAPInG

Depois de uma explicação pormenorizada de todos os módulos executados neste projecto, é necessário analisar, no conjunto, o impacto que estes trouxeram ao funcionamento do SAMPInG. Começando por uma representação esquemática do sistema existente no início deste projecto, temos:

Imagem 25

O SMAPInG é um sistema distribuído, com processos colocados em máquinas separadas, em que o utilizador se dirige ao computador no qual funciona o agente interface com o utilizador, através do qual interage com o sistema.
Cada um dos agentes pode ser visto da seguinte forma:

Imagem 26

Após a introdução de todas as novas funcionalidades, objectivos finais deste projecto, temos :

Imagem 27

O SMAPInG torna-se um sistema distribuído, acessível de qualquer local, através da internet, sendo possível tanto a utilização normal, como a alteração do conhecimento dos agentes constituintes.
O sistema fica também mais versátil sendo mais fácil a criação de novos agentes, bem como migração dos agentes já existentes para outras máquinas, graças às facilidades trazidas pelo Editor.


Voltar ao índice

8. Conclusão

O objectivo deste projecto foi a melhoria das funcionalidades do SMAPInG, tendo em conta as restrições e falhas existentes. Foi dada principal atenção à possibilidade da utilização de modo remoto (através da internet) do sistema, oferecendo quase todas as funcionalidades que se encontram na interface local.
Embora não se tenha possibilitado a visualização dos mapas criados pelo GIS, limitando um pouco a utilização (uma primeira melhoria ao sistema agora desenvolvido será mesmo a implementação de um interface que permita às páginas Web aceder às imagens em formato gif ou jpg, para estas poderem ser mostradas através dos browsers).

Importante foi também o desenvolvimento do Editor (e do daemon que permite algumas das suas funcionalidades através da Web), pois criou-se um ambiente mais amigável para a alteração do conhecimento e possível introdução de novos agentes.

A possibilidade de apresentar explicações do funcionamento do sistema foi também implementada, tendo no entanto de se utilizar a observação das comunicações entre agentes para construir a informação relevante para o utilizador. Uma solução mais elegante e mais útil para este problema (e mais uma possibilidade para a melhoria do sistema) passa pela alteração do funcionamento dos agentes de maneira a eles próprios manterem informações relativas à maneira de como chegaram a certas conclusões e como interagiram com os seus cooperantes.

Não posso deixar, nesta altura, de referir uma questão que pode não ser óbvia para quem tem um primeiro contacto com este projecto: uma das maiores dificuldades que este trabalho apresentou foi a familiarização com o sistema já desenvolvido e todo o trabalho de "investigação" que foi necessário fazer para compreender o funcionamento do sistema.
Assim, muito tempo foi gasto a analisar código já escrito, e a analisar a comunicação dos agentes, de modo a poder introduzir no sistema as novas funcionalidades.

Para finalizar, pode-se verificar que o funcionamento de um sistema deste tipo é perfeitamente viável, sendo perfeitamente possível a sua utilização remotamente via Web. É possível o alargamento do sistema, por inclusão de novos agentes, bem como a alteração dos seus conhecimentos, de uma maneira relativamente simples sem a necessidade de recorrer à escrita de código, e com uma interface amigável.

Voltar ao índice


9. Bibliografia

DARNELL, Rick, et al., "HTML 4 Unleashed", Sams.Net Publishing, 1997.

HOROWITZ, Ellis, SAHNI, Sartaj e MEHTA, Dinesh, "Fundamentals of Data Structures in C++", Computer Science Press, 1995.

KERNINGHAN, Brian W. e RITCHIE, Dennis M., "The C Programing Language, Second Edition", Prentice Hall, 1988.

LIPPMANN, Stanley B., "C++ Primer", Addison Wesley Publishing Company Inc, 1989.

MALHEIRO, Nuno Filipe Teixeira, "SMAPInG - Sistema MultiAgente Para Informação Geográfica", Seminário/Projecto, FEUP, 1997.

STEVENS, W. Richard, "Advanced Programming in the UNIX Environment", Addison Wesley Publishing Company Inc, 1992.


Dynamic HTML Lab - WebReference.com (http://www.webreference.com/dhtml/)

WebCoder.com - JavaScript and Dynamic HTML on the Web (http://webcoder.com/)

WebDeveloper.com - Building Web sites, Java and JavaScript (http://www.webdeveloper.com)

Microsoft HomePage(http://www.microsoft.com)

Netscape HomePage (http://www.netscape.com/)

Beejīs Guide to Netwaork Programming - using internet sockets (http://www.ecst.csuchico.edu/~beej/guide/net)

The Xforms Homepage (http://bragg.phys.uwm.edu/xforms)



Voltar ao índice

Apêndice A. Dados de referência sobre o SMAPInG

Para uma melhor compreensão do sistema, dos ficheiros mais importantes do sistema, sua localização, compilação e execução, apresenta-se de seguida uma lista dos módulos do SMAPInG, informação neles contida, e indicações relativas à instalação dos daemons, páginas Web e CGIs, bem como uma explicação de como se pode proceder para incluir novos agentes no sistema.

Localizados no Turing (conta ntm) estão os ficheiros comuns aos agentes inteligentes (directoria Common) que tratam da lógica difusa (logica_difusa), do tratamento de mensagens (mensagens), o motor de inferência (inferenceEngine), o monitor de comunicações (intelliMonitor) e o tratamento de questões (intelliQuestions). Os ficheiros específicos de cada agente estão localizados na directoria correspondente a cada agente.
No Newell estão localizados ficheiros necessários ao funcionamento do agente gis.
Para correr o SMAPInG localmente, utilizando o interface no turing, corre-se o ficheiro START. Este ficheiro coloca em funcionamento todos os agentes, incluindo o de interface de utilizador.

O Editor está localizado na directoria Editor, também no turing, onde pode alterar todos os ficheiros de conhecimento aí localizados, bem como criar novos ficheiros.

O interface Web encontra-se na directoria html, e o CGIs na directoria html/htbin (os CGIs não se encontram compilados, uma vez que aquando da apresentação do projecto foi utilizado o servidor Web do tom e não um servidor localizado no turing). Para o bom funcionamento da interface Web, os CGI devem ser alterados para coincidir com a máquina na qual estão instalados e devem residir numa directoria htbin, dentro da directoria que contém as páginas html.

Os daemons estão colocados na directoria Daemon e também não estão compilados, pela mesma razão referida acima, sendo também necessário, se se quiser colocá-los em funcionamento noutro computador, alterar alguns dados no próprio programa (nome da maquina e socket).
O sistema está implementado para que o editorDaemon funcione na porta 6633 e o userDaemon na porta 3366, mas estes números podem ser alterados, desde que se procedam a alterações nos CGIs.
Para correr o SMAPInG para utilização remota via Web deve-se correr o ficheiro STARTWeb. Este ficheiro coloca em funcionamento todos os agentes, excepto o de interface utilizador, e também os daemons.

Para colocar em funcionamento novos agentes, é necessário fazer uma nova directoria com ficheiros equivalentes aos agentes já construídos, alterar o seu conhecimento (através do Editor, por exemplo) e alterar os conhecimentos dos outros agentes de modo a que reconheçam o novo cooperador.

Voltar ao índice


(1) adicionando os dados relativos a um novo cooperador a todos os agentes existentes no sistema, construindo a base de conhecimento desse novo agente e criando-o (ver apêndice B para indicações de como adicionar um agente) facilmente se pode expandir o sistema. voltar

(2) por "crisp" refiro-me ao contrário de difuso, isto é, o grau de pertença de um elemento a um grupo pode ser apenas 1 ou 0 (sim ou não), em contraste com a possibilidade de vários graus de pertença entre 0 e 1. voltar

(3) na realidade, a falta de consenso entre os diferentes produtores de browsers levou ao aparecimento de incompatibilidades, que no entanto, com um pouco de cuidado, podem ser torneadas (estamos numa altura um pouco conturbada relativamente a estas questões, mas espera-se que dentro de pouco tempo a definição do HTML 4 pela W3C venha a "acalmar" esta situação). voltar

(4) a apresentação através da Web do ecrã do GIS GRASS não foi implementado, sendo uma das possibilidades para uma futura melhoria no sistema. voltar

(5) não é boa prática dar a possibilidade, através da internet, de observar e alterar a estrutura de ficheiros de um computador, pois pode levar a tentativas de corrupção de discos ou outras práticas não muito agradáveis para o gestor da máquina. voltar

Jorge Cunha de Sequeira Amaral