Anais do XV SEMINCOSeminario de Computacao

20 a 22 de Novembro de 2006FURB - Campus IV - Blumenau/SC

Promocao

Universidade Regional de Blumenau - FURBPro-Reitoria de Extensao e Relacoes Comunitarias - PROERCCentro de Ciencias Exatas e Naturais - CCENDepartamento de Sistemas e Computacao - DSCCentro Academico Livre de Computacao - CALCOMP

Comissao Organizadora

Prof. Everaldo Artur Grahl (Coordenador)Prof. Alexander Roberto ValdameriProf. Antonio Carlos TavaresProf. Jomi Fred HubnerProfa. Joyce MartinsProf. Jose Roque Voltolilni da Silva

Ficha Catalografica Elaborada pela Biblioteca da FURB

Seminario de Computacao (15.: 2006 : Blumenau, SC)

Anais do XV SEMINCO / promocao Universidade Regional de Blumenau, Departamentode Sistemas e Computacao; Everaldo Artur Grahl, Jomi Fred Hubner (coordenado-res). - Blumenau, O Departamento, 2006. 228 p. : il.

1. Computacao - Congressos. I. Grahl, Everaldo Artur. II. Hubner, Jomi Fred. III.Universidade Regional de Blumenau. Departamento de Sistemas e Computacao. IV.Tıtulo.

CDD 004

Universidade Regional de Blumenau

ReitorProf. Eduardo Deschamps

Vice-ReitorProf. Romero Fenili

Diretor do Centro de Ciencias Exatas e NaturaisProf. Sergio Stringari

Chefe do Departamento de Sistemas e ComputacaoProf. Mauro Marcelo Mattos

Coordenador do Colegiado do Curso de Ciencias da ComputacaoProf. Alexander Roberto Valdameri

Coordenador do Colegiado do Curso de Sistemas de InformacaoProf. Francisco Adell Pericas

Apresentacao

A Universidade Regional de Blumenau - FURB, atraves do Departamentode Sistemas e Computacao, realiza o XV Seminario de Computacao (SE-MINCO) entre os dias 20 e 22 de novembro de 2006. Este ano, em especial,comemoramos quinze anos deste evento que teve sua primeira edicao emmaio de 1992. Em toda sua trajetoria manteve a tradicao de publicacao deartigos cientıficos e apresentacao de palestras tecnicas contribuindo para odesenvolvimento da computacao.

Para comemorar a data, e demonstrar o carater inovador que originou, em1975 o Curso Tecnico de Nıvel Superior em Processamento de Dados, daFaculdade de Ciencias Economicas de Blumenau (oitavo curso do paıs e pri-meiro do sul do Brasil), a FURB , em parceria com a Prefeitura Municipalde Blumenau, lancou o projeto Blumenau Games. O objetivo e transformara cidade em uma referencia nacional de formacao de recursos humanos eoferta de servicos para o segmento de games. O Blumenau Games inte-grara o Programa Santa Catarina Games, do governo do Estado, atraves daempresa SC Parcerias. Entre as acoes previstas para fomentar o segmentoem Blumenau esta o evento Games – Blumenau, que ocorrera no dia 22de novembro, durante o SEMINCO. Entre as palestras previstas, estao: “OMercado Mundial de Games e o Potencial de Santa Catarina” e “O MercadoBrasileiro de Jogos para Celular – situacao e desafios”.

Este ano tivemos a submissao de 62 artigos provenientes de varias insti-tuicoes e empresas do paıs, sendo que destes foram aprovados 20 artigos dasseguintes universidades e empresas: FURB, UDESC, UFSC, UNIVALI,USP,CTA, UFF, UNISINOS, URI, FEEVALE, UFRGS, UCDB, CESUPA, UFPA. Aorganizacao dos artigos nestes anais e feita conforme as seguintes areas deconhecimento: Computacao Grafica, Engenharia de Software, Informaticana Educacao, Inteligencia Artificial, Integracao Hardware/Software, Rede deComputadores e Teoria da computacao.

Agradecemos a todos os envolvidos na organizacao do evento, bem como aComissao de Avaliacao Interinstitucional que nao mediu esforcos em avaliaros diversos artigos submetidos a chamada de trabalhos. Esperamos que nostres dias de realizacao do evento as expectativas dos participantes sejamatendidas e tenhamos um grande evento.

Comissao Organizadora

Agradecimentos

Sociedade Brasileira de Computacao - SBCComissao de Avaliacao InterinstitucionalProjeto Acredito - FURB

Comissao de Avaliacao Interinstitucional

Adelmo Luis Cechin (UNISINOS - RS)Adriana G. Alves (UNIVALI - SC)Alexander Roberto Valdameri (FURB - SC)Anita da Rocha Fernandes (UNIVALI - SC)Antonio Carlos Tavares (FURB - SC)Claudio Loesch (FURB - SC)Dalton Solano dos Reis (FURB - SC)Denio Duarte (Unochapeco - SC)Edson Satoshi Gomi (USP - SP)Everaldo Artur Grahl (FURB - SC)Fabiane Barreto Vavassori (FURB - SC)Fabio Rafael Segundo (FURB - SC)Fernando Santos Osorio (UNISINOS - RS)Francisco Adell Pericas (FURB - SC)Gerson Cavalheiro (UNISINOS - RS)Giovane Roslindo Kuhn (UFRGS - RS)Gustavo G. Lugo (FACET - PR)Jomi Fred Hubner (FURB - SC)Jose Roque Voltolini da Silva (FURB - SC)Joyce Martins (FURB - SC)Leandro Fernandes (UFRGS - RS)Manuel Menezes de Oliveira Neto (UFRGS - RS)Marcel Hugo (FURB)Marcello Thiry (UNIVALI - SC)Maria Ines Castineira (UNISUL - SC)Mauro Marcelo Mattos (FURB - SC)Maurıcio Capobianco Lopes (FURB - SC)Miguel Alexandre Wisintainer (FURB - SC)Paulo Cesar Rodacki Gomes (FURB - SC)Paulo Fernando da Silva (FURB - SC)Rafael Cancian (UNIVALI - SC)Rafael Heitor Bordini (University of Durham - UK)Renata Vieira (UNISINOS - RS)Roberto Heinzle (FURB - SC)Tiaraju Diverio (UFRGS - RS)Valguima Victoria Vianna Aguiar Odakura (USP - SP)Vera R. N. Schuhmacher (UNISUL - SC)

Artigos Selecionados

Computacao Grafica

Utilizando o 3D Studio Max como Level Editor para Construcao deCenarios para Ogre3D

9

Jorge. L. Salvi, Maikon. C. Santos e Jacques. D. Brancher (URI)

Topolino: Software Livre para Automatizacao do Experimento doCampo Aberto

19

Bruno Brandoli Machado, Jonathan de Andrade Silva, Wesley NunesGoncalves, Hemerson Pistori e Albert Schiaveto de Souza (UCDB)

Inspecao Visual Industrial Automatizada por Analise de Forma comDescritores de Fourier e Redes Neurais Artificiais

29

Mauricio Edgar Stivanello e Paulo Cesar Rodacki Gomes (FURB)

Engenharia de Software

AOPDelphi: Prototipo de um weaver para programacao orientada aaspectos em Delphi

41

Edmar Soares de Oliveira e Marcel Hugo (FURB)

AWSA - Ambiente web de suporte a avaliacoes da qualidade deprodutos de software

53

Everaldo Artur Grahl e Jonathan Manoel Borges (FURB)

Delphi2Java-II: uma ferramenta para conversao de formularios Delphiem codigo Java

65

Mauro Marcelo Mattos, Joyce Martins, Israel Damasio Medeiros e JaniraSilveira (FURB)

Informatica na Educacao

Informatica na Educacao: ensino presencial e educacao a distancia 75

Ana Isabel de Azevedo Spinola Dias e Wanderley Moura Rezende (UFF)

Um RPG Educacional Computadorizado e Missoes Contextualizadascom seus Ambientes

85

Michele A. Tobaldini e Jacques D. Brancher (URI)

Sistema Integrado e Visualizacao de Conteudos de 5a a 8a SeriesUtilizando X3D

97

Luis Biondo, Andre Brandao, Michele Tobaldini e Jacques Brancher (URI)

Uma Experiencia de Ensino-Aprendizagem em uma disciplina deProgramacao

109

Mauricio Capobianco Lopes (FURB)

Inteligencia Artificial

Uma Abordagem Inspirada em Insetos Sociais para a Otimizacao daDensidade de Redes de Sensores Sem Fio

119

Carlos Drumm (FEEVALE) e Paulo Roberto Ferreira Jr. (UFRGS)

Evolucao do Caminhar de Robos Moveis Simulados UtilizandoAlgoritmos Geneticos

131

Milton Roberto Heinen e Fernando Santos Osorio (UNISINOS)

AS-MCOE: Tutor inteligente modelado em AgentSpeak(L) 143

Rodrigo R. V. Goulart e Alexandre O. Zamberlam (FEEVALE)

AISO-GT: Um Novo Algoritmo Hıbrido de Otimizacao Baseado nosSistemas Imunologicos Artificiais e na Teoria dos Jogos

155

Andre Ferry Barreira (CESUPA), Carlos Eduardo de Jesus Guimaraes Oliveira(CESUPA), Otavio Noura Teixeira (CESUPA) e Roberto Celio Limao deOliveira (UFPA)

Integracao Hardware/Software

AstroFacil: Sistema Computacional Embarcado para Automatizacaode Telescopios de Pequeno Porte

165

Marcos Roberto Silva, Maicon Carlos Pereira, Caroline Farias Salvador, RafaelLuiz Cancian, Roberto Miguel Torres e Cesar Albenes Zeferino (UNIVALI)

Aplicativo Controlador de Potencia de Pseudo-Satelite e SuasAplicacoes

177

Luiz Eduardo Guarino de Vasconcelos, Durval Zandonadi Jr., FernandoWalter e Jorge Tadano (CTA)

Rede de Computadores

Desempenho de Multicast em Redes Altamente Interconectadas 189

Fernando Teubl Ferreira e Sergio Takeo Kofuji (USP)

Sistemas de Informacao

Estrategias de Escalonamento em um Ambiente de Job-shop 201

Gilberto Iraja Muller e Arthur Torgo Gomez (UNISINOS)

Sistema Web para Gerenciamento do Acesso a um ObservatorioAstronomico

209

Maiara Heil Cancian, Cesar Albenes Zeferino, Rafael Luiz Cancian e RobertoMiguel Torres (UNIVALI)

Teoria da Computacao

Teorema Fundamental da Aritmetica e Numeros de Godel Aplicados aCriptografia

221

Vilson Vieira da Silva Jr., Claudio Cesar de Sa, Rafael Stubs Parpinelli eCharles Christian Miers (UDESC)

Utilizando o 3D Studio Max como Level Editor para Construção de Cenários para Ogre3D

Jorge. L. Salvi, Maikon. C. Santos, Jacques. D. Brancher

Departamento de Engenharias e Ciência da Computação – Universidade Regional Integrada do Alto Uruguai e das Missões (URI) – Erechim, RS – Brasil jlsalvi@hotmail.com, maikoncs@gmail.com, jacques@uri.com.br

Resumo. O objetivo deste artigo é apresentar a estratégia adotada para construção de cenários dinâmicos e estáticos para o jogo “Taltun: A terra do conhecimento”. A proposta foi elaborar cenários através do uso do programa de modelagem, o 3D Studio Max, e exporta-los diretamente para a engine do jogo sem a necessidade de se desenvolver ou fazer uso de um level editor especial para elaborar as fases do jogo.

1. Introdução A utilização de editores de fases (level editor) é o meio mais comum para o desenvolvimento de fases em jogos de computador. Segundo Rouse III [2000] o level editor tem grande importância no desenvolvimento de um jogo porque permite ao designer montar suas fases através da movimentação dos objetos em 2D enquanto eles podem ser visualizados em um mundo 3D, obtendo assim, uma perspectiva do final da fase do jogo.

Com a utilização do level editor é possível inserir elementos gráficos (estáticos ou dinâmicos), luzes, câmeras entre outros elementos que podem compor a cena. Ainda, os editores possibilitam manipular os objetos da cena, para que eles se ajustem ao ambiente a ser criado. Segundo Clua e Bittencourt [2005] as manipulações básicas são as seguintes: seleção, translação, rotação e escalonamento.

Como geralmente um level editor é desenvolvido especialmente para uma única engine e seu desenvolvimento consome um tempo considerável, torna-se fundamental, em projetos de curto espaço de tempo, que os programadores tenham seu tempo enfocado na codificação da engine. No entanto, uma maneira de contornar este problema é adaptar as ferramentas de trabalho já existentes para a confecção dos cenários, neste caso a ferramenta de modelagem 3DS Max.

Nas próximas seções serão apresentados os trabalhos correlatos, as ferramentas utilizadas para a confecção deste trabalho e em seguida como foi projetado e como funciona o level editor em questão.

2. Trabalhos Relacionados A maioria das engines de jogos populares possuem editores de fases para possibilitar aos usuários a modificação das características das mesmas assim como a criação de novas delas. Segundo El-nasr e Smith [2006] o processo de modificação e criação de fases é conhecido como modding.

Dentre os editores de fases mais conhecidos podemos citar os dos jogos WarCraft III [2006] e Half Life 2 [2006] e da engine 3D Game Studio [2006]. Todos eles possuem características idênticas em seus editores, mas, além disso, eles podem possuir também outros artefatos que implementam suas funcionalidades, tais como editores de triggers e de sons.

Já na engine Yake [2006], o uso do 3DS Max torna-se fundamental. Isto ocorre devido ao fato de ela conter plugins responsáveis por exportar as propriedades do cenário modelado em um arquivo XML. A partir disso, o loader de gráfico (OGRE) e de física (ODE ou Novodex) buscam as propriedades exportadas a fim de construir a cena de forma idêntica àquela modelada.

Neste mesmo ramo também podemos ressaltar o trabalho realizado por Watsa [2001] no qual é explicado como o 3DS Max é utilizado para a construção de fases para a engine de seu jogo. Para isso foram usadas as características existentes no 3D Max e customizadas através da criação de plugins e scripts, os quais tornam possível a criação de fases para jogos de computador.

3. Ferramentas Utilizadas Para a produção do jogo Taltun [2006], desenvolvido pelo projeto RPGEDU [2006] (Role Playing Game Educacional), são envolvidas diversas ferramentas. No entanto, restringe-se neste trabalho a apresentação das ferramentas relacionadas à construção de cenários.

Na construção gráfica dos cenários é utilizado o programa 3D Studio Max [2006] ou 3DS Max. Este é um programa de modelagem 3D que permite criar animações e renderizar imagens. Sendo usado em produção de filmes de animação, vinhetas, comerciais para TV, maquetes eletrônicas e na criação de jogos eletrônicos.

Para a renderização dos gráficos gerados pela ferramenta citada acima dentro da engine do jogo é usado o OGRE [2006] (Object-Oriented Graphics Rendering Engine). “O propósito do OGRE não é ser um game engine; ele é um rendering engine genérico que pode ser incorporado a outras bibliotecas...” Maior [2005] dando assim suporte ao desenvolvimento de jogos 3D.

Ainda, para dar maior dinamismo e realismo ao jogo, é utilizada uma API de física: a OPAL [2006] (Open Physics Abstraction Layer). Sua principal característica é manipular fenômenos físicos envolvendo articulação de corpos, gravidade, detecção de colisão, atrito e outros fenômenos físicos envolvendo objetos em mundos virtuais.

A OPAL proporciona uma interface de alto nível para motores de física de baixo nível utilizados em jogos e em outras aplicações. Atualmente na versão 0.4 suporta somente a biblioteca ODE (Open Dynamics Engine) e em atual desenvolvimento dará suporte a TrueAxis (True Axis Physics SDK).

4. O 3DS Max como Level Editor Para Watsa [2001] uma das razões para se utilizar o 3DS Max como level editor é a reutilização das suas janelas de visualização. Outro motivo de seu uso é o aproveitamento das propriedades dos objetos modelados e o uso dos eventos de manipulação.

Entretanto, para se produzir um cenário completo para o jogo são utilizados os recursos citados acima. Também é necessário seguir uma seqüência de passos especificados conforme a Figura 1.

Figura 1: Fluxo para criação de um cenário.

O processo é iniciado com a modelagem, texturização e configuração da presente cena que em seguida será exportada através dos plugins do 3DS Max. Com isso serão gerados os arquivos que contêm as informações dos objetos e da cena a fim de serem carregados pelo loader da engine.

Com o final do processo de loader, obtém-se um ambiente com objetos dinâmicos e estáticos e com as propriedades e coordenadas especificadas no 3DS Max.

A seguir será exibido o método adotado para criação de cenários. Este está dividido em duas partes: o plugin e o loader da engine.

4.1 O plugin

Para que os objetos modelados usados na construção de cenários contenham as propriedades necessárias para atribuir física e gráficos foi preciso desenvolver um plugin para o 3DS Max. Este plugin foi desenvolvido para funcionar com o 3D Studio Max 6 e está dividido em duas partes: o modificador e o exportador, conforme apresentado na Figura 2. Cada um deles trabalha de forma distinta, sendo que o primeiro é responsável por adicionar novos atributos ao objeto, já o último exporta os atributos dos objetos para posterior utilização pela engine.

Figura 2: Modificador do 3DS Max para adição das propriedades de física (à esquerda) e o exportador (à direita).

Quando a modelagem dos objetos estiver concluída é necessário adicionar à sua lista de modificadores o elemento “Opal Scene”, que se refere à primeira parte do plugin. Com este modificador são acrescentados novos atributos ao objeto, que servem para configurar as propriedades de física a ser aplicada ao objeto quando carregado ao jogo.

Um exemplo da utilização das propriedades de física dispostas pelo plugin é criação dos limites por onde o personagem pode andar pelo ambiente. Estes limites são feitos através de caixas de colisão, que formam uma espécie de labirinto, no qual o jogador apenas poderá navegar entre elas, conforme apresentado na figura a seguir.

Figura 3: Exemplo de utilização do plugin para criação dos limites para

navegação do personagem.

Após a configuração de todos os objetos que irão compor a cena então é feito o uso da segunda parte do plugin: o exportador. Este tem como escopo gerar um arquivo XML que conterá as informações aplicadas com o modificador e também informações relacionadas coordenadas gráfica do objeto em questão. Um exemplo de XML gerado pelo plugin pode ser visto na Figura 4.

Figura 4: Exemplo de XML gerado pelo plugin de exportação.

Conforme observado acima, cada objeto será representado por um nodo dentro da cena. Este nodo contém atributos referentes à sua posição, rotação, escala, dimensão e raio (quando vem ao caso). A partir destes atributos é que o objeto especificado na tag entidade irá se dispor no mundo virtual.

A tag de física especifica que tipo de geometria (caixa, esfera ou malha) será utilizada para a colisão dos objetos. Ainda é definido se o objeto será dinâmico ou estático, o tipo de renderização (somente gráfico, somente física ou ambos) e outras propriedades referentes ao comportamento do objeto durante a simulação.

Contudo, ainda falta exportar a parte que compõe o gráfico do objeto. Para isto é utilizado o plugin “3D Studio Max Exporter for meshes and animation” da Ogre, gerando também um arquivo XML que em seguida é convertido para a extensão “.mesh” pelo programa OgreXMLConverter.

4.2 O loader

Logo após a exportação das especificações para a criação do ambiente virtual, contidos no arquivo XML gerados pelo plugin, começa a etapa final do processo, no qual carrega as informações contidas no arquivo e cria os objetos que irão compor a cena conforme o que foi modelado no 3DS Max.

Um ambiente é formado por um ou vários nodos (objetos). O loader tem como ponto partida o caminho do arquivo XML, fazendo a leitura dos dados e armazenando em memória as informações de cada nodo para que os mesmos possam ser criados no futuro.

A criação dos nodos pode ser feita de modo flexível e dinâmico, tendo a possibilidade de criar, tanto objetos em tempo de execução da aplicação (durante o jogo), quanto no carregamento da cena. Além disso, o loader fornece suporte para criação de todos os nodos em um único comando ou ainda através do índice ou nome de cada elemento.

O processo de criação de um nodo envolve dois elementos imprescindíveis: o uso da OGRE, para os objetos gráficos, e da OPAL, para criação de sólidos utilizados na simulação da física. As informações contidas no XML é que determinarão como cada nodo vai ser criado.

A primeira fase de criação de um nodo é a criação do sólido que simula a física do objeto, atribuindo sua posição, orientação e escala. A partir deste ponto, então é definida a geometria do sólido e acrescentadas as propriedades de físicas (atrito, densidade, etc).

Ao final da etapa de criação do nodo é construída a entidade gráfica, correspondente à rederização do objeto, no qual é anexado o arquivo .mesh correlato ao nodo. Após gerado, a cena passa a conter mais um objeto, sendo ele estático ou dinâmico. Se dinâmico há a possibilidade do objeto se mover através da aplicação de uma determinada força. Assim sendo, a entidade gráfica deve ter as mesmas coordenadas do sólido que simula a física.

Por este motivo, o loader necessita ser atualizado dentro do rendering da aplicação, para que a física e a parte gráfica estejam coerentes, gerando a simulação gráfica dos objetos dinâmicos de uma forma concisa.

Uma outra característica que incorpora este loader é o gerenciamento dos objetos após sua criação, possibilitando atribuir e obter dados sobre os nodos, tais como posição, velocidade atual, entre outras propriedades gráficas e de física.

Após o processo de loader, o cenário modelado no 3DS Max (Figura 3) fica como ilustrado a seguir. Aqui as caixas de colisão não são renderizadas, porém as propriedades de física aplicada a elas estão ativas. Sendo assim, quando o personagem, representado por uma esfera dinâmica, entrar em intersecção com as caixas, então o personagem automaticamente fica bloqueado para andar naquela direção.

Figura 5: Exemplo de cenário após o loader.

5. Como exportar um cenário O processo para exportação de cenário para o jogo é iniciado com o uso do 3D Max. Tendo em mãos os objetos modelados e texturizados é necessário adicionar a eles o modificador “Opal Scene”. Com este é feita a configuração de como o objeto irá agir quando efetuado o loader na engine.

Posteriormente, é feita a seleção dos objetos a serem exportados e em seguida executado o plugin de exportação das malhas (octopus export). Dando seqüência ao processo, falta ainda exportar o arquivo XML com a descrição básica dos objetos selecionados. Para isto usamos o plugin “Opal Scene Export”. Os dois processo de exportação não exigem nenhum

Com estes passos acima já finalizados, agora passamos para a parte de programação C++. A primeira coisa a ser feita é indicar o caminho de onde estão os arquivos gerados na etapa anterior. Depois, é preciso criar o gerenciador de objetos da aplicação, dentro do construtor da classe correspondente a cena, e em seguida apontar o arquivo XML que irá compor a cena, através do código especificado abaixo. Assim, serão carregadas todas as malhas dos objetos em seus devidos locais e, quando especificado, também com a física dinâmica ou estática.

this->graphicPhysicalLoader->addDotScene("../../scene/Gomles.scene"); this->graphicPhysicalLoader->createAll();

É importante salientar que quando os objetos possuem propriedades de física é necessário que os mesmo sejam atualizados no render da aplicação. Para isso, basta inserir a linha de código abaixo passando como parâmetro o delta time da aplicação. Por fim, basta apagar o gerenciador de objetos dentro do destrutor da classe.

this->graphicPhysicalLoader->update(OGRE::real DeltaTime);

Contudo, é possível verificar a simplicidade de se adicionar um novo cenário ao jogo, pois a parte que realmente leva tempo para desenvolver fica focada na modelagem e texturização dos objetos.

6. Dificuldades Encontradas Para desenvolver este trabalho foram encontradas diversas dificuldades. Dente elas podemos citar uma que surgiu durante a exportação das malhas, pois no 3D Max o eixo que corresponde a altura é o Z enquanto na OGRE é o Y. Ainda, verificou-se que os objetos modelados deveriam ter seu pivô centralizado, pois senão, quando exportado, as malha não ficariam nas posições especificadas. Estes itens exigiram que fossem feitos uma infinidade de testes para se chegar ao resultado esperado.

Quanto à parte de programação, o que mais exigiu dedicação foi na construção de um loader genérico para carregar os objetos com colisões do tipo caixa, esfera e malha. Além disso, no gerenciamento dos objetos das cenas também foram encontradas dificuldades, pois além do controle de memória era necessário também dispor todas as funções de manipulação gráfica e da física para que se pudesse acessar e/ou controlar os objetos.

Contudo, todas as dificuldades estavam direcionadas no ajuste da parte gráfica com a parte de física dos objetos, pois se um objeto gráfico fosse exportado com posições diferente as da física, então as colisões não seriam coerentes conforme o gráfico. Este caso pode ser exemplificado quando um objeto é lançado de certa altura em direção ao chão, no qual o objeto gráfico pode não chegar ao chão, devido à colisão antecipada, ou, em caso contrário, atravessar o terreno.

7. Conclusão O uso do 3DS Max como level editor juntamente com o loader desenvolvido proporcionou diversos benefícios para o desenvolvimento do jogo. Dentre eles podemos citar o melhor aproveitamento do tempo e de esforço de trabalho dos programadores, a criação de triggers de modo visual e o carregamento automático de objetos estáticos e dinâmicos para o jogo.

Apesar das vantagens apresentadas, o uso desta técnica dificulta ao usuário leigo criar e/ou alterar os cenários, devido a um maior grau de complexidade exigido para manusear a ferramenta e seus plugins. Porém, os usuário com um embasamento básico sobre o 3D Max, é possível efetuar a criação de cenários e a sua exportação sem maiores problemas.

Contudo, apenas o fato de efetuar a carga automática dos objetos estáticos e dinâmicos já torna este recurso útil, pois elimina a necessidade de se configurar manualmente as propriedades de cada objeto que irão compor o ambiente.

Como trabalhos futuros, pretende-se adicionar ao plugin a possibilidade de se criar câmeras e luzes. Outro ponto almejado é desenvolver articulações (joints) para os objetos que contenham física, fazendo com que haja relacionamento forçado entre dois corpos, como é o exemplo de uma dobradiça.

Agradecimentos Agradecemos ao apoio prestado pela FINEP e pela URI – Campus de Erechim que tornaram possível a realização deste trabalho. Parte integrante do projeto RPGEDU – FINEP 1925/2004-0.

Referências 3d Game Studio. (2006). Disponível em: http://www.3dgamestudio.com/ [Acessado em

18 Ago. 2006].

3d Studio Max. (2006). Disponível em: http://usa.autodesk.com/adsk/servlet/index?id=5659302&siteID=123112 [Acessado em 13 Ago. 2006].

Clua, E. W. G. e Bittencourt, J. R. (2005). Desenvolvimento de Jogos 3D: Concepção, Design e Programação. In: XXIV Jornadas de Atualização em Informática (JAI) Part of XXIV Congresso da Sociedade Brasileira de Computação, 22-29 jul. 2005 São Leopoldo. São Leopoldo: UNISINOS, 1313-1357.

El-nasr, M. S. e Smith, B. K. (2006). Learning Through Game Modding. ACM Computers in Entertainment, Vol. 4, No. 1, Jan. 2006. Article 3B.

Half Life 2. (2006). Disponível em: http://www.half-life2.com/ [Acessado em 17 Ago. 2006].

Maior, T. S. et al. (2005). O Engine Gráfico OGRE 3D. In: SBGames 2005 parte do IV Workshop Brasileiro de Jogos e Entretenimento Digital , 23-25 Nov. São Paulo. CD-ROM.

Ogre. (2006). Disponível em: http://www.ogre3d.org/ [Acessado em 12 Ago. 2006].

Opal. (2006). Disponível em: http://ox.slug.louisville.edu/~o0lozi01/opal_wiki/index.php/Main_Page [Acessado em 18 Ago. 2006].

Rouse III, R. (2000). Toiling with Tools. In: 27th International Conference on Computer Graphics and Interactive Techniques, 25-27 Jun. Lousiana - USA. New York: ACM Press, 5-9.

Rpgedu. (2006). Disponível em: http://www.uri.com.br/rpgedu/ [Acessado em 18 Ago. 2006].

Taltun: A terra do conhecimento. (2006). Disponível em: http://www.malisoft.com.br/taltun/webstandards/ [Acessado em 20 Ago. 2006].

WarCraft III. (2006) Disponível em: http://www.blizzard.com/war3/ [Acessado em 18 Ago. 2006].

Watsa, S. (2001). Case Study: Using Max Script for Building Game levels [online] Gamasutra - The Art & Business of Making Games. Disponível em: http://www.gamasutra.com/features/20010824/watsa_01.htm [Acessado em 18 Ago. 2006].

Yake - VR and Game Engine. (2006). Disponível em: http://www.yake.org/ [Acessado em 15 Ago. 2006].

Topolino: Software Livre para Automatizacao doExperimento do Campo Aberto

Bruno Brandoli Machado, Jonathan de Andrade Silva, Wesley Nunes Goncalves,Hemerson Pistori, Albert Schiaveto de Souza

1Universidade Catolica Dom Bosco – UCDB,Av. Tamandare, 6000, Jardim Seminario,Campo Grande, MS, Brasil, 79117–900

{bmachado,jsilva,wnunes }@acad.ucdb.br, {pistori,albert }@ucdb.br

Resumo.A analise do comportamento de camundongose um procedimentobastante comum em estudos fisiologicos e farmacologicos. Nesse artigo,e apre-sentado um software livre baseado em visao computacional e aprendizagem demaquina para a automatizacao dos experimentos realizados com camundongosno teste do campo aberto. Para a analise dos comportamentos de exploracaofoi utilizado aprendizagem de maquina. Os algoritmos de subtracao de fundo,subtracao de fundo adaptativo e segmentador baseado em modelo gaussianoforam utilizados para a segmentacao das imagens. Para o rastreamento doscamundongos foram implementados os algoritmos filtro de Kalman e filtro departıculas. O softwaree capaz de executar os experimentos em tempo real esuporta o rastreamento de multiplos camundongos.

1. Introducao

O estudo do comportamento animale extremamente importante para se obter o co-nhecimento sobre a diversidade de seus costumes [Morrow-Tesch et al. 1998]. Taisestudos fornecem dados importantes para o desenvolvimento de terapias e novosfarmacos. O uso de animais de laboratorio em pesquisas, em particular os camundongos,serve de modelos simplificados do comportamento humano [Fagundes and Taha 2004,Carvalho and Lopes 2006]. Com isso, os camundongos tornaram-se fundamentais emestudos etologicos e permitem que os novos farmacos sejam avaliados antes de seremtestados em seres humanos.

Em diversas pesquisas, o estudo do comportamento animale feito de forma ma-nual. Os registros manuais e a observacao visual em experimentos podem ser realizadoscom um investimento relativamente baixo em relacao a observacao automatica. Porem,deve se considerar que o observador possui a necessidade de presenciar todo o experi-mento para obter as informacoes relevantes nas pesquisas. Dessa forma, o registro manualexige um trabalho exaustivo dos pesquisadores, que pode ser influenciado pela fadiga, oque compromete o registro de comportamentos de interesse.

Com a automatizacao dos sistemas no monitoramento animale possıvel forneceruma estrutura mais confiavel na aquisicao de dados. A observacao automatica e parti-cularmente apropriada para registrar os comportamentos que ocorrem momentaneamenteapos perıodos longos, em que o observador humanoe incapaz de estimar com exatidao

as informacoes espaciais, como por exemplo distancia percorrida e velocidade. Um outroponto significativoe possibilitar a gravacao digital dos experimentos em vıdeo. Assim,o pesquisador pode analisar os comportamentos realizados pelos animais reproduzindo agravacao.

A proposta deste trabalhoe apresentar um sistema computacional para automati-zar a analise de determinados comportamentos de camundongos no teste do campo aberto.O sistemae capaz de processar as imagens capturadas atraves de um dispositivo de baixocusto, como umawebcam, podendo proporcionar a gravacao digital dos experimentosem vıdeo. Uma etapa de processamento das imagens realiza a extracao automatica dosparametros de interesse, utilizando tecnicas de visao computacional e aprendizagem demaquina.

Uma das principais contribuicoes deste trabalhoe apresentar uma alternativa mul-tiplataforma, e de codigos-fonte abertos, aos sistemas atualmente disponıveis no mercado,muitas vezes caros e pouco flexıveis. Alem disso, o pesquisador pode utilizar diversosdispositivos de captura de imagens digitais de baixo custo. O sistema Topolino foi de-senvolvido com fontes na linguagem Java visando portabilidade. Foram utilizados algunspacotes livres, como o ImageJ1 para o pre-processamento das imagens alimentadas pelaetapa de captura de imagens. Para capturar e manipular vıdeos foi utilizado o JMF. OWeka2, outro pacote livre, foi utilizado para classificacao baseada em aprendizagem demaquina. Para o gerenciamento de informacoes utilizou-se o banco de dados relacionalPostgreSQL e o JFreeChart para visualizacao dos graficos. Para o controle de versoes nodesenvolvimento de fontes do sistema utilizou-se o repositorio Subversion, integrado como Trac, um sistema baseado emwebpara o gerenciamento de projetos.

Este artigo esta estruturado em cinco secoes. A Secao 2 descreve algumas ferra-mentas existentes que realizam a analise do comportamento animal. Na Secao 3,e des-crito o teste do campo aberto e as caracterısticas de interesse selecionadas para a execucaodos experimentos com camundongos. Na proxima secao, sao descritos os modulos de-senvolvidos e as caracterısticas do sistema. Finalmente, na Secao 5 sao discutidas aslimitacoes e os pontos positivos do sistema.

2. Trabalhos CorrelatosO Ethovision [Noldus et al. 2001]e uma ferramenta proprietaria para analise do compor-tamento animal. Este sistema foi desenvolvido pela Noldus, uma empresa que atua naarea de tecnologia de informacao. Osoftwarefoi implementado em Visual C++, podendoser executado somente em ambiente Microsoft WindowsTM. A aquisicao de imagens doEthovisione realizada por umhardwarededicado que conecta um dispositivo de capturade imagens ao computador para a execucao do sistema. Pelo sistema ser limitado a estehardware, o usuario fica dependente de um dispositivo especıfico para a sua utilizacao.

O rastreamento do Ethovisione iniciado apos a etapa de aquisicao das imagens. Omodulo de rastreamento utiliza tres tecnicas que possuem limitacoes quantoa eficienciae aplicacao. A primeira tecnicae baseada em limiarizacao nos nıveis de cinza. O limiarpode ser definido pelo usuario ou atraves do proprio sistema. A segunda tecnica con-siste na subtracao de imagens. O usuario define uma imagem de referencia, geralmente

1http://rsb.info.nih.gov/ij/2http://www.cs.waikato.ac.nz/ml/weka/

o fundo sem a presenca do animal, para realizar a subtracao das imagens seguintes quecontem o animal. O resultado da subtracao e uma outra imagem possuindo somente ocamundongo. A terceira tecnicae baseada em cores, onde sao utilizadas as componentesmatiz e saturacao do modelo de espaco de cores HSI (hue, saturation, intensity). Estatecnicae empregada para rastrear multiplos camundongos, entretanto, possui a necessi-dade de pintar parte dos camundongos com uma tinta recomendada pelo sistema.

Ghozland e Granon [Ghozland et al. 2002, Granon et al. 2003] utilizaram o Vi-deoTrack, um sistema desenvolvido pelaViewPoint que analisa o comportamento deexploracao dos camundongos. A captura das imagense feita por uma camera analogica.Existem outras ferramentas que nao sao baseadas em visao computacional, como em[Galsworthya et al. 2005, Kritzler et al. 2006, Kramer and Kinter 2003, Metris 2005], eque empregam dispositivos de radio-frequencia, infravermelho e sistemas eletricos para aidentificacao do animal. Estes metodos intrusivos podem alterar o equilıbrio emocionaldo animal, influenciando nos resultados dos experimentos.

3. Campo Aberto

O teste do campo aberto ouopen fielde amplamente utilizado para quantificar movi-mentos locomotores e de exploracao dos animais. Os movimentos locomotores sao osdeslocamentos entre um ponto a outro da arena. Os movimentos de exploracao ou naolocomotores sao aqueles que o animal pode realizar sem a necessidade de deslocamento,como por exemplo elevacao vertical, cheirar o ambiente e autolimpeza. Em experimentoscom roedores, estes comportamentos sao essenciais para compreender o efeito de dife-rentes drogas psicoestimulantes e ansiolıticas [Prut and Belzung 2003, Eilam 2003].

Os experimentos do campo aberto ocorrem em uma arena de formato variavel,geralmente circulares ou retangulares. Neste trabalho foi utilizada uma arena circularcontendo uma circuferencia interna com o mesmo centro. A circunferencia interna possuiraio igual a 11,5cme a circunferencia da arena possui raio de 20cm, como mostra a Figura1(a). O piso da arenae revestido de formica de cor branca ou preta para que haja umcontraste entre o camundongo e o piso, facilitando a observacao do pesquisador e osalgoritmos de segmentacao. O piso da arena esta dividido em 12 regioes regulares de104,7cm2 cada. A arenae circundada por um material em acrılico transparente de formacilındrica, com 30cmde altura, conforme mostra a Figura 1(b).

Para realizacao dos experimentose aplicada a droga a ser avaliada nos camundon-gos. Posteriormente, os camundongos sao inseridos no centro da arena, a prıncipio umambiente desconhecido. No decorrer do teste, o pesquisador pre-determina o tempo emque o animal permanecera na arena. Em seguidae verificada e registrada a regiao em queo animal se encontra. As Figuras 2(a), 2(b) e 2(c) apresentam exemplos de camundon-gos realizando atividade motora em uma regiao demarcada. Apos o termino do tempopre-definido, retira-se o animal. A execucao do testee feita sucessivamente com todosanimais do grupo do experimento.

No teste do campo aberto sao utilizados mais de 30 parametros que avaliam asatividades motoras e de exploracao dos animais. Para a sua realizacao, foram seleciona-das as caracterısticas de interesse do experimento juntamente com os especialistas. Osparametros relativos aos comportamentos locomotores, neste caso, sao: distancia per-corrida, velocidade de deslocamento e o tempo de permanencia em cada regiao. Nas

(a) (b)

Figura 1. (a) Formato e limites das regi oes demarcadas. (b) Material do piso edas paredes da arena.

(a) (b) (c)

Figura 2. (a) (c) Movimento motor do animal sobre areas demarcadas. (b)Multiplos camundongos realizando explorac oes pela arena.

atividades exploratorias foi analisada a exploracao vertical [Goncalves et al. 2006]. Aexploracao vertical consiste na elevacao das patas posteriores do camundongo, conformeapresentado nas Figuras 3(a), 3(b) e 3(c). Neste caso,e registrado o numero de ocorrenciasdestes comportamentos ao longo do experimento. Um outro fator importantee conhecera trajetoria que o camundongo percorreu ao longo do experimento.

4. Topolino

O sistema Topolino3 e um projeto que foi desenvolvido na UCDB entre a parceria doGrupo de Pesquisa em Engenharia e Computacao (GPEC4) e do Centro de CienciasBiologicas e da Saude (CCBS5). Este sistema visa desenvolver solucoes tecnologicasque beneficiam significativamente pesquisas naarea da saude, em particular as de com-portamento animal. Este trabalho esta dividido em cinco modulos: interface, banco dedados, captura de imagens digitais, rastreamento e aprendizagem supervisionada para

3http://www.gpec.ucdb.br/topolino4http://www.gpec.ucdb.br5http://www.ucdb.br/cursos/ccbs/

(a) (b) (c)

Figura 3. (a) (b) (c) Comportamento de explorac ao vertical realizado pelo camun-dongo.

classificacao de comportamentos de exploracao.

O modulo dainterfacefoi desenvolvido com base nos conceitos de HCI (HumanComputer Interaction) [Myers et al. 1996]. A aplicacao destes estudos proporcionam aousuario a facil interacao na execucao de tarefas. Desse modo, as funcionalidades do sis-tema tornam-se intuitivas para a realizacao dos experimentos. O usuario ainda possui aopcao de salvar e acessar os resultados quantificados atraves de dados tabulados e graficos.Para isso, foi utilizado o modulo de banco de dados responsavel para o armazenamentoe o gerenciamento das informacoes provenientes dos experimentos. Estas informacoespodem fornecer aos usuarios uma forma de comparar outros experimentos realizados an-teriormente. A Figura 4 mostra a tela de configuracao do sistema.

A captura de imagens digitais alimenta o sistema de visao computacional da fer-ramenta. Para isso,e necessario um dispositivo de aquisicao de vıdeo e umsoftwarede rastreamento para o processamento das imagens. O dispositivo possibilita ao usuariogravar ou executar em tempo real os experimentos. O sistema manipula vıdeos em for-matosavi ou mov. O vıdeo capturadoe fragmentado em quadros a uma taxa de 30 porsegundo (fps). Em seguida, de cada quadro sao processadas as imagens e extraıdas ascaracterısticas dos comportamentos locomotores.

Para os comportamentos de exploracao e realizada a etapa de treinamento antesdos quadros serem processados. A etapa de treinamento permite realizar a classificacaodos comportamentos de interesse utilizando o modulo de aprendizagem supervisionada.Este modulo e capaz de realizar a classificacao automatica a partir de experiencias emcasos de sucesso. As regras de classificacao inferidas pelo modulo de aprendizadosao analisadas pela complexidade das proprias regras e o erro de classificacao sobrenovos conjuntos de imagens. Neste modulo, foram utilizados momentos estatısticos[Souza and Pistori 2005] para a extracao de atributos aplicados ao treinamento. Para otreinamentoe escolhido um conjunto de imagens do vıdeo que melhor representam estescomportamentos, descritos na Secao 3. Realizada a selecao dos quadros, sao extraıdos osatributos do conjunto de imagens utilizados para a classificacao.

O software de rastreamento utiliza metodos de segmentacao em imagens para ex-trair o objeto de interesse, neste caso o camundongo. Os metodos de segmentacao utiliza-dos foram subtracao de fundo, subtracao de fundo adaptativo e segmentador baseado em

Figura 4. Configurac oes do sistema Topolino.

modelo gaussiano. A subtracao de fundo [Piccardi 2004]e uma das tecnicas mais utili-zadas devido a sua simplicidade de implementacao e seu baixo custo de processamento.O princıpio basicoe subtrair cada imagem do quadro fragmentado de uma imagem dereferencia, obtida a partir de um fundo estatico e sem o objeto de interesse. A grandedificuldade apresentada pela subtracao de fundoe nao se adaptar a modificacoes no fundoda cena, como mudanca de iluminacao ou objetos que entram em cena e em seguida ficamestaticos e sem relevancia. Para contornar esse problema, existem tecnicas de subtracaode fundo mais sofisticadas, como a subtracao de fundo adaptativo [Collins et al. 2000].Essa tecnica possui a vantagem de se adaptar a pequenas modificacoes, sendoutil emlongos perıodos de tempo, como experimentos com muitas horas de duracao. O modelogaussiano utiliza a cor como principal caracterıstica [Terrillon et al. 2000]. O espaco decor utilizado neste trabalhoe o HSV. As cores no padrao HSV sao divididas em matiz (H)definindo a cor dominante, saturacao (S) representando a pureza da cor e intensidade (V)representando a luminosidade da cor. Para este caso, a componente (V) foi descartadapara que o sistema seja mais robusto em relacao a mudanca na intensidade de iluminacao.

Para o rastreamento dos camundongos nas imagens foram implementados doisalgoritmos baseados em filtros preditivos: filtro de Kalman [Funk 2003] e filtro departıculas [Hue et al. 2001, Morais et al. 2005]. Estes filtros usam um modelo dedinamica e incerteza para propagar os estados do sistema, em seguida o estado pre-dito e corrigido atraves de um modelo de observacao. Os filtros preditivos apresentammuitas vantagens como eficiencia em aplicacoes em tempo real e habilidade de tratara sobreposicao de objetos. O filtro de Kalman apresenta uma limitacao por considerar

que as variaveis aleatorias sao gaussianas e o modelo de dinamica linear. Em algumasaplicacoes, essa restricao de linearidade nao e aplicavel e o filtro nao pode estimar cor-retamente o estado do objeto sobre o tempo. Uma aproximacao possıvel para contornaressa limitacao e empregar uma representacao nao-parametrica baseada em amostras oupartıculas, como o filtro de partıculas.

Os algoritmos dos filtros e os segmentadores implementados possuem parametrosque podem ser alterados pelo usuario e visualizados em tempo real de processamento.A Figura 5 mostra a execucao do modulo de rastreamento. O sistema Topolino, alemde analisar um camundongo por vıdeo, suporta o rastreamento de multiplos camundon-gos, podendo ser observado o nıvel de socializacao entre eles. Apos esta etapae possıvelextrair as caracterısticas das imagens. Com base no treinamento sao classificados os com-portamentos apresentados pelos camundongos durante o experimento. A integracao como software Weka tornou disponıvel para os usuarios do Topolino dezenas de algoritmosde aprendizagem supervisionada, entre eles o C4.5, as maquinas de vetores de suporte ea redes neurais artificiais.

Figura 5. M odulo de rastreamento do sistema Topolino.

5. Conclusao e Trabalhos Futuros

O resultado deste trabalhoe um sistema com fontes livres para auxiliar pesquisadores noregistro de parametros comportamentais relevantes durante experimentos com camundon-gos. Outro ponto a ser destacado,e que o pesquisador possui a flexibilidade de utilizardiversos dispositivos de captura de imagens digitais. Alem disso,e possıvel executar osistema para rastrear ate quatro camundongos atraves de gravacoes de vıdeo ou ate mesmo

em tempo real. A ferramenta mostrou serutil em estudos etologicos, facilitando ao pes-quisador a avaliacao do efeito de determinados farmacos.

A ferramenta implementada automatizou o teste do campo aberto. Porem,e importante agora expandir os experimentos para outros tipos de testes quetambem medem a atividade locomotora de camundongos, como o teste do la-birinto aquatico de morris [Grossmann and Skinner 1996] e o labirinto em cruz[Boguszewski and Szmagalska 2002]. Neste caso, poderia ser expandido o numero devariaveis a serem analisadas. Ainda vale ressaltar que uma maneira de ampliar a utilizacaodo sistema seria realizar os experimentos com diferentes animais e em ambientes diversos.

Agradecimentos

Este trabalho recebeu apoio financeiro da Universidade Catolica Dom Bosco, UCDB, daFundacao de Apoio ao Desenvolvimento do Ensino, Ciencia e Tecnologia do Estado deMato Grosso do Sul, FUNDECT. Alguns dos academicos que participaram no desenvol-vimento do sistema citado nesse artigo receberam bolsas PIBIC/CNPQ.

Referencias

Boguszewski, P. and Szmagalska, J. Z. (2002). Emotional changes related to age in rats abehavioral analysis.Behavioural Brain Research, 133:332–332.

Carvalho, T. H. F. and Lopes, O. U. (2006). O emprego de camundongo genetica-mente modificado como modelo de estudo para doencas cardiovasculares. InXSimposio Brasileiro de Fisiologia Cardiovascular, volume 39, pages 110–116, Ri-beirao Preto,Brasil.

Collins, R., Lipton, A., Kanade, T., Fujiyoshi, H., Duggins, D., Tsin, Y., Tolliver, D., Eno-moto, N., and Hasegawa, O. (2000). A system for video surveillance and monitoring.Technical Report CMU-RI-TR-00-12, Robotics Institute, Carnegie Mellon University,Pittsburgh, PA.

Eilam, D. (2003). Open-field behavior withstands drastic changes in arena size.Behavi-oural Brain Research, 142:53–62.

Fagundes, D. J. and Taha, M. O. (2004). Modelo animal de doenca: criterios de escolha eespecies de animais de uso corrente.Acta Cirurgica Brasileira, 19:59–65.

Funk, N. (2003). A study of the kalman filter applied to visual tracking. Technical report,University of Alberta.

Galsworthya, M. J., Amreina, I., Kuptsovb, P. A., Poletaevab, I. I., Zinna, P., Raua, A.,Vyssotskia, A., and Lippa, H.-P. (2005). A comparison of wild-caught wood mice andbank voles in the intellicage: assessing exploration, daily activity patterns and placelearning paradigms.Behavioural Brain Research, 157:211–217.

Ghozland, S., Matthes, H. W. D., Simonin, F., Filliol, D., Kieffer, B. L., and Maldonado,R. (2002). Motivational effects of cannabinoids are mediated by micro-opioid andk-opioid receptors.The Journal of Neuroscience, 22:1146–1154.

Goncalves, W. N., de Andrade Silva, J., Machado, B. B., de Ruchkys, D. P., and Pistori, H.(2006). Software de auxılio no reconhecimento de padroes em animais de laboratorio

utilizando cadeia de codigo. InProceedings of the VII Workshop on Free Software -WSL (VII International Forum on Free Software), Porto Alegre, Brasil.

Granon, S., Faure, P., and Changeux, J.-P. (2003). Executive and social behaviors undernicotinic receptor regulation.Proceedings of the National Academy of Sciences, pages9596–9601.

Grossmann, M. and Skinner, M. H. (1996). A simple computer based system to analyzemorris water maze trials on-line.Journal of Neuroscience Methods, 70(2):171–175.

Hue, C., Cadre, J.-P. L., and Perez, P. (2001). A particle filter to track multiple objects. InIEEE Workshop on Multi-Object Tracking, pages 61–68, Vancouver, Canada.

Kramer, K. and Kinter, L. B. (2003). Evaluation and applications of radiotelemetry insmall laboratory animals.Proceedings of the American Philosophical Society, 13:197–205.

Kritzler, M., Lewejohann, L., Kruger, A., Raubal, M., and Sachser, N. (2006). An rfid-based tracking system for laboratory mice in a semi natural environment. InPTAWorkshop, PERVASIVE - Pervasive Technology Applied Real-World Experiences withRFID and Sensor Networks, Dublin, Ireland.

Metris, B. V. (2005). High-quality measurements of rodent behavior tracking and ultra-sounds using laboras and sonotrack.Business Briefing, Future Drug Discovery.

Morais, E. F., Campos, M. F. M., Padua, F. L. C., and Carceroni, R. L. (2005). Particlefilter-based predictive tracking for robust fish counting. InSIBGRAPI ’05: Proceedingsof the XVIII Brazilian Symposium on Computer Graphics and Image Processing, page367, Washington, DC, USA. IEEE Computer Society.

Morrow-Tesch, J., Dailey, J. W., and JIang, H. (1998). A video data base system forstudying animal behavior.Journal of Animal Science, 76(10).

Myers, B., Hollan, J., Cruz, I., Bryson, S., Bulterman, D., Catarci, T., Citrin, W., Glinert,E., Grudin, J., Hollin, J., Ioannidis, Y., et al. (1996). Strategic directions in human-computer interaction.ACM Computing Surveys, 28(4):794–809.

Noldus, L. P., Spink, A. J., and Tegelenbosch, R. A. J. (2001). Ethovision: A versatilevideo tracking system for automation of behavior experiments.Behav Res MethodsInstrum Comput, 33(3):398–414.

Piccardi, M. (2004). Background subtraction techniques: a review. InProc. of IEEE SMC2004 International Conference on Systems, Man and Cybernetics.

Prut, L. and Belzung, C. (2003). The open field as a paradigm to measure the effects ofdrugs on anxiety-like behaviors: a review.European Journal of Pharmacology, pages3–33.

Souza, K. P. and Pistori, H. (2005). Implementacao de um extrator de caracterısticas ba-seado em momentos da imagem. InProceedings of SIBGRAPI 2005 - XVIII BrazilianSymposium on Computer Graphics and Image Processing, Natal, RN, Brazil. SBC,IEEE Press.

Terrillon, J.-C., Fukamachi, H., Akamatsu, S., and Shirazi, M. N. (2000). Comparativeperformance of different skin chrominance models and chrominance spaces for the

automatic detection of human faces in color images. InFG ’00: Proceedings of theFourth IEEE International Conference on Automatic Face and Gesture Recognition2000, page 54, Washington, DC, USA. IEEE Computer Society.

Inspecao Visual Industrial Automatizada por An alise deForma com Descritores de Fourier e Redes Neurais Artificiais

Mauricio Edgar Stivanello, Paulo Cesar Rodacki Gomes

1 Departamento de Sistemas e ComputacaoUniversidade Regional de Blumenau (FURB) – Blumenau, SC – Brazil

maustiva@das.ufsc.br, rodacki@inf.furb.br

Resumo.Este trabalho apresenta um prototipo de inspecao industrial auto-matizada independente de produto, feita atraves de aquisicao e reconheci-mento de imagens. No desenvolvimento do prototipo sao utilizados, dentre ou-tras tecnicas de processamento de imagens, os descritores de Fourier para adescricao de formas a partir da borda da silhueta dos objetos inspecionados.Para a interpretacao das representacoes dos produtos, foi implementada umarede neural artificial do tipo Perceptron Multicamadas. O trabalhoe resultadode um projeto de conclusao de curso de graduacao em Ciencia da Computacao.

1. IntroducaoO mercado consumidor de produtos industrializados esta cada vez mais exigente no quediz respeitoa qualidade. Este fato tem motivado as industrias a investirem cada vez maisnos processos de inspecao de qualidade, ja que a mesma se tornou um diferencial compe-titivo. Apesar do aumento dos investimentos naarea, na maioria das industrias brasileirasa inspecao e a selecao dos produtos nas fabricas ainda sao realizadas por inspetores hu-manos, que permanecem em determinados pontos de uma linha de producao, onde devemavaliar determinadas caracterısticas dos produtos produzidos. Caso alguma destas carac-terısticas encontre-se fora dos padroes de qualidade aceitaveis, a pecae retirada da linhade producao para ser descartada ou corrigida.

Por se tratar de uma tarefa extremamente repetitiva e que exige um excessivoesforco fısico por parte do funcionario que a realiza, a inspecao humana acarreta proble-mas tais como a falta de inspecao em todos os produtos, a falta de precisao nas inspecoes ea alta rotatividade de trabalhadores. Os sistemas de inspecao por computador surgem paraauxiliar o homem nestas tarefas. Estes sistemas tem como principal objetivo o auxılio ouate mesmo a substituicao da visao humana no ambiente industrial.

O presente trabalho apresenta a implementacao de um prototipo de software parainspecao industrial automatizada atraves da aquisicao, processamento e interpretacao deimagens dos produtos utilizando descritores de Fourier e redes neurais artificiais. Aproxima secao descreve em termos gerais a arquitetura tıpica de um sistema de inspecaoindustrial. A secao 3 trata do processamento e calculo de descritores de Fourier. Emseguida,e discutido o processo de interpretacao das imagens. A secao 5 demonstra aoperacionalidade do prototipo e discute os resultados obtidos. Por fim, sao apresentadasas conclusoes.

2. Arquitetura de um sistema de inspecaoNormalmente, a arquitetura de um sistema de inspecao automatizadae composta porvarios subsistemas e pode assumir diferentes configuracoes. Para aplicacoes de inspecao

industrial, porem,e comum que seja composta por um sistema de aquisicao de imagens,um sistema de processamento e um sistema de descarte, conforme apresentado na figura 1.

Neste exemplo, o processo de inspecaoe realizado de forma integrada com a linhade producao, evitando assim trabalho desnecessario, ja que uma peca identificada comodefeituosa nao estara presente nas etapas seguintes da producao. O sistema de aquisicaocaptura pelo menos uma imagem de cada peca que transita pela esteira. A imagemetransmitida ao sistema de processamento, ondee analisada a fim de se identificar algumdefeito na peca. Em caso afirmativo, o sistema de processamento deve enviar um comandopara o sistema de descarte, que por meio de algum mecanismo retira a peca defeituosa daesteira.

Figura 1. Arquitetura de sistema de inspec ao

O presente trabalho trata do sistema de processamento. O software deve ser res-ponsavel pelo controle do sistema como um todo, pelo processamento e analise das ima-gens e pela interface com o usuario. Atraves deste tipo software,e realizada a analisesobre cada uma das imagens em busca de defeitos, irregularidades ou mesmo para reali-zar classificacao. Com base no resultado da analise, o software toma uma decisao acercade cada produto analisado, que pode resultar em diferentes acoes.

3. Processamento de imagens

O processamento de imagens assume um importante papel nos sistemas de inspecao au-tomatizada para a extracao de informacoes relevantes para posterior analise e tomada dedecisao. A inspecao sobre um produto pode ser realizada observando-se diferentes carac-terısticas tais sua como forma, cor, textura, e outras. A analise implementada no presentetrabalhoe baseada na forma dos produtos, ela possibilita a inspecao de diferentes tipos deprodutos, ja que a presenca de muitos defeitos de producao tem reflexo direto sobre suaforma externa. Esta secao descreve algumas das tecnicas utilizadas no desenvolvimentodo prototipo.

3.1. Segmentacao das imagens

A segmentacao procura reproduzir o processo da visao humana onde sao efetuados agru-pamentos sobre a imagem percebida, baseados em proximidade, similaridade e continui-dade. Ela consiste em dividir a imagem em elementos significativos e tem como objetivoisolar os objetos de interesse.

Figura 2. Aplicac ao do operador Sobel

No presente traba-lho foi utilizada a tecnica desegmentacao por deteccao debordas [Facon 1993]. Estaeuma das tecnicas em que asegmentacao e realizada combase na descontinuidade devalores de nıveis de cinza. Adeteccao de bordas pode serobtida pelo uso de filtros porderivada. Dentre os filtros porderivada, encontra-se o denominado operador de Sobel. Na figura 2 pode-se observaro resultado obtido pela aplicacao deste filtro em uma imagem. Este filtro faz parte dosmetodos de domınio espacial que operam diretamente sobre os pixels de uma imagemconsiderando a vizinhanca dos mesmos.

A abordagem principal para definir a vizinhanca em torno de um pixel consiste emaplicar mascaras a uma sub-imagem quadrada, centrada no pixel em questao. O centrodesta sub-imageme movido entao de pixel a pixel sobre toda a imagem, aplicando-se ooperador para cada posicao da mesma.

Figura 3. a) Posic oes de uma imagem 3x3; b) M ascara para x; c) M ascara para y

A partir das mascaras do operador de Sobel exibidas na figura 3, tem-se que asderivadas baseadas nas mesmas podem ser obtidas por

Gx = (z7 + 2z8 + z9)− (z3 + 2z2 + z3), (1)

Gy = (z3 + 2z6 + z9)− (z1 + 2z4 + z7). (2)

Conforme exibido na figura 2, a partir do processamento do operador de Sobel osvalores dos nıveis de cinza dos pixels presentes na fronteira da forma a ser segmentadasao aproximados a 255, e os valores dos nıveis de cinza dos pixels que nao pertencerema fronteira sao aproximados a 0. Para evitar que os processamentos que virao a seguirconsiderem faixas de valores proximos a estes extremos,e realizada a binarizacao daimagem atraves da tecnica de limiarizacao global. A binarizacao permite que somentesejam considerados valores de 0 ou 255.

A partir da imagem segmentada pela deteccao de bordas e pela limiarizacao glo-bal, se poderia varrer a imagem e identificar os pixels que compoem um contorno. Porem,nem todos os pixels identificados correspondem necessariamente ao mesmo objeto. Podeexistir mais de um objeto em um quadro analisado, assim como mais de um contornopode pertencer a umunico objeto. Para resolver este problema o presente trabalho utiliza

a tecnica de rotulacao de componentes [Gonzales and Woods 1993]. Atraves dela os dife-rentes agrupamentos de pixels presentes na imagem sao rotulados com diferentes valoresde nıveis de cinza. Observa-se agora que, como a propria faixa de valores dos pixels entre0 e 255e utilizada como identificador dos componentes, existe uma limitacao ao uso deno maximo 253 diferentes agrupamentos. Uma abordagem diferente com utilizacao denova estrutura poderia resolver o problema, porem esta quantidade mostrou-se suficientepara a resolucao do problema aqui exposto.

As informacoes extraıdas dos componentes sao entao utilizadas para decidir qualdos contornos deve ser considerado. Partindo do princıpio que aarea de atuacao de umponto de inspecao em uma linha de producao deve ser controlada e tambem previamentepreparada, o presente trabalho assume que o contorno a ser inspecionadoe o maior con-torno presente no quadro. Para identificacao do maior contorno, considera-se o compo-nente conexo de maiorarea dentre todos os componentes conexos gerados pela rotulacaode componentes.

3.2. Calculo dos descritores de Fourier

Na etapa de segmentacao, obtem-se agrupamentos de pixels que representam o compo-nente da imagem a ser analisado. Porem, este componente deve ser descrito de maneiramais apropriada, ja que uma analise direta sobre os pixels naoe adequada para o problemaem questao.

Identificado o componente conexo a ser considerado, pode-se compor uma linhapoligonal com as coordenadas dos pixels que compoe o contorno. Istoe feito atraves daimplementacao de uma funcao de perseguicao de contorno para percorrer a fronteira deum componente conexo, partindo de um ponto inicial informado. Com isso,e obtida umalista contendo as coordenadas de todos os pontos pertencentesa fronteira do componente.

Com a lista de coordenadas dos pontos no plano xy que formam o contorno, jaha informacao suficiente para diferenciar produtos. Porem, a lista gerada geralmenteemuito grande. Considerando-se que os quadros capturados por cameras especıficas paraaplicacoes de inspecao normalmente sao compostos por 640 pixels de largura por 480pixels de altura, frequentemente sao obtidos contornos com mais de 1000 pixels. Estaquantidade de informacaoe inviavel para a maioria das tecnicas de interpretacao.

Para resolver este problema, o presente trabalho utiliza descritores de ima-gens, que sao conjuntos de numeros, gerados para descrever uma forma. Os des-critores nao reconstituem completamente a forma descrita, mas devem ser suficien-tes para diferenciar uma forma de outra. O presente trabalho utiliza a descricao porFourier. Os descritores de Fourier sao uma das formas de representacao de ima-gens mais populares para aplicacoes de visao computacional e reconhecimento depadroes [da Fontoura Costa and Cesar, Roberto Marcondes 2001], eles nao constituemum metodo simples, mas uma classe de metodos ja que existem diferentes maneiras dedefini-los [Gonzales and Woods 1993].

A figura 4 exibe uma fronteira de N pontos no planoxy. Iniciando de um pontoqualquer(x0, y0) no sentido anti-horario (por exemplo), pode-se encontrar os pares de co-ordenadas(x0, y0), (x1, y1), (x2, y2), ...(xn−1, yn−1) que representam a fronteira da forma.Cada par pode ser tratado como numero complexo da formas(k) = x(k) + jy(k), parak = 0, 1, 2, ..., N − 1, ondeN e a quantidade de pontos que compoe a fronteira. Esta

representacao possui a vantagem de reduzir um problema de duas dimensoes a uma sodimensao.

Figura 4. C odigo de cadeia

A transformada discreta de Fourierecalculada por

a(u) =1

N

N−1∑k=0

s(k)−j2πuk/N (3)

ondeN e a quantidade de pontos que compoe afronteira. Os coeficientes complexosa(u) saochamados de descritores de Fourier. Podem serobtidos tantos descritores quanto o numero depontos que compoem a fronteira no planoxy.Porem, nao existiria vantagem em se descre-ver a forma pela mesma quantidade de pontos.Com este metodo de descricao existe a possi-bilidade de representar uma forma com uma pequena quantidade de descritores. Istoconstitui uma grande vantagem, pois com uma quantidade relativamente pequena deinformacao, pode-se diferenciar formatos de fronteiras distintos. De maneira geral, pou-cos coeficientes de baixa ordem sao capazes de capturar as caracterısticas mais gerais daforma analisada. Para a definicao de caracterısticas mais marcantes, como cantos e re-tas,um grande numero de coeficientese necessario. A transformada inversa de Fourier dea(u) e calculada por

s(k) =M−1∑u=0

a(u)j2πuk/N (4)

ondeN e a quantidade de pontos que compoe a fronteira. Esta transformadae utili-zada para reconstruir os valores des(k) a partir dos coeficientesa(u). A variavel M(comM ≤ N − 1) representa o numero de coeficientes utilizados na descricao da fron-teira [Bowman et al. 2001]. Outra vantagem na utilizacao dos descritores de Fourierea possibilidade de se obter invariancia quantoa rotacao, translacao e escala atraves detransformacoes simples dos descritores. Uma descricao detalhada destas transformacoespode ser encontrada em [Gonzales and Woods 1993].

4. Interpretacao das imagens

A interpretacao consiste em identificar padroes atraves da analise das descricoes da ima-gem obtidas nas etapas anteriores. Esta analise leva em conta padroes ou regras pre-viamente definidas. Dentre as varias tecnicas utilizadas no reconhecimento de padroesencontram-se as redes neurais artificiais, surgidas como uma tentativa de simular o funci-onamento e resolver problemas do mesmo modo comoe feito pelo cerebro humano.

4.1. Redes neurais artificiais

As redes neurais artificiais sao sistemas computacionais implementados em hardwareou software que imitam as habilidades computacionais do sistema nervoso, usandoum grande numero de neuronios artificiais interconectados [Loesch and Sari 1996]. Oneuronio artificial e o elemento basico que forma uma rede neural artificial e simula ofuncionamento de um neuronio biologico. A figura 6 apresenta um modelo de neuronio

artificial, cujos principais elementos sao entradas, pesos sinapticos, funcao de ativacao oufuncao Soma e a funcao de transferencia ou ativador.

O neuronio possui um ou mais sinais de entrada, por onde ele recebe os estımulosa serem processados. Assim como ocorre no neuronio natural, no neuronio artificial todasas entradas sao consideradas de maneira simultanea no momento do processamento.

Os pesos sao os valores que representam o grau de importancia de cada entradapara o neuronio. E atraves da variacao destes valores que se constroi o conhecimento. Osvalores dos pesos sao obtidos no momento do treinamento da rede neural.

Figura 5. Modelo de Neur onio Artificial

A funcao de ativacao ante-cede a funcao de transferencia e temcomo atribuicao repassar o sinal ob-tido atraves das entradasa funcao detransferencia. Em modelos mais sim-ples de redes neurais esta funcao sim-plesmente realiza a soma dos valoresdas entradas multiplicados pelos res-pectivos pesos. A funcao de trans-ferencia analisa o valor gerado pelafuncao de ativacao e gera uma saıda para o neuronio. A funcao muda conforme o modelode rede utilizado. Uma das funcoes mais empregadase a de sinal, onde o valor obtidopela funcao de ativacao e comparado com determinado limiar. Conforme o resultado dacomparacao, a saıda assume um entre dois valores predeterminados.

Em uma rede neural artificial os neuronios sao agrupados em camadas[Loesch and Sari 1996]. Os neuronios da camada de entrada nao realizam processamento.Suaunica funcaoe armazenar a informacao de entrada para ser repassada aos neuronios daproxima camada. Uma rede neural artificial pode tambem possuir camadas intermediariasou ocultas, que se situam entre a camada de entrada e a camada de saıda. A estrutura des-tas camadase iguala da camada de saıda, porem nao tem contato com o exterior. Estascamadas tem como objetivo melhorar o desempenho da rede, aumentando a possibili-dade de divisao do espaco de entrada de maneira nao linear. Por fim tem-se a camada desaıda. Alem de realizar processamento atraves de seus neuronios esta camada tambeme responsavel por repassar o resultado do processamento da rede ao mundo exterior. Aquantidade de neuronios da camada de saıda e igual ao numero de saıdas esperadas darede. As diferentes organizacoes de camadas possıveis distinguem os tipos de arquiteturade redes neurais artificiais existentes. Para a realizacao deste trabalho foi implementadauma rede neural do tipo Multicamadasfeedforward, que sera descrita em secao propria.

4.2. Fases do projeto de uma rede neural

Apesar das redes neurais artificiais serem utilizadas em diversasareas, seu obje-tivo e quase sempre o mesmo, reconhecer e classificar padroes, alem de generalizarinformacoes. Diante de um projeto de uma rede neural ao inves de se pensar em pro-cedimentos e formulas algorıtmicas de processamento de dados deve-se ter em mentetipos de dados de entrada, dados de saıda e tratamento de dados. A rede tem dois momen-tos distintos de processamento: o momento de aprendizado e o momento de utilizacao.Apesar destas duas fases bem distintas de processamento, um projeto de rede possui 3 fa-

ses principais: a definicao, o treinamento e a utilizacao [Loesch and Sari 1996]. Na fasede definicao da rede neural devem-se identificar as variaveis relacionadas ao problemaque contem as informacoes necessariasa resolucao do mesmo. Uma vez identificadasestas variaveise escolhido o modelo da rede neural a ser utilizado. Tambem devem serdefinidos os seguintes aspectos da rede:

1. tamanho da rede: deve-se definir o tamanho da rede no que diz respeito a quanti-dade de camadas, quantidade de neuronios por camada, quantidade de entradas equantidade de saıdas;

2. tipo de problema a ser resolvido: o problema pode ser de classificacao,padronizacao ou otimizacao;

3. tipo de aprendizado: o algoritmo de aprendizado deve ser selecionado entre su-pervisionado e nao-supervisionado.

Dentre as formas de treinamento possıveis para a rede neural artificial, o treina-mento supervisionadoe o mais utilizado. Neste processo, deve-se possuir um conjunto detreinamento organizado em pares, onde para cada entrada se tenha a saıda desejada. Estespares sao entao apresentadosa rede e para cada entrada deve ser verificado se a saıdaobtida correspondea saıda desejada. Caso a saıda obtida seja diferente da saıda desejadadeve ocorrer o ajuste dos pesos sinapticos dos neuronios da rede. Caso a saıda obtida sejaigual a saıda desejada, deve-se apresentar o par seguintea rede. Este processo deve serepetir para todos os pares do conjunto de treinamento, ate que se obtenha uma taxa deacerto satisfatoria. O ajuste sinaptico citado nada maise do que o aprendizado do fatoapresentado.E atraves deste ajuste que o conjunto de neuronios representa a informacaoque foi apresentadaa rede. O ajuste sinapticoe resultado de um calculo que visa somarao peso atual um valor que corresponda ao grau de erro gerado pela rede diante a uma en-trada, a fim de corrigir o valor do peso. Apos ter sido realizado o treinamento satisfatorioda rede neural, ela esta pronta para ser utilizada. A fase de utilizacao e propriamente aexecucao da rede neural, que se inicia quando uma entradae apresentadaa rede e terminaquando a rede gera uma saıda. E importante lembrar que, na fase de utilizacao, nenhumajuste de peso sinapticoe realizado. O processo de utilizacao consiste na obtencao de umaresposta da rede a um estımulo de entrada. Caso ainda surja a necessidade de reconhe-cimento de novos conjuntos de dados ou caso sejam identificados erros significativos naexecucao da rede, sera necessaria uma manutencao na rede neural. A manutencao podeser realizada pelo processo de treinamento ou mesmo por alteracoes na definicao da rede,dependendo do caso.

4.3. Redes neurais perceptron multicamadas

Diferentes combinacoes quanto aos aspectos estruturais das redes neurais artificiais resul-tam na existencia de diferentes modelos, cada um com sua arquitetura, aprendizagem e ca-pacidade diferente dos demais. As aplicacoes praticas tambem variam para cada modelo.A rede perceptron multicamadas possui, alem da capacidade de abstracao, a capacidadede generalizacao. Com isso,e capaz de classificar um padrao mesmo quando este naopertenca ao conjunto de treinamento. Tambeme uma rede robusta, sendo assim imune apequenas falhas nos padroes apresentados [Loesch and Sari 1996]. Quantoa sua arquite-tura, ela possui uma camada de entrada, uma ou mais camadas ocultas e uma camada desaıda. Cada neuronio recebe diversos valores de entrada e produz apenas uma saıda. Osneuronios de uma mesma camada atuam em paralelo. O fluxo de processamento inicia

na camada de entrada e os valores produzidos sao propagados ate a camada de saıda. Asequacoes utilizadas neste tipo de processamento sao chamadas equacoesfeedforward. Aequacao 5 faz este tipo de calculo,

s(k)j = w

(k)0j +

Nk∑i=1

w(k)ij × xk−1

i , (5)

ondexk−1i representa a saıda da funcao de ativacao do neuronio i da camadak; s

(k)j

e a soma ponderada dos pesos pelas entradas;w(k)ij representa os pesos das conexoes

sinapticas na entrada do neuronio j da camadak na i-esima conexao;Nk e o numero deneuronios da camadak; e x

(k)j = f(s

(k)j ) obtem a saıda do neuronio j da camadak; w

(k)0j

representa o valor do bias.

O biase uma entrada adicional que pode ser acrescentada ao neuronio artificial,nao proveniente de nenhum outro neuronio, e de valor de entrada fixado em 1. Seu pesode conexaoe ajustavel pelo aprendizado como qualquer outro peso de conexao. O uso dobias no modelo prove meios de transladar o valor de limiar da funcao de transferencia.

Para o treinamento da rede, ao se apresentar um padrao de entrada, o fluxoealimentado pra frente, camada por camada. O valor de saıda obtidoe comparado coma saıda desejada, e em caso de erro ocorre um reajuste dos pesos da rede. Este ajusteerealizado de tras para frente, ou seja, da camada de saıda a primeira camada oculta. Oalgoritmo de retropropagacaoe apresentado no abaixo:

1. Inicialize os pesosw(k)ij da rede com valores aleatorios proximos a zero;

2. Seja(x, d) o par de treinamento, aplique o vetorx na camada de entrada e propa-gue a rede ate a camada de saıda. Sejay a saıda da rede, calcule o erro quadraticoε2 =

∑mj=1 (dj − yj)

2 . Se for inferior ao valor de tolerancia, pare com sucesso,senao prossiga;

3. Facak ← ultima camada;4. Para todo elementoj da camadak faca:

• Calculeε(k)j empregandoε(k)

j = (dj − yj) sek for a ultima camada ou

ε(k)j =

∑Nk+1

i=1 (δ(k+1i × w

(k+1)ji ) sek for uma camada oculta;

• Calculeδ(k)j = ε

(k)j × f ′(s

(k)j ).

5. k ← k − 1. Sek > 0 va para o passo 4, senao prossiga para o passo 6;6. Recalcule todos os pesos de conexao da rede:W (k)

j (n + 1) = W(k)j (n) +

2µδ(k)j (n) × x

(k)j (n), ondeµ e a taxa de aprendizagem da rede en significa a

iteracao corrente . Tome outro par de treinamento e retorne ao passo 2.

Para a implementacao do algoritmo de retropropagacao existe a necessidade docalculo da derivada da funcao de transferencia no passo 4. Este calculo pode ser realizadocom maior eficiencia computacional quando a funcao de transferencia for alguma funcaologıstica [Fausett 1994]. Deste modo, a derivada foi obtida porf ′(x) = f(x)×(1−f(x)),e a funcao logıstica apresentada abaixo foi utilizada como funcao de transferencia

f(x) =1

1− e−x. (6)

5. Operacionalidade do prototipo e resultados

O prototipo foi implementado em C++, no ambiente de desenvolvimento Microsoft Vi-sual Studio. Sua tela iniciale exibida na figura 6a. O primeiro passo necessario para asua utilizacao na inspecao de produtose a definicao e configuracao das analises a seremconsideradas na inspecao.

Figura 6. a)Tela principal; b) Tela de definic ao de subquadros

A tela exibida na figura 6be utilizada para configuracao da analise de forma.Devem ser informados os parametros utilizados na criacao da rede neural, bem como olocal onde se encontram os padroes a serem utilizados no seu treinamento. Alem disso,o usuario deve informar a quantidade de descritores a serem utilizados e os tipos de in-variancia a serem mantidos. Definidos estes parametros, deve ser realizado o treinamentoda rede neural para que a analise seja preparada para uso. Apos a configuracao da analise,o prototipo encontra-se pronto para inspecionar imagens de produtos. Para isso, bastacarregar as imagens e efetuar as analises. Os resultados sao exibidos na lista de saıda.

Dois casos de teste foram utilizados para verificar o cumprimento dos requisitospara o prototipo proposto, cada um deles refere-sea inspecao de um tipo de produtopara a distincao entre as classes de produtos aprovados e reprovados, contendo diferentesparticularidades a serem analisadas. Para a captura das imagens dos produtos, foi usadoum sistema composto por camera de vıdeo, placa de aquisicao, lentes, dispositivos deiluminacao e um computador. O tamanho da imagem capturada pela placa de aquisicaoede 640 por 480pixels.

Figura 7. Amostra deproduto aprovado

No primeiro caso de teste, foi utilizado como ob-jeto de analise um frasco empregado como embalagemde produtos para limpeza. Esta embalagem foi escolhidapor ser composta por varias pecas, cuja montagem deveser inspecionada para a identificacao de possıveis pro-blemas. Foram definidos os seguintes itens como sendopotenciais pontos de defeito, e, portanto, de analise ne-cessaria na fase de inspecao deste produto: presenca ecorreta posicao do bico; presenca e correta posicao dogatilho; e alinhamento, presenca e correta posicao dosistema de borrifo. A figura 7 mostra a imagem de umproduto considerado aprovado.

A figura 8 exibe imagens de produtos reprovados, exemplificando os defeitos ci-tados anteriormente. Aqui nao e considerada a situacao em que o produto transita pelaesteira e passe pela camera com sua base em umangulo diferente do exibido nas amos-tras das figuras 7 e 8. Isto se da pelo fato de que este controle pode ser conseguidofisicamente, pela utilizacao de duas guias, uma em cada lado do produto. Desta maneirapode-se reduzir em muito a quantidade de posicoes a serem consideradas pelo sistema deinspecao. Para a descricao do produto foram utilizados 15 descritores de Fourier. Quantoas variacoes possıveis na estrutura da rede neural implementada, foi utilizada uma camadaoculta, contendo 15 neuronios. Este mesmo numero de neuronios foi utilizado na camadade entrada. Como a saıda deve assumir um entre dois estados possıveis (produto aceitoou rejeitado), foi utilizado na camada de saıda apenas 1 neuronio.

Figura 8. Amostras de produtos defeituosos

Para este primeiro caso de teste, foram utilizadas 480 amostras para a fase detreinamento, dentre produtos aprovados e reprovados. Para a formacao deste conjuntode treinamento, foram capturadas 50 imagens de produtos. O restante das amostras foigerado a partir do processamento em lote de diferentes transformacoes geometricas, apartir das imagens originais. O objetivo da aplicacao destas transformacoes foi o de gerarpequenas variacoes na forma do produto analisado. Para treinar a rede com a configuracaocitada anteriormente, o processo de treinamento demorou aproximadamente 3 horas numcomputador IBM-PC com processador Pentium 4 de 2.5GHz e 256MB de memoria RAM.

Figura 9. Amostra deproduto aprovado

Na fase de reconhecimento e analise, foramapresentadasa rede 200 novas amostras de produ-tos. Novamente foi utilizado o recurso de gerarvariacoes de imagens a partir de 50 originais, atravesde transformacoes geometricas. A rede classificoucorretamente 100% das amostras. Observe que asimagens exibidasa rede nao haviam sido utilizadasno processo de treinamento. Este fato mostra a capa-cidade de generalizacao da rede. O tempo necessariopara a analise de cada produto girou em torno de 0.1segundos. Deste tempo, verificou-se que a maior par-celae utilizada pelos algoritmos de processamento de imagem, sendo o restante consu-mido pelo reconhecimento atraves da rede neural.E importante comentar que nao foram

despendidos maiores esforcos para a otimizacao do codigo. Portanto, acreditamos que otempo gasto pela analise pode ainda ser reduzido.

Para o segundo caso de teste, foi selecionado como objeto de analise um tubo uti-lizado como embalagem para creme dental. Esta embalagem foi escolhida por possibilitara verificacao da capacidade do prototipo de analisar produtos com variacao na orientacaoem relacao a camera. Foram definidos os seguintes itens como potenciais pontos de de-feito: presenca e correta posicao da tampa; e integridade do tubo. A figura 9 mostra aimagem de um produto considerado aprovado.

Na figura 10 , sao exibidas imagens de produtos reprovados, exemplificando os de-feitos citados anteriormente.E importante observar que neste momento sao consideradastodas as variacoes possıveis quantoa orientacao do tubo.

Figura 10. Amostras de produtos defeituosos

Para este caso de teste foi utilizada a mesma quantidade de descritores utilizadosno caso anterior para a representacao da borda, assim como a mesma estrutura para a redeneural. O tamanho do conjunto de treinamento foi o mesmo do caso de teste anterior. Oprocesso de treinamento demorou 5 horas para ser concluıdo. Enquanto para o primeirocaso de teste foi obtido sucesso no treinamento da rede com um erro maximo de 0.1, paraeste caso foi necessario um erro maximo de 0.2. Isto foi necessario porque a diferenca daborda entre os produtos aprovados e reprovados utilizados neste caso de testee mais sutildo que as do primeiro caso. Neste caso de testes tambem foi obtido 100% de sucesso naclassificacao das amostras. Adicionalmente, confirmou-se a eficiencia no uso dos descri-tores quantoa invariancia a translacao e rotacao, ja que o prototipo reconheceu produtosem diferentesangulos, sendo que na fase de treinamento nao foram apresentados padroesabrangendo todas as combinacoes possıveis.

6. ConclusoesEste trabalho apresentou um metodo para a analise de produtos e o desenvolvimento deum prototipo de software para inspecao industrial automatizada a partir de analise deimagens. Para realizar tal tarefa foram utilizadas diversas tecnicas de processamento deimagens, alem de uma rede neural para o reconhecimento e interpretacao das amostras. Acombinacao do metodo de descricao de fronteiras por Fourier e da tecnica de interpretacao

por redes neurais permitiu o desenvolvimento de um prototipo de inspecao automatizadaversatil quanto ao produto a ser inspecionado, com velocidade e resultado satisfatorios naexecucao das analises. A utilizacao dos descritores de Fourier para a descricao de formaspara a interpretacao das imagens foi baseada na capacidade do metodo em representaras formas a partir de uma quantidade pequena de descritores. Outra propriedade impor-tante considerada no momento da escolha do metodo foi a possibilidade de obtencao dedescritores invariantesa translacao e rotacao. Isso amplia as possibilidades de aplicacaodo prototipo a uma serie de produtos em que pode existir variacao na orientacao dasimagens. A utilizacao de redes neurais do tipo Perceptron Multicamadas baseou-se na ca-pacidade de generalizacao da rede e tambem na sua facilidade de implementacao. Como adescricao dos produtos pode ser obtida por um numero pequeno de descritores,e possıvelutilizar uma rede com quantidade reduzida de neuronios, tornando-a muito eficiente naclassificacao dos produtos. Apesar disto, o treinamento mostrou-se relativamente lento,tendendo a aumentar quando a diferenca do contorno dos produtos das classes aprovadoe reprovadoe sutil. Finalmente,e importante comentar que, apesar do tipo de analisebaseado na forma ser aplicavel a uma grande diversidade de produtos, para muitos des-tes o mesmo nao sera suficiente para a determinacao de ausencia de todos os defeitos deproducao possıveis. Muitos produtos demandam analises especıficas, como, por exem-plo, uma garrafa de bebida ondee necessaria a analise do volume do lıquido. Para estetipo de analise, o metodo apresentado nao e recomendado, pois a variacao no volumedo lıquido nao tem reflexo sobre a forma da garrafa. A complexidade e abrangencia dossistemas de visao computacional possibilitam que o presente trabalho seja estendido comdiferentes objetivos. Durante o desenvolvimento do prototipo, este item foi levado emconsideracao, tanto no projeto do sistema como na escolha das ferramentas utilizadas naimplementacao.

Referencias

Bowman, E. T., Soga, K., and Drummond, W. (2001). Particle shape characterisationusing fourier descriptor analysis.Geotechnique, 51(6):545 – 554.

da Fontoura Costa, L. and Cesar, Roberto Marcondes, J. (2001).Shape Analysis andClassification: Theory and Practice. CRC Press, Boca Raton-London-New York-Washington, DC.

Facon, J. (1993).Processamento e analise de imagens. Universidad Nacional de Cordoba,Argentina.

Fausett, L. (1994).Fundamentals of Neural Networks, volume 1 of1. Prentice hall,Englewood cliffs, unknown, 1 edition.

Gonzales, R. C. and Woods, R. E. (1993).Digital Image Processing. Addison-WesleyPublishing Company.

Loesch, C. and Sari, S. T. (1996).Redes neurais artificiais :fundamentos e modelos.Editora da FURB, Blumenau.

AOPDelphi – Protótipo de um weaver para programaçãoorientada a aspectos em Delphi

Edmar Soares de Oliveira, Marcel Hugo

Departamento de Sistemas e ComputaçãoUniversidade Regional de Blumenal (FURB) – Blumenau, SC

edmar.mg@gmail.com, marcel@furb.br

Resumo. Este trabalho apresenta uma ferramenta de suporte à programaçãoorientada a aspectos na linguagem Delphi. É composto por uma linguagem deprogramação orientada a aspectos e um weaver. A ferramenta recebe comoentrada um projeto Delphi, um ou mais programas de aspectos e gera umprojeto Delphi mesclando as funcionalidades dos programas de entrada.

1. Introdução

Ao longo dos últimos anos, a Engenharia de Software tem disponibilizado para osdesenvolvedores vários métodos, técnicas e ferramentas, para auxiliá-los a produzir commaior qualidade. Entre as características perseguidas, a busca pela reusabilidade emanutenibilidade são as mais importantes para a produtividade (RESENDE; SILVA,2005). Nessa evolução se destaca o surgimento da orientação a objetos, onde houve umamudança radical na maneira de se desenvolver software. Porém, com o crescimento dossistemas e conseqüentemente o aumento de sua complexidade, surgiram problemas,como entrelaçamento e espalhamento de código, que os métodos propostos pelaorientação a objetos não são totalmente eficazes para resolver (KICZALES et al., 1997).Assim nasceu a programação orientada a aspectos (POA), com o objetivo de apresentartécnicas capazes de cobrir essas falhas.

A POA trabalha com o princípio de separação de interesses (separation ofconcerns), que prega que as preocupações envolvidas no desenvolvimento de umsoftware devem ser focadas e trabalhadas separadamente, concentrando em uma de cadavez, reduzindo a probabilidade de ocorrência de erros em cada módulo econseqüentemente no sistema como um todo (KULESZA; SANT’ANNA; LUCENA,2005). Estes conceitos favorecem a reusabilidade e manutenibilidade do software. Éuma tecnologia criada para a implementação de interesses transversais (crosscutingconcerns), que são aqueles cuja implementação atravessam os componentesresponsáveis pela modularização do sistema (RESENDE; SILVA, 2005).

A POA oferece uma estrutura que encapsula implementações de umaresponsabilidade que ficariam espalhadas no modelo orientado a objetos. Esta unidade échamada de aspecto (NELSON, 2005). Para uma implementação básica de POA, énecessário: uma linguagem para programação dos componentes, como por exemplo oJava; uma linguagem para programação dos aspectos, como o AspectJ; um weaver; umprograma de componentes e um programa de aspectos (STEINMACHER, 2001). Oweaver (ou montador) é o combinador de aspectos. Sua função é combinar os programasescritos em linguagem de componentes, no caso, as regras de negócio implementadas

com orientação a objeto, com os escritos em linguagem de aspecto. O resultado será umprograma mesclando as funcionalidades implementadas nos programas de componentese aspecto (GROTT, 2005).

Na POA não há chamada explícita de métodos entre as partes. Ao invés disso, éespecificada em uma unidade separada, como uma parte deve reagir a eventos queocorrem em outra parte (NELSON, 2005).

Este artigo apresenta o desenvolvimento de um protótipo de um weaver parageração de código na linguagem Delphi com suporte a programação orientada aaspectos. Por se tratar de uma ferramenta de engenharia de software, ela é voltada para odesenvolvedor. A ferramenta recebe como entrada um arquivo de projeto do Delphi(arquivo .dpr), e um ou mais programas na linguagem de aspecto AOPDelphi, que foicriada neste trabalho. A ferramenta realiza análises léxica e sintática dos programas deaspectos fornecidos como entrada. Como saída, gera programas fontes na linguagemDelphi, mesclando as funcionalidades dos programas fornecidos como entrada. Esteweaver foi desenvolvido baseado no AspectJ1.

2. Linguagem AOPDelphi

A linguagem AOPDelphi é uma linguagem não case sensitive. Apesar de ter sidoinspirada na linguagem de aspectos do AspectJ, sua sintaxe e seus comandos sãosemelhantes aos da linguagem Delphi, pois ela é uma extensão dessa última linguagem.

2.1 Especificação

Para especificação da linguagem foi utilizada a ferramenta GALS (GESSER, 2003). Asdefinições regulares de auxílio para definição de tokens, os tokens e a gramática dalinguagem foram definidas nesta ferramenta. Baseado nessas especificações o GALSgera os fontes dos analisadores léxico e sintático da linguagem.

Na definição da gramática foi utilizada a notação Backus-Naur Form (BNF). Oquadro 1 apresenta a gramática da linguagem AOPDelphi e algumas definiçõesregulares por ela utilizada.

1 AspectJ é uma ferramenta de apoio a programação orientada a aspectos na linguagem Java que possui o seu � � � � � e sua linguagemde aspectos.

Quadro 1: BNF da linguagem AOPDelphi

2.2 Estrutura da linguagem AOPDelphi

A seguir são apresentadas as construções que formam a linguagem de aspectoAOPDelphi. Um programa AOPDelphi é composto por seu identificador, declarações devariáveis, declarações de pointcuts e declarações de advices, formando um aspecto,como mostra o quadro 2.

������������� ������ �����������IDENTIFICADOR : (<letra> | "_") (<letra> | <digito> | "_")*CURINGA_IDENTIFICADOR: ("*" (<letra> | <digito> | "_")+)

| ((<letra> |"_") (<letra> | <digito> | "_")* "*"(<letra> | <digito> | "_")* (<letra> |"_" |

<digito>))| ((<letra> |"_") (<letra> | <digito> | "_")* "*")

CODIGO : .

���<AOPDelphi> ::= <define_aspecto> <declara_variaveis>

<implementation>End.

<define_aspecto> ::= IDENTIFICADOR = Aspect<letra> ::= [a-zA-Z]<digito> ::= [0-9]<declara_variaveis> ::= Var <lista_variaveis>

�<lista_variaveis> ::= <lista_identificador> : <tipos_primitivos>;

<lista_variaveis_linha><tipos_primitivos>::= string | integer | real

| double | extended | currency| boolean | variant | word| byte | char

<lista_identificador> ::= IDENTIFICADOR <lista_identificador_linha><lista_identificador_linha> ::= , IDENTIFICADOR <lista_identificador_linha>

�<lista_variav � � � � � � � � � � � � � � � � � � � � � � � � � � � � �<implementation> ::= Implementation <declara_pointcuts> <declara_advices>

|<declara_pointcuts>::= IDENTIFICADOR : Pointcut = ( <joinpoint> ) ;

<lista_pointcut><joinpoint>::= <excecao> | <metodo><excecao>::= Exception <indentificador_excecao><metodo>::= <tipo_metodo> <id_classe_metodo> . <id_classe_metodo>

( <parametros> )<tipo_metodo>::= Procedure | Function | Constructor

| Destructor | <curinga><id_classe_metodo>::= IDENTIFICADOR

| <curinga>| CURINGA_IDENTIFICADOR

<parametros>::= <tipos_primitivos> <parametros_linha>| <curinga>

<parametros_linha>::= , <tipos_primitivos> <parametros_linha>�

<lista_pointcut>::= <declara_pointcuts>�

<declara_advices>::= Advice IDENTIFICADOR : <tipo_advice> ;<codigo_advice> ;<lista_advice>

<tipo_advice>::= Before| After

<lista_advice>::= <declara_advices>�

<indentificador_excecao>::= IDENTIFICADOR | <curinga><curinga> ::= *<codigo_advice> ::= Begin (<codigo>)* EndAdvice<codigo> ::= CODIGO

Quadro 2: Exemplo de programa AOPDelphi

ALog = Aspect

Var

FId : Integer;

Str1, Str2 : String;

Implementation

logInsert : Pointcut = (procedure Arquivo.Insert(*));

Advice logInsert: Before;

begin

ShowMessage(‘Olá Mundo!’);

EndAdvice;

End.

No programa exemplificado no quadro 2 foi criado um aspecto de nome ALog,que possui três variáveis (FId, Str1, Str2), um pointcut e um advice, ambosidentificados por logInsert.

A declaração de variáveis na implementação de um aspecto é opcional e asregras sintáticas são as mesmas de um programa Delphi. A restrição é que são aceitasapenas declarações de variáveis de tipos primitivos do Delphi. Para cada variáveldeclarada no programa de aspecto é criado um atributo privado na classe interceptadapelo aspecto.

2.2.1 Pointcut

Os pointcuts, também conhecidos como conjuntos de junção, são utilizados paraespecificar os pontos no programa de componentes que serão interceptados e inseridosum comportamento diferente (RESENDE; SILVA, 2005). Ou seja, eles selecionam umconjunto de pontos de junção, também conhecidos por joinpoints. Os pointcuts podemser comparados com uma variável que armazena uma lista de assinaturas de métodosque serão interceptados e terão o fluxo normal do programa alterado. Na execução doprograma, ao ser invocado um desses métodos, o aspecto entra em ação executando asinstruções definidas para o respectivo pointcut. Há regras que permitem flexibilidade nadeclaração de pointcuts, não sendo necessário especificar um pointcut para cada pontode junção, o que tornaria a POA praticamente sem sentido (NELSON, 2005).

Na declaração de um pointcut em AOPDelphi, especifica-se o tipo de métodoque será interceptado. Um construtor, destrutor, procedimento, função ou exceção. Épossível generalizar, através do caracter *, fazendo com que o pointcut estejaassociando qualquer método, exceto uma exceção.

Especifica-se também a classe e método que serão interceptados. Utilizando ocaracter * é possível fazer uma combinação que se refira a várias classes e métodos. Omesmo acontece ao especificar os parâmetros do método. O pointcut declarado no

exemplo do quadro 2, identificado por logInsert, está se referindo ao métodoInsert da classe Arquivo, não importando quais sejam os parâmetros.

2.2.2 Advice

Os advices são construções semelhantes aos métodos na orientação a objetos e sãoassociados aos pointcuts. Eles contêm o código que será inserido no ponto de junçãoquando o pointcut correspondente for atingido. Podem ser executados antes ou depoisdo método interceptado (KULESZA; SANT’ANNA; LUCENA, 2005). Todo pointcutdeve possuir um ou dois advices.

Na linguagem AOPDelphi, o código Delphi contido no advice não é analisadopelo compilador. A linguagem permite que seja capturado o objeto que invocou ométodo interceptado, podendo utilizá-lo no escopo do advice, através da palavra self,como se tivesse sido criado localmente, porém é uma referência do objeto que chamou ométodo. No aspecto exemplificado no quadro 2, tem-se a implementação de um advicedo tipo before associado ao pointcut logInsert. Conforme o exemplo, o códigoShowMessage(‘Olá Mundo!’) será executado antes da execução do métodoInsert da classe Arquivo.

3. AOPDelphi

O AOPDelphi é uma ferramenta que provê suporte à programação orientada a aspectospara a linguagem Delphi e é composta por uma linguagem de aspecto e um weaver. Oweaver é o combinador de aspectos. Sua função é combinar os programas escritos emlinguagem de componentes, no caso, as regras de negócio implementadas comorientação a objeto, com os escritos em linguagem de aspectos, gerando um programaque mescle as funcionalidades definidas nesses programas de entrada. Este processo échamado de weaving (GROTT, 2005).

A ferramenta foi implementada utilizando a linguagem de programação Delphino ambiente Borland Delphi 7. Na implementação do compilador dos programas deaspectos foi utilizada também a ferramenta GALS (GESSER, 2003). Através dele foramgeradas as classes para a implementação dos analisadores léxico e sintático, e a interfaceda classe do analisador semântico. Isso é feito com base nas definições regulares,palavras reservadas, símbolos especiais, gramática e outras informações que sãofornecidas como entrada na ferramenta.

Na figura 1 é apresentado o diagrama de atividades do AOPDelphi onde estãoespecificadas suas funcionalidades de forma geral. Ele está dividido em duas raias,representadas pelo desenvolvedor e a ferramenta, com suas respectivas atividades.

Figura 1: Diagrama de atividades da ferramenta AOPDelphi

Conforme o diagrama da figura 1, após implementar e informar à ferramenta osprogramas de entrada, o programa de componentes (arquivo .dpr) é compilado paracertificar de que não contenha erros de compilação. Em seguida são compilados osprogramas de aspectos e organizados em objetos as informações necessárias pararealizar o processo de weaving. Não encontrando erros no processo de compilação, aferramenta faz uma cópia dos fontes do programa de componente fornecido na entrada.As alterações realizadas pelo weaver são feitas no programa cópia.

Em seguida é realizado o processo de weaving. Baseado nos pointcuts extraídosem cada aspecto, a ferramenta gera expressões regulares para varrer os fontes do projetoDelphi, localizar os joinpoints que devem ser interceptados e implementar a alteraçãoescrita no respectivo advice. Para trabalhar com expressões regulares, foi utilizada abiblioteca RegExp Studio (SOROKIN), que é uma biblioteca freeware para uso deexpressões regulares no Delphi. Finalizado o processo de weaving, o projeto alterado écompilado e se não houver erros de compilação o programa é executado. Havendo erros,é informado pela ferramenta o nome do fonte, classe e método com problema, além doaspecto e advice que originaram o erro.

Dentre as atividades apresentadas no diagrama ilustrado na figura 1, se destaca aatividade Weaving, principal atividade da ferramenta. Nela é representado o processodesde a seleção das units que serão analisadas pelo weaver até a junção do códigocontido no advice, quando este é inserido no método interceptado por um pointcut. Odiagrama de atividades do processo weaving é representado na figura 2.

Figura 2: Diagrama de atividades do processo de weaving

Neste processo, inicialmente a ferramenta extrai do arquivo de projeto Delphi,que será afetado pelos aspectos, as units que estão diretamente associadas ao projeto eadiciona-as a uma fila. Essas units também são lidas, e delas são extraídas as units asquais elas se referem, e as mesmas são adicionadas à fila. Este processo se repete paratodas as units referenciadas no projeto. Em seguida, o weaver varre a lista de aspectosdo projeto e para cada aspecto, varre a lista de pointcuts, gerando expressões regularesbaseadas em suas informações. Essas expressões regulares são parâmetros de busca nas

units adicionadas à fila para serem analisadas pelo weaver. Ao detectar nos fontesanalisados algum método que contemple a expressão regular em questão, o códigocontido nos advices associados ao pointcut é inserido neste método, antes ou depois docódigo já implementado, conforme definição do advice.

A ferramenta foi desenvolvida baseada no diagrama de classes da figura 3 e maisdetalhes de sua implementação estão disponíveis em Oliveira (2006).

Figura 3: Diagrama de classes da ferramenta AOPDelphi

3.1 Operacionalidade

Ao ser executado o aplicativo AOPDelphi, é exibida uma tela como mostra a figura 4.

Figura 4: Apresentação da ferramenta AOPDelphi

A tela é dividida em duas guias: Projeto AOP e Editor de Aspectos.A guia Editor de Aspectos é o ambiente para programação dos aspectos. Há comandosgerais para manipulação de arquivos, como solicitar um arquivo novo ou abrir, salvarum existente, além da função para compilar. Na guia Projeto AOP são definidos osparâmetros para compilação de um projeto orientado a aspectos.

No campo Projeto Delphi é informado o arquivo de projeto Delphi(arquivo .dpr) que será envolvido no projeto orientado a aspectos. Todas as units quefazem parte desse projeto serão aspectadas2, com exceção daquelas que estiveremincluídas nas listas de units que não devem ser afetadas por aspectos. O AOPDelphioferece mecanismos para criar tais listas.

Após informar o projeto Delphi, o desenvolvedor deve indicar à ferramentaquais são os programas de aspectos que irão interagir com o projeto Delphi informado.A ferramenta dispõe de funcionalidades para adicionar e remover programas de aspectos(arquivo .dao) na lista de aspectos do projeto. O quadro 3 apresenta uma implementaçãode um aspecto de autenticação, onde o objetivo é permitir que somente usuáriosautorizados possam efetuar determinadas operações (inserção, alteração e exclusão) nastabelas da base de dados de um sistema.

2 Trata-se de um neologismo. É o mesmo que ser afetado pelo aspecto.

Quadro 3: Aspecto de autenticação

AAutenticacao = AspectImplementationAutenticaInsert : Pointcut = (* *.SQLInsert(*));AutenticaUpdate : Pointcut = (* *.SQLUpdate(*));AutenticaDelete : Pointcut = (* *.SQLDelete(*));

Advice AutenticaInsert: Before;beginWith DMTaskMan.qryAutentica dobeginClose;Sql.Clear;Sql.Add(’Select count(*) from DIREITO_USUARIO’);Sql.Add(’Where IDUSUARIO = :IDUSUARIO and OPERACAO = :OPERACAO’);Sql.Add(’ and TABELA = :TABELA’);ParamByName(’IDUSUARIO’).AsInteger := giCodUsuario;ParamByName(’OPERACAO’).AsInteger := 1; //1=Insert, 2=Update, 3=DeleteParamByName(’TABELA’).AsInteger := Self.NomeTabela;ExecSQL;if Fields[0].AsInteger = 0 then

Raise Exception.Create('Você não tem permissão para essa atividade. '+ Chr(13) + 'Entre em contato com o seu superior.');

end;EndAdvice;

Advice AutenticaUpdate: Before;beginWith DMTaskMan.qryAutentica dobegin...ParamByName('OPERACAO').AsInteger := 2; //1=Insert, 2=Update, 3=Delete...

end;EndAdvice;

Advice AutenticaDelete: Before;beginWith DMTaskMan.qryAutentica dobegin...ParamByName('OPERACAO').AsInteger := 3; //1=Insert, 2=Update, 3=Delete...

end;EndAdvice;

End.

Em seguida o desenvolvedor pode indicar à ferramenta as listas de units que nãoserão afetadas pelos aspectos do projeto. A cada lista adicionada, suas units sãoinseridas no campo Units não afetadas por aspectos. Durante o processode weaving, cada unit referenciada em algum fonte lido será analisada, a menos de queseu nome conste nesta lista de restrição.

Tendo informado esses parâmetros, o projeto AOPDelphi está pronto para sercompilado. Ao executar o comando Weaving, é feita a consistência no projeto Delphi eem seguida são compilados os programas de aspectos. É feita a cópia do projeto Delphioriginal e inicia-se a junção dos programas de aspectos e do programa de componentes.Os fontes gerados são compilados e ocorrendo sucesso a aplicação será executada.Havendo erros de compilação no projeto Delphi após o weaving, a ferramenta apresentaos tais erros e sua origem.

Os quadros 4 e 5 mostram um método SQLDelete de uma classe afetada peloaspecto, antes e depois do processo de weaving, respectivamente.

Quadro 4: Método SQLDelete antes do processo de weaving� � � � � � � TClientes.SQLDelete(vId: Integer); � � � �

� � � � DMTaskMan.SqlQuery � � � � �

Close;Sql.Clear;Sql.Add(’Delete from CLIENTE Where CL_CODIGO = :CL_CODIGO’);ParamByName(’CL_CODIGO’).AsInteger := vID;ExecSql;� � �

� � �

Quadro 5: Método SQLDelete após o processo de weaving� � � � � � � TClientes.SQLDelete(vId: Integer); � � � �

� � � � � � ! � # $ % & � � ! ( ! & + - . / % 0 ( 3 � 4 6 # 8 9 � !� � � � DMTaskMan.qryAutentica � � � � �

Close;Sql.Clear;Sql.Add(’Select count(*) from DIREITO_USUARIO’);Sql.Add(’Where IDUSUARIO = :IDUSUARIO and OPERACAO = :OPERACAO’);Sql.Add(’ and TABELA = :TABELA’);ParamByName(’IDUSUARIO’).AsInteger := giCodUsuario;ParamByName(’OPERACAO’).AsInteger := 3; //1=Insert, 2=Update,

3=DeleteParamByName(’TABELA’).AsInteger := Self.NomeTabela;ExecSQL;

� : Fields[0].AsInteger = 0 � � � �Raise Exception.Create('Você não tem permissão para essa

atividade. ' + Chr(13) +'Entre em contato com o seu superior.');� � �

� � � � � � ! � # $ % & � � ! ( ! & + - . / % 0 ( 3 � 4 < � >

� � � � DMTaskMan.SqlQuery � � � � �

Close;Sql.Clear;Sql.Add('Delete from CLIENTE Where CL_CODIGO = :CL_CODIGO');ParamByName('CL_CODIGO').AsInteger := vID;ExecSql;

� � �� � �

Conforme definido no advice AutenticaDelete do tipo before, o códigonele contido foi inserido no método interceptado, antes das instruções que já estavam aliimplementadas.

4. Conclusões

Considerando a proposta e as vantagens da programação orientada a aspectos, ossoftwares desenvolvidos com essas técnicas tendem a serem mais flexíveis, melhorandoa manutenibilidade e reusabilidade, pois a implementação dos interesses transversaisfica encapsulada em módulos fisicamente separados do restante do código. Dessa forma,cada componente terá apenas código específico da implementação de seu negócio,permitindo uma melhor evolução do software.

Sendo uma tecnologia relativamente nova, e pelo fato das linguagens deprogramação existentes não proverem suporte nativo a POA, é importante o surgimentode novas ferramentas de apoio nessa área.

Na implementação do aspecto de autenticação na seção anterior, observa-se afacilidade e a confiabilidade que a ferramenta pode proporcionar no desenvolvimento.Nessa implementação através do AOPDelphi, foi necessário a implementação de umaspecto com três pointcuts e três advices. Além de manter íntegros os programas quetêm seu interesse específico, não gerando entrelaçamento de código, a implementaçãodo controle de autenticação está pronta até mesmo para as novas classes que vierem aserem adicionadas no sistema.

Uma limitação da linguagem de aspecto é a não possibilidade de criar variáveis,procedimentos e funções locais dentro dos advices, o que poderia facilitar bastantealgumas implementações.

5. Referências

GESSER, Carlos E. “GALS: gerador de analisadores léxicos e sintáticos”. 2003. 150 f.Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) –Centro Tecnológico, Universidade Federal de Santa Catarina, Florianópolis.

GROTT, Márcio C. “Estudo de caso aplicando programação orientada a aspectos”.2005. 65 f. Monografia (Especialização em Tecnologia da Informação na GestãoIntegrada de Negócios) – Universidade Regional de Blumenau, Blumenau.

KICZALES, Gregor et al. “Aspect-oriented programming”, in Proceeding ofECOOP’97, Finland: Springer - Verlag, 1997.

KULESZA, Uirá; SANT’ANNA, Cláudio; LUCENA, Carlos J. P. “Técnicas de projetoorientado a aspectos”. Uberlândia, 2005. Disponível em: <http://www.sbbd-sbes2005.ufu.br/mini_cursos.aspx>. Acesso em: 01 maio 2006.

NELSON, Torsten. Apostila do curso de programação orientada a aspectos comAspectJ. Belo Horizonte, 2005. Disponível em:<http://www.aspectos.org/courses/aulasaop/curso_poa.pdf>. Acesso em: 26 abr.2006.

OLIVEIRA, Edmar Soares. “protótipo de um weaver para programação orientada aaspectos em delphi”. 2006. 72 f. Trabalho de Conclusão de Curso (Bacharelado emCiências da Computação) – Centro de Ciências Exatas e Naturais, UniversidadeRegional de Blumenau, Blumenau.

RESENDE, Antônio M. P.; SILVA, Claudiney C. “Programação orientada a aspectosem Java”. Rio de Janeiro: Brasoft, 2005.

SOROKIN, Andrey V. “RegExp studio”. Saint Petersburg, Rússia, 2004. Disponívelem: <http://regexpstudio.com/TRegExpr/TRegExpr.html>. Acesso em: 01 mar.2006.

STEINMACHER, Igor F. “Estudo de caso aplicando programação orientada aaspectos”. 2002. 72 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências daComputação) – Universidade Estadual de Maringá, Maringá.

AWSA - Ambiente web de suporte a avaliações da qualidade de produtos de software

Everaldo Artur Grahl, Jonathan Manoel Borges

Departamento de Sistemas e Computação Universidade Regional de Blumenau (FURB) – Blumenau, SC – Brasil

egrahl@furb.br, jmborges@inf.furb.br

Resumo. Este artigo apresenta a especificação e implementação do AWSA-ambiente web para auxiliar na avaliação de produtos de software. O ambiente suporta o processo de avaliação definido na norma NBR ISO/IEC 14598-5 e o método de avaliação da qualidade de produto de software MEDE-PROS definido pelo Centro de Pesquisas Renato Archer (CenPRA). Atualmente o ambiente está sendo adotado em avaliações de produtos de software do mercado e também no auxílio a aulas práticas de engenharia de software.

1. Introdução

Atualmente, atingir níveis adequados de qualidade em produtos de software é um objetivo perseguido por todas as organizações, não sendo mais aceitável entregar produtos ao cliente com muitos problemas. Para Cortês e Chiossi (2001), a “preocupação com a qualidade deixou de ser um diferencial competitivo e passou a ser um pré-requisito básico para participação no mercado”. Muitas empresas estão adotando métodos, ferramentas e buscando certificações da qualidade de software, a fim de garantir a qualidade de seus produtos.

Neste sentido, institutos como a International Organization for Standarization (ISO) e a International Electrotechnical Commission (IEC) definiram normas da qualidade de produtos de software. Dentre estas, pode-se citar as normas ISO/IEC 9126 (aplicada a produtos de software), ISO/IEC 12119 (para pacotes de software) e ISO/IEC 14598 (padrão para processo de avaliação de produtos de software). Com base nestas normas, o Centro de Pesquisa Renato Archer (CenPRA) vem desenvolvendo projetos com o intuito de transferir conhecimento e tecnologia para a avaliação de produtos de software. Como resultado destes projetos, pode-se destacar o Método de Avaliação da Qualidade de Produto de Software (MEDE-PROS), que define um modelo de qualidade aplicado na avaliação de produtos de software. O CenPRA disponibiliza o método a laboratórios interessados. Para isso, os laboratórios devem passar pelo processo de credenciamento junto ao CenPRA. Em Blumenau, a iniciativa para a criação e credenciamento do Laboratório de Qualidade de Software (LQS) partiu do Grupo de Pesquisa de Qualidade de Software da Universidade Regional de Blumenau (FURB). Desta forma, em 2004, o laboratório começou a utilizar o método MEDE-PROS. Inicialmente todas as atividades do processo de avaliação eram manuais não possuindo nenhum software de apoio. Surgiu então, em função da demanda de avaliações de produtos de software a necessidade da construção de um software para apoiar o processo de avaliação.

O objetivo deste artigo é apresentar a especificação e implementação de um ambiente web para auxiliar no processo de avaliação de produtos de software, o qual dá suporte ao processo definido na norma NBR ISO/IEC 14598-5 e ao método de avaliação MEDE-PROS, atualmente sendo utilizado no LQS.

O artigo está organizado em seis seções. Na segunda seção é apresentado o processo de avaliação definido na norma 14598-5. Na terceira seção é apresentado o método de avaliação MEDE-PROS. Na quarta seção é abordado o desenvolvimento da ferramenta. A quinta seção apresenta um estudo de caso. Finalmente, na sexta seção são apresentados os resultados e conclusões.

2. Processo de avaliação da qualidade de software (ISO/IEC 14598-5)

O processo de avaliação da qualidade de produtos de software apresentado pela norma ISO/IEC 14598 é descrito por um conjunto de documentos contendo as atividades a serem realizadas. As normas ISO/IEC 14598-2 e ISO/IEC 14598-6 são relacionadas ao suporte e gestão da avaliação, enquanto as ISO/IEC 14598-3, ISO/IEC 14598-4 e ISO/IEC 14598-5 fornecem requisitos e orientações para avaliação. A ISO/IEC 14598-1 fornece uma visão geral dos demais documentos (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2001a, p. 5). Sua aplicação é prevista em diferentes situações: desenvolvimento (NBR ISO/IEC 14598-3), aquisição (NBR ISO/IEC 14598-4) e avaliação independente (NBR ISO/IEC 14598-5).

O processo de avaliação definido pela norma ISO/IEC 14598-5 fornece requisitos e recomendações para a implementação prática de avaliação de um produto de software, quando várias partes envolvidas necessitam entender, aceitar e confiar nos resultados da avaliação, de modo a garantir a repetitibilidade, reprodutibilidade, imparcialidade e objetividade nas avaliações (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2001b, p. 5).

Para isto, o processo de avaliação é composto por um conjunto de atividades que são conduzidas pelos requisitantes e pelo avaliador cooperativamente, conforme ilustrado pela figura 1.

Figura 1. Processo de avaliação ISO/IEC 14598-5

A função da etapa de análise dos requisitos da avaliação é descrever os objetivos da avaliação, que podem variar de acordo com o uso pretendido do software e os riscos associados ao uso. Após a revisão dos requisitos levantados pelo solicitante da avaliação é feito um acordo formal sobre os mesmos.

Na etapa de especificação da avaliação é definida a abrangência da avaliação, ou seja, quais funções e componentes do produto serão avaliados. Inclui-se nesta etapa uma análise da descrição do produto e a definição das medições a serem realizadas durante o processo, identificando o nível de importância para todas as características de qualidade a serem avaliadas no software.

Na fase de projeto da avaliação é produzido um plano de avaliação baseado na especificação, que descreve os recursos necessários para a realização da avaliação, bem como a distribuição destes recursos nas diversas ações a serem realizadas. Podem ser considerados recursos humanos, recursos computacionais ou espaço físico.

A etapa de execução da avaliação consiste na inspeção, medição e teste dos produtos e de seus componentes de acordo com o plano. Em paralelo, deve ser feito o gerenciamento da execução da avaliação. Como resultado, obtém-se uma versão preliminar do relatório de avaliação e os registros da avaliação.

Por fim, na etapa de conclusão da avaliação é feita a revisão e liberação do relatório de avaliação e a devolução de todo o material (documentos e componentes) disponibilizado pelo requisitante da avaliação, além de verificar o nível de atendimento da avaliação segundo as expectativas do solicitante.

3. Método de avaliação MEDE-PROS

O CenPRA é uma instituição associada ao Ministério da Ciência e Tecnologia, que tem a finalidade de desenvolver e implementar pesquisas científicas e tecnológicas no setor de informática, sendo que o domínio e a disseminação do conhecimento tecnológico é o seu foco de atuação. Uma das suas áreas de atuação é a qualificação de produtos e processos da tecnologia da informação, sob a responsabilidade da Divisão de Qualificação em Software (DQS) que tem como objetivo a geração, aquisição e disseminação de tecnologia para a avaliação de produtos de software. Atualmente, o CenPRA fornece aos avaliadores instrumentos para auxiliar na avaliação de software, por meio de métodos que definem as características e atributos de modelo de qualidade, tendo como destaque o Método de Avaliação da Qualidade de Produto de Software (MEDE-PROS). Este método é amplamente utilizado pelo CenPRA nos serviços de avaliações prestados, além de contar com mais laboratórios credenciados a utilizá-lo, distribuídos nas regiões nordeste, sudeste e sul do Brasil.

Segundo o Centro de Pesquisas Renato Archer (2004a, p. 6), o método foi desenvolvido para apoiar a avaliação da qualidade de produtos de software sob o ponto de vista de um usuário final. O resultado desta avaliação é um relatório da avaliação apontando os aspectos do produto que atendem as normas de qualidade de software e os aspectos a serem revistos, com sugestões de melhoria ao produto.

O método na sua versão 2001 conta com um total de 526 questões divididas em sete componentes: instalação, documentação do usuário, interface de usuário, software, descrição do produto, embalagem e desinstalação. A figura 2 fornece uma visão geral da

organização de características e subcaracterísticas de qualidade de cada item de avaliação do método MEDE-PROS. Mais informações sobre o método pode ser vista em Colombo e Guerra (2002).

Figura 2. Modelo de qualidade do MEDE-PROS

Tendo como base a ISO/IEC 14598, o processo de avaliação descrito no método MEDE-PROS é composto pelas seguintes etapas:

a) definição de diretrizes gerais para o laboratório: definição da estrutura física e de recursos humanos necessários para a prestação do serviço de avaliação;

b) definição da proposta de prestação de serviço: levantamento dos requisitos, elaboração, negociação e formalização da proposta de prestação de serviço;

c) planejamento de prestação de serviço: planejamento das tarefas e recursos necessários para a execução da avaliação;

d) avaliação: testes funcionais e inspeção da documentação do produto (avaliadores), gerenciamento e distribuição do material a ser avaliado e acompanhamento da avaliação (coordenador);

e) término da prestação de serviço: devolução do material avaliado juntamente com o relatório da avaliação, pesquisa da satisfação do cliente quanto ao resultado da avaliação e encaminhamento de uma cópia do material produzido durante a avaliação ao CenPRA.

4. Desenvolvimento da ferramenta

Esta seção apresenta a especificação do software e as principais tecnologias utilizadas para o desenvolvimento da ferramenta.

4.1. Especificação do software

Para a especificação do software foi utilizada a análise orientada a objetos com Unified Modeling Language (UML) e suporte da ferramenta CASE Enterprise Architect. A seguir são apresentados os diagramas de casos de uso, distribuídos de acordo com os atores do sistema (coordenador, avaliador e requisitante). Uma descrição dos casos de uso assim como uma modelagem completa do ambiente (diagramas de classes, atividades e seqüência) pode ser vista em Borges (2006).

O coordenador é responsável pelos cadastros básicos do sistema. Além disso, é responsável por gerenciar e acompanhar as avaliações de software, assim como os métodos de avaliação (figura 3).

Figura 3. Diagrama de casos de uso do coordenador

Aos avaliadores são disponibilizadas funcionalidades referentes à fase de avaliação, como responder as questões do modelo de qualidade, registrar as atividades de avaliação e ocorrências de erros do produto, além de visualizar o resultado da avaliação através dos relatórios da avaliação (figura 4).

Figura 4. Diagrama de casos de uso do avaliador

O requisitante da avaliação usa o ambiente para solicitar e acompanhar a avaliação, e ao final da avaliação, responder ao formulário de satisfação do cliente quanto aos resultados da avaliação (figura 5).

Figura 5. Diagrama de casos de uso do requisitante da avaliação

4.2. Principais tecnologias utilizadas

O ambiente foi implementado utilizando a linguagem de programação PHP versão 5, acessando uma base de dados MySQL versão 5. Utilizou-se também Asynchronous JavaScript and XML (AJAX) e a biblioteca JPGraph. Todos os relatórios do sistema são disponibilizados nos formatos HyperText Markup Language (HTML) e Rich Text Format (RTF).

A metodologia AJAX foi utilizada para a implementação da interface utilizada pelos avaliadores para preencher o questionário de avaliação (figura 7). Nesta interface são listados todos os níveis do modelo de qualidade. Desde as características, suas subcaracterísticas (pode haver vários níveis de subcaracterísticas) e as questões do

modelo de qualidade, através de uma árvore de conteúdo. Geralmente esta árvore de conteúdo de um modelo de qualidade é bem extensa, não sendo viável carregar e apresentar toda a árvore de conteúdo de uma vez, pois o tempo de resposta para carregar esta página pode comprometer a eficiência da ferramenta. Por isto utilizou-se o conceito de desenvolvimento AJAX.

AJAX não é uma nova tecnologia. É uma metodologia de desenvolvimento para aplicativos web que utiliza um conjunto de tecnologias e padrões: web standards e Cascading Style Sheet (CSS), Document Object Model (DOM), Extensible Markup Language (XML), XMLHttpRequest e Javascript (GARRET, 2005). Com o uso desta metodologia as aplicações web passam a realizar as requisições ao servidor web de forma assíncrona, não precisando recarregar toda a página a cada requisição. Desta forma, o aplicativo web ganha maior performance, utilizando menos recurso da rede, pois o servidor envia apenas parte da página e não a página completa. Além disso, é possível criar páginas mais interativas e dinâmicas (mais próximas a aplicações desktop), sendo que enquanto o servidor está processando e respondendo as requisições, a página do lado do cliente continua sendo utilizada normalmente.

JPGraph é uma biblioteca escrita totalmente em PHP, compatível com as versões 4.3.1 ou superiores. Possui dois tipos de licença de uso: uma licença free para utilização educacional, e uma versão comercial. Com esta biblioteca é possível criar diversos tipos de gráficos (ADITUS CONSULTING, 2005). Esta biblioteca foi utilizada para a geração do gráfico no relatório estatístico, que informa o percentual de questões atendidas, atendidas parcialmente, não atendidas, não aplicáveis e não respondidas, das características e subcaracterísticas de um modelo de qualidade.

5. Estudo de caso

Além de ilustrar as principais funcionalidades disponibilizadas pela ferramenta, esta seção demonstra a operacionalidade da implementação por meio da utilização do sistema em uma avaliação.

Com base nos requisitos levantados e tomando como referência a norma NBR ISO/IEC 14598-5 e o método de avaliação MEDE-PROS, definiu-se o ciclo de atividades para o processo de avaliação composto por quatro etapas: levantamento de requisitos, especificação e plano da avaliação, execução e acompanhamento da avaliação e finalização da avaliação.

O processo inicia na fase de levantamento de requisitos com a solicitação da avaliação feita pelo requisitante. Nesta etapa o requisitante fornece informações sobre a empresa, o produto a ser avaliado e os requisitos da avaliação (figura 6), o que fornece uma visão dos recursos necessários e dos objetivos que o requisitante deseja alcançar com a avaliação.

Na fase seguinte (especificação e plano da avaliação) o coordenador define o modelo de qualidade a ser utilizado na avaliação, aloca os avaliadores e equipamentos e libera a avaliação para os avaliadores.

Figure 6. Especificação de requisitos da avaliação

A próxima etapa é a execução da avaliação. Através de inspeção da documentação e testes no software, os avaliadores verificam as características de qualidade no produto, respondendo o questionário da avaliação. A figura 7 ilustra a interface disponível ao avaliador para navegar e preencher o questionário da avaliação. Além de responder as questões, o avaliador também pode anexar figuras para ilustrar e justificar suas respostas.

Figura 7. Respondendo questionário de avaliação

Durante a execução da avaliação, o coordenador pode acompanhar o andamento da avaliação, conforme pode ser visto na figura 8. Na parte superior da interface são listados alguns detalhes sobre a execução da avaliação, para cada avaliador. Na parte central e inferior são encontradas as opções de relatórios, como o tipo de relatório e o formato do arquivo a ser gerado.

Figure 8. Interface de acompanhamento e relatórios (coordenador)

Com exceção do relatório de comparação entre avaliadores que é acessível somente pelo coordenador do relatório, os demais relatórios implementados são disponibilizados tanto para o coordenador do laboratório quanto para os avaliadores. Este conjunto de relatórios pode ser visualizado nos formatos HTML e RTF e são compostos por:

a) resultados da avaliação: aspectos positivos e aspectos a serem revistos do produto;

b) questionário da avaliação: lista todas as respostas do avaliador;

c) comparação de questionários: lista as respostas de dois ou mais avaliadores (somente disponível para o coordenador do laboratório);

d) relatório estatístico: apresenta em uma tabela e gráfico o percentual de questões atendidas e não atendidas, para cada característica de qualidade.

e) resultado quantitativo (métrica): apresenta uma tabela e gráfico com as notas e pesos de cada característica de qualidade, assim como uma pontuação final;

O exemplo parcial do relatório estatístico pode ser visto na figura 9. O gráfico apenas retrata os dados apresentados na tabela e que é gerada a partir das perguntas respondidas pelos avaliadores.

CARACTERÍSTICAS DE QUALIDADE

Atende Atende Parc.

Não Atende

Não se Aplica

Não Resp.

Total

INSTALAÇÃO DO SOFTWARE 13

35.1% 1

2.7% 11

29.7% 12

32.4% 0

0% 37

100% DOCUMENTAÇÃO DO USUÁRIO IMPRESSA E/OU ON-LINE

116 52.3%

19 8.6%

27 12.2%

60 27%

0 0%

222 100%

INTERFACE DE USUÁRIO 68

71.6% 0

0% 6

6.3% 21

22.1% 0

0% 95

100%

SOFTWARE 22

32.8% 1

1.5% 2

3% 42

62.7% 0

0% 67

100%

DESCRIÇÃO DO PRODUTO 15

27.3% 0

0% 10

18.2% 30

54.5% 0

0% 55

100%

EMBALAGEM 17

65.4% 0

0% 6

23.1% 3

11.5% 0

0% 26

100%

DESINSTALAÇÃO 6

25% 0

0% 3

12.5% 15

62.5% 0

0% 24

100%

TOTAL 257 48.9%

21 4%

65 12.4%

183 34.8%

0 0%

526 100%

Figura 9. Relatório estatístico da avaliação

Durante todo este processo, o requisitante pode acompanhar o andamento da avaliação através de uma senha fornecida pelo coordenador. Na fase de finalização da avaliação, o requisitante obtém o relatório final da avaliação e pode preencher o questionário de satisfação, que serve como um feedback para os avaliadores, com a intenção de melhorar o processo de avaliação.

6. Conclusões

O ambiente desenvolvido mostrou-se adequado para o processo de avaliação de software que está sendo adotado no LQS em avaliações prestadas pelo laboratório. Vários aperfeiçoamentos vêm sendo sugeridos pela coordenação do laboratório assim como pelos avaliadores. O ambiente tem mantido um histórico de suas avaliações, o que poderá ser objeto de análises futuras.

Quanto ao processo de avaliação de software suportado pelo ambiente, este atende as principais atividades recomendadas na norma NBR ISO/IEC 14598-5 e no método de avaliação MEDE-PROS. Na tabela 1 é feita uma análise das principais

atividades proposta na norma NBR ISO/IEC 14598-5, relacionando quais destas são suportadas pela ferramenta desenvolvida.

Tabela 1. Análise de atividades da norma ISO/IEC 14598-5

Atividade Subatividade Suporta Proposta dos requisitos da avaliação Sim

Requisitos Acordo formal sobre os requisitos Não Definição da Abrangência da avaliação Sim

Especificação Definição das medições Sim Documentar métodos de avaliação Não

Projeto Planejar ações com base nos recursos disponíveis Sim Gerenciar componentes do produto Não Gerenciar dados da avaliação Sim Execução Gerenciar ferramentas utilizadas Não Gerenciar entrega dos componentes Não Revisão e entrega do relatório da avaliação Sim Finalização Pesquisa de satisfação do cliente Sim

Procurou-se atender as atividades mais relevantes e que tomavam mais tempo dos avaliadores no processo de avaliação. Por este motivo, algumas atividades descritas na norma NBR ISO/IEC 14598-5 não foram contempladas pelo ambiente e atualmente são realizadas de forma manual, porém não ocasionando atraso significativo no processo de avaliação.

A tabela 2 apresenta uma análise das atividades do processo de avaliação definido no método MEDE-PROS com as atividades suportadas pela ferramenta desenvolvida. Percebe-se que basicamente as mesmas subatividades não são suportadas pelo ambiente.

Tabela 2. Análise de atividades do MEDE-PROS

Atividade Subatividade Suporta Definir competências dos avaliadores Sim Diretrizes do

laboratório Definir configuração dos equipamentos Sim Levantamento de Requisitos Sim Proposta de

prestação de serviço

Especificação e formalização da proposta Não

Seleção de avaliadores Sim Plano da avaliação Seleção de equipamentos Sim

Preencher CheckList da Avaliação Sim Elaborar Relatório preliminar Parcialmente Gerenciar recebimento e distribuição dos componentes do produto (coordenador)

Não Execução da avaliação

Acompanhamento da avaliação (coordenador) Sim Elaborar/revisar Relatório final da avaliação Parcialmente Gerenciar entrega dos componentes do produto Não

Finalização da avaliação

Pesquisa de satisfação do cliente Sim

Com relação às tecnologias utilizadas, o AJAX se mostrou adequado para a apresentação da árvore que compõe o modelo de qualidade utilizado nas avaliações. Em alguns casos este modelo de qualidade pode ser bastante extenso (como é o caso do MEDE-PROS com um total de 526 questões) o que poderia comprometer a eficiência do ambiente.

Outro aspecto importante é destacar o uso do ambiente para fins didáticos no ensino de engenharia de software na graduação e pós-graduação. Da mesma forma, o uso de modelos de qualidade e manutenção de um histórico de avaliações têm tornado as aulas mais interessantes e o ensino de tópicos como avaliação de qualidade mais realistas.

Como sugestão para o desenvolvimento de trabalhos futuros e para aprimoramento do mesmo, sugere-se a inserção de funcionalidades que dêem suporte às atividades relacionadas com a gerência dos componentes dos produtos de software avaliados. Nesta gerência, inclui-se o controle de recebimento dos materiais, distribuição destes entre os avaliadores e controle da devolução dos mesmos. Também sugere-se um estudo mais aprofundado da norma ISO/IEC 14598, abordando o processo de avaliação de software para desenvolvedores e adquirentes. Outra funcionalidade a ser desenvolvida é a geração de um contrato para formalizar a proposta de avaliação. Finalmente espera-se a adequação do atual ambiente para suportar a norma ISO/IEC 25000. Esta norma está sob estudos e deverá tomar o lugar nas normas ISO/IEC 14598 e ISO/IEC 9126.

Agradecimentos

Este trabalho foi parcialmente apoiado pelo FINEP através do projeto PLATIC.

Referências

ADITUS CONSULTING. JPGraph. [S.l.], 2005. Disponível em: <http://www.aditus.nu/jpgraph/index.php>. Acesso em: 23 maio 2006.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 14598-1: tecnologia de informação – avaliação de produto de software – parte 1: visão geral. Rio de Janeiro, 2001a.

______. NBR ISO/IEC 14598-5: tecnologia de informação – avaliação de produto de software – parte 5: processo para avaliadores. Rio de Janeiro, 2001b.

BORGES, Jonathan M. Ambiente Web de suporte ao processo de avaliação da qualidade de produtos de software. 2006. 127 f. Trabalho de conclusão de curso - Universidade Regional de Blumenau, Curso de Ciências da Computação, Blumenau. Disponível em: <http://www.bc.furb.br/docs/MO/2006/307280_1_1.pdf>. Acesso em: 29 set. 2006.

CENTRO DE PESQUISAS RENATO ARCHER. Manual do avaliador: MEDE-PROS 2001. [Campinas], 2004a.

COLOMBO, R.; GUERRA, A. The Evaluation Method for Software Product. ICSSEA 2002 – International Conference Software & System Engineering and their Applications, Paris – França.

CORTÊS, M. L.; CHIOSSI, T. C. S. Modelos de qualidade de software. Campinas: Unicamp, 2001.

GARRET, J. J. Ajax: a new approach to web applications. [S.l.], 2005. Disponível em: <http://www.adaptivepath.com/publications/essays/archives/000385.php>. Acesso em: 23 abr. 2005.

Delphi2Java-II: ferramenta para conversão de formulários Delphi em código Java

Mauro Marcelo Mattos, Joyce Martins, Israel Damásio Medeiros, Janira Silveira

Departamento de Sistemas e Computação Universidade Regional de Blumenal (FURB) – Blumenau, SC – Brasil

Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brazil {mattos,joyce,messiah}@inf.furb.br, janira.silveira@gmail.com

Resumo. Este artigo apresenta uma solução desenvolvida em forma de ferramenta, para realizar a conversão de formulários elaborados no ambiente de programação Delphi para aplicações na linguagem Java. A ferramenta Delphi2Java-II é capaz de converter componentes de visualização, de visualização de dados e de acesso ao banco de dados. A aplicação convertida segue o padrão Model-View-Controller.

1. Introdução O processo de desenvolvimento de aplicações via de regra está inserido em um ciclo evolutivo e requer constantes modificações, seja para corrigir erros, melhorar desempenho ou adicionar novas funcionalidades. No entanto, segundo DMSNet (2004), para muitas empresas produtoras de software e sistemas corporativos, a grande limitação de seus produtos não se encontra na evolução das regras de negócio do mesmo, mas sim, na plataforma de desenvolvimento e no banco de dados para os quais o produto foi originalmente projetado. Tal limitação afeta seu posicionamento estratégico e mercadológico, pois inviabiliza a comercialização para clientes com outras plataformas ou sistemas operacionais. Mas “existem tantos sistemas, que a completa substituição ou a reestruturação radical é financeiramente impensável para a maioria das organizações” (SOMMERVILLE, 2003, p. 533). Para solucionar esse problema, foram desenvolvidas várias ferramentas visando apoiar a migração de aplicações para plataformas distintas (FONSECA, 2005; DMSNET, 2004).

Atualmente o mercado está polarizado entre duas principais plataformas de desenvolvimento: Java 2 Enterprise Edition (J2EE) e Microsoft .NET. Segundo Gartner (2003 apud CESAR, 2003), juntas, essas tecnologias terão 80% ou mais do mercado de desenvolvimento de aplicações de e-business até 2008. Ainda, uma recente pesquisa, “que mede o percentual de adoção de tecnologias nas empresas de software, indica que Java cresceu de 72,2% em 2003 para 77,4% hoje. Ou seja, 77,4% das empresas de software usam Java. A pesquisa ainda mostra que 6,3% esperam usar Java até o próximo ano” (PAMPLONA, 2006).

Considerando esta demanda pela adoção da tecnologia Java, muitas empresas estão reestruturando seu processo de desenvolvimento ou até mesmo migrando os sistemas desenvolvidos. Para realizar a migração de aplicações Delphi para Java, por exemplo, além da necessidade de conversão da interface gráfica, deve-se também converter o código fonte para que seus componentes visuais mantenham a funcionalidade original, incluindo conexão com banco de dados.

Dentre as ferramentas que podem auxiliar no processo de migração de aplicações Delphi para a plataforma Java, cita-se Delphi2Java (ROBINSON, 2004). Trata-se de uma ferramenta comercial que se propõe a converter interfaces gráficas, conexões com banco de dados e código fonte de aplicações Delphi. No entanto, Delphi2Java teve seu desenvolvimento e comercialização descontinuados. Com o mesmo objetivo, em 2005 iniciou-se o desenvolvimento da ferramenta Delphi2Java-II (FONSECA, 2005). A partir da análise de formulários Delphi contendo os componentes de interface, são geradas classes Java. Em 2006 a ferramenta foi estendida incluindo a conversão de componentes de visualização de dados, componentes de acesso e conexão ao banco de dados (SILVEIRA, 2006).

Assim, neste artigo é apresentada a ferramenta Delphi2Java-II, estando o texto organizado da seguinte forma: a seção 2 trata de migração de código e geradores de código, descrevendo aplicações e etapas de desenvolvimento; a seção 3 apresenta as principais funcionalidades da ferramenta, bem como as técnicas utilizadas na implementação. Por fim, na última seção são apresentados os resultados obtidos e as limitações da ferramenta proposta.

2. Migração de código Uma das dificuldades enfrentadas pelas empresas de tecnologia é a manutenção e a migração de sistemas para as novas plataformas de desenvolvimento. Para reduzir custos na evolução de sistemas, usa-se a reengenharia de software através da tradução dos mesmos, quando um código fonte em uma linguagem de programação é traduzido para um código fonte em uma outra linguagem. A tradução do código fonte só é economicamente viável se um tradutor automatizado estiver disponível para fazer a maior parte da tradução (SOMMERVILLE, 2003). Assim, como recurso para a migração de software, encontram-se os geradores de código.

A geração de código é uma técnica de construção de código que utiliza determinadas ferramentas para gerar programas. Estas ferramentas podem variar de scripts de ajuda muito pequenos a aplicações que transformam modelos abstratos de lógica de negócio em sistemas completos, incluindo os geradores de interface com o usuário e os de acesso ao banco de dados. Não há nenhum estilo específico para as ferramentas de geração de código (DALGARNO, 2006): podem trabalhar na linha de comando ou possuir uma Graphical User Interface (GUI); podem gerar código para uma ou mais linguagens; podem gerar código uma vez ou múltiplas vezes; podem ter um número ilimitado de entradas e saídas.

Para a construção de um gerador de código, segundo Herrington (2003), podem ser seguidas as seguintes etapas de desenvolvimento: (1º) determinar qual deve ser a saída do gerador, identificando quais informações devem ser recuperadas da entrada; (2º) definir qual será a entrada e como a mesma será analisada; (3º) analisar a entrada, extraindo as informações necessárias para gerar a saída; (4º) gerar a saída a partir das informações extraídas da entrada.

3. A ferramenta Delphi2Java-II Neste contexto, Delphi2Java-II foi desenvolvida como um gerador de interface e de código para acesso ao banco de dados. Em termos de funcionalidades, a ferramenta implementa:

a) a conversão de formulários Delphi (arquivos com extensão DFM) para classes Java;

b) a conversão de 22 componentes de visualização (TButton, TChebckBox, TComboBox, TCoolBar, TEdit, TForm, TLabel, TListBox, TMainMenu, TMemo, TMenuItem, TPageControl, TPanel, TProgressBar, TRadioButton, TRadioGroup, TScrollBar, TSpinEdit, TStatusBar, TStringGrid, TTabSheet, TToolBar);

c) a conversão de 7 componentes de visualização de dados (TDBCheckBox, TDBComboBox, TDBEdit, TDBGrid, TDBMemo, TDBRadioGroup, TDBText);

d) a conversão de 4 componentes de acesso ao banco de dados (TTable, TQuery, TDatabase, TDataSource), implementando suas principais funcionalidades;

e) a interligação dos componentes de acesso ao banco de dados com os componentes de visualização de dados, implementada em Delphi através do componente TDataSource;

f) a geração de uma classe contendo a assinatura dos métodos para os principais eventos (onCreate, onDestroy, onClick, onChange, onEnter, onExit, onCloseUp, onKeyPress) habilitados na aplicação Delphi, permitindo que o código seja futuramente inserido.

O diagrama de caso de uso representa a interação do usuário com a ferramenta, destacando as ações que podem ser realizadas. A Figura 1 mostra o diagrama de caso de uso da ferramenta e no Quadro 1 é apresentado o detalhamento deste caso de uso.

Figura 1 – Diagrama de caso de uso UC01

UC01 - Converter código Pré-condição: O(s) arquivo(s) .DFM não pode(m) estar corrompido(s). Cenário principal:

1. A ferramenta apresenta as opções para carregar o(s) arquivo(s) e o diretório para salvar os arquivos gerados.

2. O usuário seleciona o(s) arquivo(s) que deseja carregar e o diretório onde deseja salvar os arquivos gerados.

3. A ferramenta apresenta a relação de arquivos carregados. 4. O usuário seleciona o(s) arquivo(s) que deseja converter. 5. A ferramenta apresenta as opções para gerar código para arquivo(s) selecionado(s) e

para gerar código para todos os arquivos carregados. 6. O usuário seleciona a opção desejada. 7. A ferramenta faz a conversão do código.

Pós-condição: Dois ou mais arquivos com a extensão .java gerados para cada arquivo selecionado.

Quadro 1 – Detalhamento do caso de uso.

3.1. Especificando a saída Como saída da ferramenta são geradas classes Java, usando componentes da biblioteca

Swing similares aos componentes Delphi de visualização e de visualização de dados, e fazendo a conexão com o banco de dados através da API JDBC. Para padronizar e dividir em camadas a saída gerada, é utilizado o padrão Model-View-Controller (MVC). Assim, deve-se criar um projeto e dispor as classes geradas em pacotes (Quadro 2).

CLASSE DESCRIÇÃO PACOTE

xxxxxxFRM.java

Classe com os componentes de visualização e visualização de dados (layout da interface), sendo xxxxxx o nome do arquivo DFM convertido.

view

xxxxxxEvent.java Classe de eventos de interface, sendo xxxxxx o nome do arquivo DFM convertido.

controller

ConnectionManager.Java Classe de conexão com o banco de dados.

model

BeanTByyyyyy.java

Classe que representa os campos das tabelas acessadas, incluindo os métodos de inclusão, alteração e exclusão, sendo yyyyyy o nome da tabela. É gerada uma classe Bean para cada tabela acessada.

model/bean

CursorTByyyyyy.java

Classe que contém as consultas a serem executadas, sendo yyyyyy o nome do componente de acesso ao banco de dados. É gerada uma classe desse tipo para cada componente de acesso ao banco de dados.

model/cursor

Quadro 2. Estrutura das classes geradas pela ferramenta Delphi2Java-II

Tendo em vista que a versão atual do Delphi2Java-II foi desenvolvida para acesso ao banco de dados Oracle8i, deverão ser adicionadas, nas propriedades do projeto, as bibliotecas da API JDBC (classes12.jar, classes12dms.jar, nls_charset12.jar) para acesso ao banco de dados.

3.2. Analisando formulários Delphi A entrada da ferramenta são formulários Delphi. Para cada formulário de uma aplicação desenvolvida em Delphi tem-se um arquivo com extensão DFM, contendo todas as informações dos componentes da interface.

Quadro 3. Exemplo de um arquivo DFM Figura 2. Formulário

Cada componente tem uma identificação, uma lista de propriedades com valores associados e outros possíveis objetos componentes (SASSE, 2005). O Quadro 3 mostra um arquivo DFM e a Figura 2 mostra o formulário correspondente.

Como um arquivo DFM é organizado de uma maneira hierárquica, sua estrutura

object Form1: TForm1 Left = 192 Top = 114 Width = 213 Height = 169 ... object Button1: TButton Left = 64 Top = 48 Width = 75 Height = 25 Caption = 'Abrir' TabOrder = 0 end end

objeto componente

nome do objeto

lista de propriedades

<dfm>::= <object> <object>::= OBJECT identifier ":" identifier { <property> } { <object> } END <property>::= identifier ["." identifier] "=" <value> <value>::= ["+" | "-"] (integer | real)

| string | FALSE | TRUE | identifier ["." identifier] | "<" { <collectionItem> } ">" | "[" [ <value> { "," <value> } ] "]" | "(" <value> { <value> } ")" | "{" <value> { <value> } "}"

<collectionItem>::= identifier { <property> } END

pode ser descrita usando a notação Extended Backus-Naur-Form (EBNF), conforme o Quadro 4, onde os símbolos entre chaves podem ocorrer zero ou mais vezes e os símbolos entre colchetes são opcionais.

Para analisar os arquivos DFM e extrair as informações necessárias para gerar a saída foram utilizados os analisadores léxico, sintático e semântico, módulos componentes de um compilador, implementados na solução proposta por Souza (2005). No modelo implementado, o analisador léxico identifica as palavras reservadas (OBJECT, END, FALSE, TRUE), os identificadores, as constantes (integer, real, string) e os símbolos especiais (: . , < > [ ] ( )). O analisador sintático verifica se as unidades léxicas estão dispostas de acordo com estrutura gramatical definida no Quadro 4. E o analisador semântico extrai e armazena as informações do arquivo DFM necessárias para gerar a saída.

Fonte: adaptado de Souza (2005).

Quadro 4. Gramática

3.3. Gerando classes Java Depois de extraídas as informações do formulário principal da aplicação, inicia o processo de conversão. Buscando simplicidade e flexibilidade na construção da ferramenta, optou-se pelo uso de templates, de forma a manter a formatação do código separada da lógica que determina o que deve ser construído. No Quadro 5 tem-se o código gerado pela ferramenta para o objeto Button1 do Quadro 3, usando o template do Quadro 6. ... Button1.setBackground(new java.awt.Color(199,199,199)); Button1.setBounds(64, 48, 75, 25); Button1.setFont(new java.awt.Font("MS Sans Serif", 0,12)); Button1.setForeground(new java.awt.Color(0, 0, 0)); Button1.setText("Abrir"); Button1.setFocusable(false); Button1.setVisible(true); ...

Quadro 5. Código gerado para o componente TButton

Com a Velocity Template Language (VTL), linguagem do motor de templates Velocity (MOURA; CRUZ, 2002), foram definidos 10 templates que possuem, além do conteúdo estático, um código dinâmico composto por variáveis e comandos estruturados que são substituídos quando do seu processamento. Assim, para a implementação de Delphi2Java-II foi necessário: criar uma instância do VelocityEngine; criar um esquema de mapeamento entre os objetos Java que contêm as informações extraídas do arquivo DFM e os elementos dos conteúdos dinâmicos definidos nos

templates; carregar os templates; substituir adequadamente as referências definidas nos templates pelos valores dos objetos Java de acordo com o contexto; e, gerar o arquivo de saída.

... #foreach ($TButton in $arrayButton) ... ${TButton.getName()}.setBackground(new java.awt.Color(${TButton.setarBackground()})); ${TButton.getName()}.setBounds(${TButton.getLeft()}, ${TButton.getTop()}, ${TButton.getWidth()}, ${TButton.getHeight()}); ${TButton.getName()}.setFont(new java.awt.Font(${TButton.getFontJava()})); ${TButton.getName()}.setForeground(new java.awt.Color(${TButton.getForeground()})); ${TButton.getName()}.setText("${TButton.getCaption()}"); ${TButton.getName()}.setFocusable(${TButton.isFocusable()}); ${TButton.getName()}.setVisible(${TButton.getVisible()}); #if ($TButton.getEnabled()) ${TButton.getName()}.setEnabled(${TButton.getEnabled()}); #end #end ...

Quadro 6. Template com definição do componente TButton

3.4. usando o Delphi2Java-II A Figura 3 apresenta uma seqüência de telas que permitem a visualização do funcionamento da ferramenta .

Figura 3. Delphi2Java-II

código dinâmico

código estático

passo 01: selecionar arquivos para conversão

passo 02: selecionar diretório para salvar arquivos gerados

passo 03: selecionar opção de conversão

O primeiro passo para realizar a conversão dos formulários é identificar a sua localização num diretório qualquer. Todos os arquivos com extensão DFM são listados para que o usuário faça a seleção daqueles que deseja converter. Em Arquivos .DFM é apresentada a relação de arquivos selecionados para a conversão. O próximo passo é identificar o diretório onde os arquivos gerados serão armazenados.

Para realizar a conversão de formulários existem duas opções: gerar código Para arquivo(s) selecionado(s) e gerar código Para todos os arquivos carregados (em Arquivos .DFM). Os componentes que a ferramenta não reconhece e cuja conversão para Java ainda não foi contemplada, são listados em Componentes não convertidos.

Delphi2Java-II foi implementada na linguagem Java, utilizando o ambiente de desenvolvimento Eclipse 3.0, a biblioteca gráfica Swing e o JDK na versão 1.4.2. O motor de templates Velocity foi utilizado através da biblioteca velocity-dep-1.3.jar.

3.5. Validando a ferramenta Para validar a ferramenta, foram desenvolvidos vários formulários utilizando o ambiente Delphi 7.0. Nos testes foi utilizado o banco de dados Oracle8i. Como exemplo de utilização de Delphi2Java-II, a Figura 4(a) mostra um arquivo DFM contendo vários componentes possíveis de serem convertidos e a Figura 4(b) mostra a interface correspondente em Java.

Figura 4. Formulários Delphi e Swing com componentes de banco de dados.

4. Resultados e limitações O presente trabalho descreveu as principais características da versão atual da ferramenta Delphi2Java-II. Esta versão faz parte de um projeto iniciado em 2005 (FONSECA, 2005) e expandido para produzir interfaces web - projeto DelphiToWeb (SOUZA, 2005). As interfaces geradas pelas três ferramentas apresentam muita semelhança no que se refere à conversão dos componentes de visualização. No entanto, a 1a versão de Delphi2Java-II (FONSECA, 2005) e DelphiToWeb (SOUZA, 2005) não convertem formulários que contenham componentes de visualização de dados e componentes de acesso ao banco de dados.

Quanto aos eventos encontrados no arquivo DFM, as duas versões de Delphi2Java-II geram código para manipulá-los. A 1a versão de Delphi2Java-II disponibiliza uma classe de eventos contendo apenas as assinaturas dos métodos que estão habilitados na aplicação original em Delphi. A versão atual, além de gerar as assinaturas desses métodos, inclui outros para carregar valores para os componentes de visualização de dados. Cabe ressaltar que, devido ao fato de apenas a versão de Delphi2Java-II descrita nesse trabalho efetuar a geração de mais de dois arquivos de saída, é a única que padroniza e divide o código gerado em camadas, utilizando o padrão MVC. No que se refere às técnicas utilizadas no desenvolvimento das ferramentas, DelphiToWeb lê e recupera as informações dos formulários Delphi a partir de analisadores léxico, sintático e semântico. Essa solução, descrita em Souza (2005), foi reutilizada para implementar a ferramenta proposta nesse trabalho. Por fim, foram especificados templates, modelos que servem como guia para a geração de código de saída. No Quadro 7 é apresentada uma comparação entre as ferramentas levando em consideração suas principais características.

CARACTERÍSTICAS Delphi2Java-II (FONSECA,2005)

DelphiToWeb (SOUZA,2005)

Delphi2Java-II (SILVEIRA,2006)

conversão de componentes de visualização

27 22 22

conversão de componentes de visualização de dados

- - 7

conversão de componentes de acesso ao banco de dados

- - 4

tratamento de eventos sim - sim geração de código de saída no padrão MVC

- - sim

uso de analisadores (léxico, sintático e semântico) para leitura do arquivo DFM

- sim sim

uso de templates para geração de código

- - sim

Quadro 7. Comparação entre ferramentas

Atualmente, através de um projeto do PIBIC/CNPq, está sendo desenvolvida uma nova versão que envolve a conversão de código fonte object pascal dos tratadores de evento de componentes de interface já convertidos. Posteriormente pretende-se explorar o projeto para conversão do código fonte Pascal (incluindo código de acesso ao banco de dados). Como extensões da ferramenta estão sendo consideradas as seguintes possibilidades: efetuar a conversão de outros componentes de acesso ao banco de dados; e gerar código utilizando outros drivers JDBC ou em outras linguagens, como HTML ou JavaScript, bastando definir o template que servirá de modelo para o código a ser gerado.

Agradecimentos Parte deste trabalho foi financiada com bolsas de iniciação científica do PIBIC/CNPq.

Referências CESAR, R. Java X .NET: disputa acirrada no mercado nacional. ComputerWorld, São Paulo,

n. 387, jun. 2003. Disponível em: <http://computerworld.uol.com.br/AdPortalv5/ adCmsDocumentShow.aspx?DocumentID=75187>. Acesso em: 26 mar. 2005.

DALGARNO, M. Frequently asked questions about code generations. [S.l.], 2006. Disponível em: <http://www.codegeneration.net>. Acesso em: 29 abr. 2006.

DMSNET. Migração / conversão de sistemas para Java (J2EE). [S.l.], 2004. Disponível em: <http://www.dmsnet.com.br/conversor.htm>. Acesso em: 15 mar. 2005.

FONSECA, F. Ferramenta conversora de interfaces gráficas: Delphi2Java-II. 2005. 59 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

HERRINGTON, J. Code generation in action. California: Manning, 2003. MOURA, M.F.; CRUZ, S.A.B. Formatação de dados usando a ferramenta Velocity.

Campinas, 2002. Disponível em: <http://www.cnptia.embrapa.br>. Acesso em: 9 abr. 2006. PAMPLONA, V. F. Continua aumentando o índice de adoção do Java nas empresas. [S.l.],

2006. Disponível em: <http://www.javafree.org/news/ >. Acesso em: 02 fev. 2006. ROBINSON, S. L. Delphi to Java conversions. [S.l.], [2004?]. Disponível em:

<http://spritemaster.com/delphi_to_java_conversions.html>. Acesso em: 31 maio 2006. SASSE, E. Convertendo arquivos DFM binários para texto. [S.l.], [2005?]. Disponível em:

<http://www.clubedelphi.net/Novo/Colunistas/Erick_Sasse/02.asp>. Acesso em: 8 maio 2005.

SOMMERVILLE, I. Engenharia de software. 6. ed. Tradução André Maurício de Andrade. São Paulo: Addison Wesley, 2003.

SILVEIRA, J. Extensão da ferramenta Delphi2Java-II para suportar componentes de banco de dados. 2006. 81 f. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

SOUZA, A. Ferramenta para conversão de formulários Delphi em páginas HTML. 2005. 67 f. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

Informática na Educação: ensino presencial e educação a distância

Ana Isabel de Azevedo Spinola Dias1, Wanderley Moura Rezende2

1Departamento de Análise – Universidade Federal Fluminense (UFF) Niterói, RJ – Brasil

2Departamento de Matemática Aplicada – Universidade Federal Fluminense (UFF) Niterói, RJ – Brasil e CEDERJ

{belspinola,wanderley.rezende}@gmail.com

Rua Mário Santos Braga, Valonguinho, Centro, Niterói, RJ, Brasil, CEP 24.020-140 Telefones: 2629-2058 e 2629-2070

Resumo: Apresentamos uma reflexão sobre o impacto da educação a distância no ensino presencial, analisando a parceria entre as práticas e teorias da EAD e as do ensino presencial, parceria esta essencial para o aprimoramento da educação em seu sentido amplo, com novas posturas acadêmicas.

1. Introdução São notórias as mudanças tecnológicas, econômicas e político-sociais que ocorrem no mundo de hoje. A cada dia surgem novas tecnologias que interferem diretamente (ou indiretamente) no nosso cotidiano. Computadores, celulares, cartões magnéticos são, por exemplo, algumas das tecnologias que já fazem parte do cotidiano da nova geração de adolescentes. Novas maneiras de pensar e de conviver estão sendo elaboradas no mundo das telecomunicações e da informática. Segundo Levy(1993), “as relações entre os homens, o trabalho, a própria inteligência dependem, na verdade, da metamorfose incessante de dispositivos informacionais de todos os tipos. Escrita, leitura, visão, audição, criação, aprendizagem são capturados por uma informática cada vez mais avançada”. Assim, diante desses fatos, não há como a pedagogia ficar alheia a este cenário. Algo precisa e, com certeza, será mudado no processo educacional. Não se trata aqui de fazer uma apologia à educação a distância, mas, sobretudo, de, no embate de forças desta nova modalidade educacional com a pedagogia convencional e presencial, extrairmos subsídios que nos permitam uma reflexão mais crítica sobre a educação do futuro, porque não dizer do presente. E nesse sentido, pode-se afirmar que as novas tecnologias produzidas e inseridas no âmbito da educação a distância constituem um fecundo campo de investigação em busca de alternativas para uma nova pedagogia. E é a partir deste duelo intelectual entre a “nova modalidade” e a “educação convencional”, que pretendemos desenvolver as idéias contidas neste artigo.

2. Informática e Educação No início dos anos 80 a comunicação informatizada – ou telemática – emergiu, conforme nos revela Levy(1998), “como um fenômeno econômico e cultural: redes mundiais de universitários e pesquisadores, redes empresariais, correios eletrônicos, comunidades virtuais se desenvolvendo sobre uma base local, acesso direto a bases de dados etc”. Mas foi somente no fim dos anos 80 que a Internet, “rede das redes”, tornou-se “o símbolo do grande meio heterogêneo e transfronteiriço”: o ciberespaço.

A cada mês, o número de pessoas com endereço eletrônico no mundo aumenta em 5%. Em 1994, mais de 20 milhões de pessoas, essencialmente jovens, estavam “conectados”. As previsões giram em torno de 100 milhões de usuários para o ano de 2000. Graças às redes digitais, as pessoas trocam todo tipo de mensagens entre indivíduos ou no interior de grupos, participam de conferências eletrônicas sobre milhares de temas diferentes, têm acesso às informações públicas contidas nos computadores que participam da rede, dispõem da força de cálculo de máquinas situadas a milhares de quilômetros, constroem juntos, mundos virtuais puramente lúdicos – ou mais sérios – constituindo para os outros uma imensa enciclopédia viva, desenvolvem projetos políticos, amizades, cooperações..., mas dedicam-se também ao ódio e a enganação”. (Levy, 1998, p.12)

É evidente, nesse sentido, o papel central que as novas tecnologias de informação e comunicação (NTIC's) vêm desempenhando neste processo de transformação. Assim, com o desenvolvimento das NTIC's e da própria Internet, novas maneiras de pensar e de agir são freqüente e rapidamente re-elaboradas em nossa sociedade informatizada. As relações entre homens, trabalho e a própria inteligência dependem, na verdade, da metamorfose incessante de dispositivos informacionais de todos os tipos. Escrita, leitura, visão, audição, criação e aprendizagem são potencializadas por uma informática cada vez mais avançada. O cenário que se apresenta se constitui ao mesmo tempo como um desafio e uma oportunidade ao mundo da educação conforme nos revela Dowbor(2001):

É um desafio, porque o universo de conhecimentos está sendo revolucionado tão profundamente, que ninguém vai sequer perguntar à educação se ela quer se atualizar. A mudança é hoje uma questão de sobrevivência, e a contestação não virá de “autoridades”, e sim do crescente e insustentável “saco cheio” dos alunos, que diariamente comparam os excelentes filmes e reportagens científicos que surgem na televisão e nos jornais com as mofadas apostilas e repetitivas lições da escola.

Segundo Dowbor(2001), as transformações que vêm ocorrendo em todo o planeta estão, no entanto, “muito além de uma simples mudança de tecnologias e de comunicação e informação”. Para o educador, estas transformações devem ser incluídas em nossa visão sobre educação. Não se trata apenas de mudar a técnica de ensino fazendo o uso de novas tecnologias, mas, sobretudo, de modificar a própria concepção de ensino e de repensar os seus caminhos. Hoje em dia não se aprende apenas no prédio físico da escola, mas em casa, no escritório ou em qualquer lugar que se possa ter acesso à informação. Da mesma forma como a inteligência humana inventa novas ferramentas tecnológicas, existe um efeito inverso: a tecnologia modifica a expressão criativa do homem, modificando sua forma de adquirir e de produzir conhecimento, interferindo assim em seu universo cognitivo (Levy, 1993). Por outro lado, alheia a essa modernidade tecnológica e cognitiva, sabe-se que grande parte da população brasileira ainda tem dificuldades de acesso às vias públicas e regulares da escolaridade normal. Assim, fazendo uso de novas tecnologias computacionais e da informação, uma nova modalidade de educação vem se

apresentando como promissora (e muitas vezes como a única possibilidade) na paisagem educacional para grande parte dos nossos atores sociais: a educação ou ensino a distância. Mas será que esta modalidade educacional, apresentada no cenário nacional como solução para certos problemas locais da educação brasileira, serve como paradigma para a educação do futuro? É exatamente sobre isso que pretendemos discorrer nos parágrafos seguintes.

3. Ensino a distância versus ensino presencial O que é Educação a Distância? Segundo Petters(2001), já existem pelo menos três gerações de ensino a

distância. A primeira geração, que utiliza o material impresso como meio principal, foi denominada pelo autor como ensino a distância por correspondência. A segunda geração foi caracterizada pelo autor tomando como exemplo a experiência da Open University inglesa, que realiza um ensino a distância que combina outros meios a serviço do ensino acadêmico: televisão, rádio e os centros de estudo. E como exemplo de um ensino de terceira geração, Petters cita o Project Contact North que faz uso dos meios digitais e “toma por base do processo de ensino e aprendizagem nada menos do que quatro formas de teleconferência”. Pelo que expõe o autor, as gerações de ensino a distância podem ser identificadas pelo nível de desenvolvimento dos meios e das técnicas para se atingir as metas do ensino a distância. Mas, em que consistem essas metas? O que caracteriza o Ensino ou Educação a Distância?

Em verdade, existem diversas denominações e conceituações a respeito dessa modalidade. Preti(1996) observa, por exemplo, que muitos acadêmicos não fazem distinção entre Ensino a Distância e Educação a Distância. De fato, Ensino – conforme nos relata o autor – representa “instrução, socialização de informação, aprendizagem, etc.” enquanto Educação 1 é “estratégia básica de formação humana” – conforme relatou o autor em seu artigo. Esta confusão semântica é preocupante, mas quando ela se estende à práxis educativa compromete ainda mais aquilo que se entende por educação.

Preti(1996) propõe, com prudência, que “a EAD, enquanto prática educativa, deve considerar esta realidade [as desigualdades sociais] e comprometer-se com os processos de libertação do homem em direção a uma sociedade mais justa, solidária e igualitária”. Cabe destacar, entretanto, que tal proposta deve ser estendida a qualquer prática educativa, seja ela “a distância” ou “presencial”, seja ela “especial” ou “convencional”, ou mesma de qualquer outra modalidade. A diretriz desenhada acima sempre foi, sem sombra de dúvida, a grande utopia (utopia usada aqui no sentido que Paulo Freire tão bem delineou em seus trabalhos: como “aquilo que é possível, que mobiliza e motiva a ação educativa, meta a ser atingida”, e não como algo “impossível de ser realizado”) que tem motivado grandes educadores (o próprio Paulo Freire foi um deles) em seus trabalhos de campo ou de pesquisa, antes mesmo da EAD ter-se tornado

1 Derivado do latim – educatio, do verbo educare (instruir, fazer crescer, criar), próximo de educëre (conduzir, levar até determinado fim) –, a palavra educação sempre teve seu significado associado à ação de conduzir a finalidades socialmente prefiguradas, o que pressupõe a existência e a partilha de projetos coletivos (Machado, 2000)

mais conhecida. Portanto, tal propósito não pode, e nem deve, constituir efetivamente, como observamos, o elemento diferencial entre a EAD e a educação convencional 2. Mas o que distingue então a EAD da modalidade presencial?

Segundo Sebastián Ramos(1990, apud Preti, 1996), “a essência da EAD é a relação educativa entre o estudante e o professor que não é direta, mas “mediada e mediata””. Para Garcia Aretio(1995, apud, Preti, 1996), a EAD distingue-se da modalidade de ensino presencial por ser “um sistema tecnológico de comunicação bidirecional que pode ser massivo e que substitui a interação pessoal na sala de aula entre professor e aluno como meio preferencial de ensino pela ação sistemática e conjunta de diversos recursos didáticos e o apoio de uma organização e tutoria que propiciam uma aprendizagem independente e flexível”. Desse modo, pode-se afirmar, parafraseando Preti(1996), que os “elementos constitutivos” da EAD são:

− a distância física professor-aluno: a presença física do professor não é indispensável e ela se dá de modo virtual;

− estudo individualizado e independente: investe-se aqui no desenvolvimento da autonomia dos estudantes nos processos de aprendizagem; “o estudante deve aprender a construir seu caminho, seu conhecimento por ele mesmo”;

− processo de ensino-aprendizagem mediatizado: a mediatização ocorre através do material didático 3, meios tecnológicos, sistema de tutoria e de avaliação;

− o uso de tecnologias: o rápido e crescente desenvolvimento de recursos técnicos de comunicação e de informática têm possibilitado cada vez mais romper com as barreiras das distâncias, das dificuldades de acesso à educação e dos problemas de aprendizagem de quem “estuda individualmente, mas não isolado e sozinho”;

− a comunicação bidirecional: no processo de EAD busca-se estabelecer “relações dialogais, criativas, críticas e participativas” com o estudante; “o estudante não é mero receptor de informações”.

Portanto, ao nos depararmos com os elementos constitutivos listados pelo pesquisador, podemos perceber que algumas características e metas da EAD fazem (ou deveriam fazer) parte de um processo educacional em sentido amplo. De fato, a comunicação bidirecional, o formato dialógico do material didático, o uso de tecnologias deveriam ser também características e metas de qualquer modalidade de educação. Por isso, não poderíamos tomar esses elementos constitutivos como elementos diferencias entre a EAD e a educação presencial, a menos, é claro, do primeiro elemento que circunstancia e justifica a ação da primeira modalidade de educação.

Isto posto, pode-se afirmar então que o que distingue a EAD da modalidade presencial é efetivamente a sua circunstância: a distância física entre o aluno e o seu professor. No entanto, cabe ressaltar que na modalidade presencial, se não existe a distância física, existem também outros tipos de distâncias na relação professor-aluno: a

2 Importante que se diga que Oresti também não pretendia que este fosse o elemento diferencial entre a EAD e a educação convencional. 3 Cabe ressaltar aqui o formato dialógico presente na linguagem escrita do material didático: além de tornar a leitura mais agradável, faz com que o aluno desenvolva o processo de construção do conhecimento de forma mais crítica e consciente.

distância da linguagem, a distância de metas e objetivos, etc. Por outro lado, é notável o grande esforço que alguns educadores têm feito na tentativa de minimizar essas distâncias no ensino presencial. Assim, ao que parece, poder-se-ia concluir que um dos principais objetivos do ato educativo em qualquer modalidade, seja na modalidade presencial ou na modalidade a distância, é minimizar as distâncias. E nesta nobre ação de minimizar as distâncias, a parceria entre as teorias e as práticas da EAD e as do modelo presencial é de fundamental importância para o aprimoramento da prática educativa em seu sentido amplo. Neste sentido, cabe destacar que o uso de novas tecnologias, prática tão comum na EAD, tem-se mostrado um instrumento em potencial para a redenção e renovação da didática.

4. Novas tecnologias: o resgate da didática Para discutir alternativas para a estrutura do ensino nas condições de um mundo globalizado onde é possível o uso de novas tecnologias para a produção e transmissão de conhecimento, vamos colocar em destaque os relacionamentos que existem no cenário educacional. 4.1 Tipos de Relacionamentos no Cenário Educacional

Em qualquer cenário educacional podemos evidenciar diversos relacionamentos importantes acontecendo ao mesmo tempo. Para analisarmos as possíveis relações existentes distinguimos classes de atores deste cenário: classe dos alunos, classe dos professores e classe do próprio saber (dos conteúdos).

Em uma situação ideal de aprendizagem, seja presencial ou a distância, cada classe está relacionada com ela própria, o que é assinalado na figura acima pelas setas curvas. Desta forma estamos enfatizando:

− A interação entre alunos que permite que eles troquem idéias, dúvidas e respostas sobre o conteúdo;

− Relacionamentos entre os professores que trocam idéias e partilham experiências;

− Relacionamentos entre os próprios conteúdos que, hoje em dia, surgem e se renovam em alta velocidade. Isto faz com que num espaço bem curto de tempo muitos conhecimentos novos surjam e outros se renovem.

Estas são as relações entre entes da mesma classe. Mas podemos ainda pensar nas relações estabelecidas entre classes distintas: relações entre alunos e professores, entre alunos e saberes, entre professores e saberes. A parceria, citada anteriormente, entre as práticas da EAD e as do modelo presencial pode servir para diminuir as distâncias envolvidas nestes relacionamentos que estão sendo abordados. 4.2 As Novas Tecnologias Alterando os Tipos de Relacionamentos As mutações contemporâneas nas relações entre os atores humanos do cenário educacional – sejam entre alunos, entre professores ou entre alunos e professores – se devem em grande parte ao uso de ferramentas de comunicação síncronas e assíncronas tais como fóruns, chats, e-mail e listas de discussão.

Vamos refletir sobre o relacionamento de humanos com o saber, tanto de alunos quanto de professores. A natureza destes relacionamentos vem mudando ao longo dos anos face à utilização das novas tecnologias que disponibilizam, de formas variadas, uma riqueza muito grande de conteúdo. Os recursos multimídia, por exemplo, permitem um envolvimento multissensorial e intelectual dos alunos com os saberes. Usam a audição, a visão, a fala, o tato e até o olfato, como apontam pesquisas recentes, em algumas vezes; em oposição à maneira unissensorial de se relacionar com o conteúdo oferecida por uma aula expositiva. Tudo isto acaba gerando uma nova forma de perceber o conteúdo, e portanto, uma nova forma de se apropriar dele. Além do uso de vídeo, sons e imagens, os variados recursos de interatividade presentes nas plataformas, sites e agora na TV digital, acabam reformulando a própria postura do aluno frente ao conteúdo e ao saber. Tais recursos muitas vezes requerem do aluno tomadas de decisões, e conseguem transformar o aluno passivo em um participante ativo na construção de seu saber. Conseguem-se interações bem mais intensas com o uso das mídias eletrônicas, como bem é abordado em Pina(1998).

4.3 O Resgate da Didática – Novas Concepções e Novas Demandas Neste momento nos remetemos a Borba(2001), que chama atenção para o fato de que a questão contemporânea não é mais se as novas tecnologias devem ou não estar presentes no ensino. O autor discute, inclusive, o fato de que o lápis e o papel também são tecnologias que empregamos indiscriminadamente no ensino e nem por isso paramos para questionar se o aluno fica ou não dependente dessas mídias. Não deveria ser esta a questão discutida. As novas tecnologias estão cada dia mais presentes na vida das pessoas (estudantes e professores), e isto é um fato incontestável. Elas são novos atores no cenário educacional. A questão relevante deveria ser: como agregá-las ao dia-a-dia do professor? Como adequar os métodos de trabalho? Como minimizar as distâncias relatadas na introdução? Como conciliar as técnicas de EAD com o ensino presencial? Como viabilizar esta modificação? Como escolher um software que seja adequado ao conteúdo trabalhado, por exemplo? Que critérios utilizar na escolha? Que ferramentas utilizar em cada situação didática? Como fazer um bom uso das novas tecnologias disponíveis em prol de um melhor aproveitamento dos alunos? Que ambiente computacional usar para melhor alcançar objetivos educacionais? E poderíamos continuar listando várias questões que confirmam o novo cenário com

novos atores, e que querem respostas de como devem atuar juntos daqui para diante. Todas estas questões merecem muitas reflexões e estudo. Não vamos discutir todas as questões apresentadas, mas já pudemos constatar na prática o que é exaustivamente analisado em Belloni(1999): “Não é possível o uso das NTIC´s sem profundas mudanças nos modos de ensinar e na própria concepção e organização dos sistemas educativos, gerando profundas modificações na cultura da escola.”

Em outras palavras, não é viável o uso de novas tecnologias de informação e comunicação no ensino sem profundas reformulações na maneira de ensinar, visto que novas formas de aprender exigem novas formas de ensinar. Neste sentido enxergamos o uso das novas tecnologias no processo educacional como um resgate da didática. Uma didática que aponte alternativas para o ensino inserido neste mundo contemporâneo. A força inovadora que a informática na educação traz potencialmente sempre foi neutralizada pela força do modelo arcaico da educação nas escolas. Ainda hoje existem escolas que impedem os professores de entrar nos laboratórios de informática. Se quiserem desenvolver algum trabalho com os alunos, o professor deve passar para o professor de informática (ou orientador tecnológico) o que deve ser feito.

Apesar de concordarmos com a importância do uso das novas tecnologias no ensino devemos apontar que, salvo exceções, seu uso é ainda bastante incipiente na maioria das instituições de ensino. Há uma necessidade muito grande de experiências de uso das NTIC´s em cursos de graduação para gerar mais questionamentos que possam alimentar e aprofundar essa reflexão.

O uso responsável de novas tecnologias no ensino envolve ainda outra questão fundamental a ser considerada, que é a da segurança da informação. Vivemos num tempo em que navegar na Internet pode ser perigoso, e o aluno deve ser alertado e preparado para isso. O ambiente escolar pode e deve estimular o uso da Internet como ferramenta didática, desde que também ofereça conhecimentos para que os alunos não fiquem vulneráveis na rede. As redes de transferência peer-to-peer, as redes de relacionamento e as redes de comunicação instantânea são usadas em grande escala por jovens e adolescentes que, em sua maioria, desconhecem os perigos existentes em seu uso. A Internet não é segura para crianças; elas precisam ser orientadas. Entre os possíveis perigos existe o da pedofilia. Segundo Chappell(2006), uma simulação feita pela Internet Safety for Kids (www.packet-level.com) criou perfis de crianças de até 13 anos e entrou em chats e comunicadores instantâneos. Constatou que em 100% dos casos houve requisição sexual, e que esta ocorreu após 3 minutos de contato, em média, tendo levado, no máximo, 7 minutos e 12 segundos, depois de juras de amizade eterna.

5. A escola do futuro O modelo medieval de transmissão de conhecimento foi profundamente abalado

pela revolução que o livro impresso fez. O ensino passou por mudanças estruturais face a esta nova tecnologia. Com o advento da TV e do videocassete, a produção de tele-aulas e vídeos educativos tornou-se uma “coqueluche educacional”: uma imagem vale mais que mil palavras. O programa TV Escola, da SEED/MEC (Secretaria de Educação a Distância) destinado exclusivamente à educação, conta com um grande acervo de

vídeos educativos de alta qualidade e pode ser usado de forma a melhorar a aprendizagem como apontado em Motta&Lopes(2002). Neste artigo as autoras sugerem ainda a utilização de um sistema de recomendação voltado para equipes. A revolução dos meios digitais nos pede agora um novo modelo de produção/transmissão de conhecimento. Que novo modelo seria este? Vamos tentar imaginá-lo hipoteticamente e gerar a nossa própria utopia, no sentido descrito neste artigo anteriormente.

Nosso aluno hipotético, Bruno, nasceu em 1995 e, portanto, está agora com 20 anos. Está cursando a graduação em Engenharia de Alimentos, uma carreira já antiga e multidisciplinar. Em 2010, Bruno optou por sua carreira depois de um longo trabalho de orientação vocacional desenvolvido em sua escola. Bruno assistia, na escola, semanalmente, pela TV Digital Interativa, a palestras com profissionais do mundo todo de diversas áreas, inclusive as mais recentes provenientes de fusões interdisciplinares. Bruno anotava em seu palm-top suas questões e depois das palestras fazia perguntas aos profissionais que estavam on-line e respondiam suas dúvidas. Foi numa destas palestras que Bruno fez contato com o diretor de uma indústria de produtos alimentícios que o convidou para conhecer um dia de trabalho efetivo de uma pessoa da área de racionalização e melhoria de processos e fluxos produtivos para incremento da qualidade e produtividade, e para redução dos custos industriais. Empolgado e elucidado pela visita ele decidiu sua carreira. Nas vezes que precisou faltar à escola, assistiu às palestras em seu celular.

Hoje, em 2015, na turma de Bruno estudam outros 29 jovens que convivem seis horas por dia numa escola contendo salas equipadas, cada uma, com dez mesas e cadeiras individuais, duas mesas maiores para trabalhos em grupo, dez computadores sendo um deles ligado permanentemente a um datashow, uma televisão com tela de plasma de 71 polegadas e com decodificador e aparelho de DVD embutidos, isolamento acústico, prateleiras com livros, prateleira com DVD´s e mapas nas paredes. Tanto Bruno quanto seus colegas e professores lidam muito bem com todas as tecnologias em questão. Os conceitos são trabalhados através de temas de interesse da turma e culminam no desenvolvimento de projetos realizados por alunos. As aulas podem ter uma parte expositiva para explanação geral do encaminhamento dos trabalhos ou mesmo para exposição feita pelos alunos a respeito de seus projetos para localizar alguma dúvida que possa ser compartilhada/discutida pela turma. Os alunos trabalham incessantemente na busca dos conhecimentos necessários para a realização de sua tarefa, mas não precisam estar todos ao mesmo tempo fazendo a mesma atividade. O professor programa atividades distintas para serem realizadas numa mesma aula: algumas individuais e outras em grupo. Os alunos são livres para usar o computador (com softwares e Internet para acesso a bibliotecas digitalizadas e uso de fóruns propostos pelos professores) e os livros da estante para aprofundar seu conhecimento e realizar sua tarefa. Têm palestras periódicas sobre segurança da informação para se conscientizar dos perigos existentes na rede, aprender a usá-la com responsabilidade e conhecimentos para não ficar vulneráveis a situações de risco. A TV digital é usada sempre que necessário. Os alunos são atores ativos na realização da tarefa de construção de conhecimento. Seus professores têm excelente formação, são bem remunerados e se dedicam a sua própria capacitação/atualização constantemente. Trabalham de forma interdisciplinar e não raramente propõem atividades interdisciplinares para a turma. Em especial, as aulas práticas de língua estrangeira acontecem durante pesquisas na Internet e debates entre grupos. Como a tarefa dos professores não se limita à transmissão de

algum conhecimento previamente estabelecido, eles conseguem estimular e proporcionar a pesquisa em sala de aula. Acima de tudo, esta escola consegue formar alunos felizes, com uma formação sólida e não fragmentada, e conscientes de seu papel numa sociedade de recursos naturais finitos.

6. Conclusão Por mais que as novas tecnologias já estejam presentes em nosso meio há algum tempo, ainda precisamos viver algumas transições nesse longo percurso. • Em primeiro lugar, é preciso que se faça uma análise crítica das possibilidades e

limitações no uso das NTIC's tendo como meta a implementação de uma educação mais progressista e menos excludente. A política de informática da educação tem que passar de elitista a inclusiva.

• Sabe-se, todavia, que o uso das NTIC's produzem profundas transformações no ambiente educacional, no processo ensino-aprendizagem e exigem por sua vez novas formas de organização do tempo, do espaço e das relações internas da escola. Por conta disso, faz-se urgente e necessária uma reorganização dos sistemas educativos nas escolas.

• Este processo de transformação educacional não deve se restringir apenas à educação básica. As experiências no ensino de graduação precisam ser estimuladas e incrementadas, principalmente no que está relacionado aos cursos de Licenciatura, formadores da consciência cidadã. Não basta assimilar informática, Internet e outras tecnologias do conhecimento; a formação de professores tem que se tornar mais efetiva neste sentido.

Considerando as transformações no universo do conhecimento e das ferramentas

de trabalho, torna-se evidente que a educação deva repensar o seu paradigma e procurar assimilar a dinâmica desta sociedade mutante. Entretanto, esta transformação pedagógica não pode perder de vista a tradição e os valores da humanidade. Como reflexão deixamos a mensagem de uma testemunha da Segunda Guerra Mundial dirigida aos professores e citada na abertura do texto de Dowbor(2001):

“Prezado Professor, Sou sobrevivente de um campo de concentração. Meus olhos viram o que nenhum homem deveria ver. Câmaras de gás construídas por engenheiros formados. Crianças envenenadas por médicos diplomados. Recém-nascidos mortos por enfermeiras treinadas. Mulheres e bebês fuzilados e queimados por graduados de colégios e universidades. Assim, tenho minhas suspeitas sobre a Educação. Meu pedido é: ajude a seus alunos a tornarem-se humanos. Seus esforços nunca deverão produzir monstros treinados ou psicopatas hábeis. Ler, escrever e aritmética só são importantes para fazer nossas crianças mais humanas.”

As novas tecnologias são, de fato, importantes para a transformação que se impõe no cenário educacional, mas saber usá-las bem (e para o bem) não é apenas um

problema de natureza técnica. Uma boa Educação deverá estar sempre alicerçada em valores tradicionais da humanidade, do ser (verbo) humano.

Referências Belloni,M.L. (1999) “Educação a Distância”, Coleção Educação Contemporânea. Campinas, Editora Autores Associados. Borba, M. e Penteado,M. (2001) “Informática e Educação Matemática”, Coleção Novas Tendências em Educação Matemática, Belo Horizonte, Editora Autêntica. Chappell,L. (2006) Entrevista dada à revista Security Review, a revista do gestor de Segurança da Informação, ano II, nº 8. Dowbor, L. (2001) “Tecnologias do Conhecimento. Os desafios da Educação” Rio de Janeiro: Vozes. Levy, P. (1993), “As Tecnologias da Inteligência. O Futuro do Pensamento na Era da Informática” São Paulo: Editora 34. Levy, P. (1998), “A Inteligência Coletiva. Por uma Antropologia do Ciberespaço” São Paulo: Edições Loyola. Machado, N. J. (2000), “Educação: Projetos e Valores” Coleção Ensaios Transversais vol.5. São Paulo: Escrituras Editora. Motta, C.L.R. da e Lopes,L.M.C. (2002), “Sistema de Recomendação apoiando a TV Escola”. XIII Simpósio Brasileiro de Informática na Educação, Unisinos. Petters, O. (2001), “Didática do Ensino a Distância. Experiências e Estágio da Discussão numa Visão Internacional” Trad. Ilson Kayser. São Leopoldo: Editora Unisinos. Pina, A.R.B. (1998), “Sistemas Multimídia, Para uma Tecnologia Educacional” cap 8, (org. Juana Maria Sancho). Porto Alegre, Artmed Editora. Preti, O. (1996), “Educação a Distância: Inícios e Indícios de um Percurso” NEAD/IE – UFMT. Cuiabá: UFMT.

Um RPG Educacional Computadorizado e MissõesContextualizadas com seus Ambientes

Michele A. Tobaldini1, Jacques D. Brancher2

1Departamento de Ciências Exatas e da Terra - Universidade Regional Integrada do AltoUruguai e das Missões (URI)

2Departamento de Engenharias e Ciência da Computação – Universidade RegionalIntegrada e das Missões (URI)

matobaldini@gmail.com, jacques@uri.com.br

Resumo. Este artigo descreve o desenvolvimento e utilização de um ambiente

com aspectos biogeográficos reais e arquiteturas históricas, para inserção de

missões didáticas. Essas, contextualizadas com os cenários, objetivando gerar

uma maior imersão do usuário em um jogo educacional computadorizado

para alunos de 5ª a 8ª séries do Ensino Fundamental.

1. Introdução

O meio educacional vem sendo alterado devido a utilização do computador,principalmente quando se concebe a educação como uma transferência deconhecimentos. A aprendizagem depende de ações como experimentar, interpretar,visualizar, abstrair e demonstrar. O educando não é mais passivo frente a apresentaçãoformal do conhecimento, pelo contrário, é um ser pensante e, como tal, capaz deconstruir seu próprio conhecimento [Moro et al. 2004].

Vivemos em uma sociedade que exige a criação, a globalização, aresponsabilidade, a autonomia e a capacidade para lidar com a virtualidade e as novastecnologias; habilidades, estas, que podem ser desenvolvidas através do jogo de RPG.Nesse sentido, é reiterada a importância do desenvolvimento de pesquisas que exploremo uso destas tecnologias no processo educativo, afim de que se construam melhorias nosjogos computadorizados didáticos, enfatizando a construção de novas metodologiasmais adequadas às necessidades de sala de aula [Bittencourt e Giraffa 2003].

Com o objetivo de desenvolver um jogo do tipo RPG educacionalcomputadorizado, que aborde conteúdos didáticos de maneira integrada, contextualizadacom o ambiente do jogo, o Projeto RPGEDU tem a proposta de criar um ambienteutilizando aspectos biogeográficos coerentes e determinadas arquiteturas históricas.

Na segunda seção discorre-se sobre aspectos gerais de RPG, na terceira seçãodefine-se RPGs digitais, na próxima seção define-se jogo computadorizado e apresenta-se a proposta do jogo em desenvolvimento, “Taltun: A Terra do Conhecimento”. Naquinta seção, o processo de desenvolvimento dos cenários é apresentado e descrito. Nasexta seção, discorre-se sobre a abordagem dos cenários no jogo, explicando osobjetivos e exemplificado sua utilização. Finaliza-se com as conclusões pertinentes até opresente momento.

2. Aspectos Gerais de Role-Playing Game

De uma maneira geral, Role-Playing Game (RPG) significa jogo de interpretação de

personagens. Zucchi (2000) descreve que no RPG, cada participante faz parte de umaaventura imaginária, interpretando uma personagem. O cenário e as personagens que ojogador ou jogadores encontrarão no decorrer da aventura são definidos e interpretadospelo mestre. Esse, também descreve as situações que os jogadores vivenciarão,utilizando como referência regras específicas do jogo para tomar decisões, na maioriadas vezes, lançando dados para conseguir um resultado aleatório.

Segundo Bolzan (2003) Role-Playing Game é um jogo de representação, onde aspersonagens interagirão dentro de uma determinada trama, no cenário do jogo, que seráconduzida pelo mestre do jogo. Cada participante constrói sua personagem comdeterminadas habilidades manuais, físicas, deficiências e perfil psicológico. Para darsegmento, o mestre descreve detalhadamente a ambientação e o sistema de regras.

Bittencourt e Giraffa (2003) contextualizam três componentes importantes emum jogo de RPG: ambientação, história e sistema de regras. Ambientação é definidacomo o contexto onde se passa a história, exemplificando: fantasia medieval, futurista,pré-história, ficção científica, dentre outros. História é o roteiro aberto de aventuras ouações determinadas pelo jogador que está inserido no ambiente. Finalmente, o sistemade regras consiste em um conjunto de regras utilizadas para resolução das açõesdescritas pelo jogador.

De acordo com Andrade, Barcia e Pezzi (2004), o RPG possui conceitos básicosque permitem o desenvolvimento do jogo e a comunicação entre os jogadores, sendoeles:

• Jogador: controla as ações de sua personagem (PC – Player Charater) durante ojogo;

• Mestre do Jogo: controla as personagens que interagirão com o jogador duranteo jogo, é responsável pelo desenvolvimento da aventura;

• Sistema de Regras: limita os tipos e níveis das capacidades de uma personagem;

• Cenário: mundo, ambiente em que o jogador está inserido;

• Personagens: são construídos pelo jogador ou oferecidos prontos;

• Trama: aventuras ou ações que ocorrem durante o jogo;

• NPCs (Non-Player Charaters): personagens controladas pelo mestre do jogo oupelo sistema.

A descrição apresentada, refere-se aos “RPGs de mesa”, assim chamados,porque os jogadores costumam sentar-se ao redor de uma mesa para representarem suaspersonagens e interagirem. Na próxima seção discorre-se sobre Role-Playing Games

digitais e determinados aspectos relativos à estes.

3. Role-Playing Games Digitais

Segundo Bolzan (2003) , os primeiros jogos de computador surgiram no fim dos anos50, eram jogos não gráficos baseados em terminais MUDD (Multi-User Dungeons &

Dragons) onde os jogadores interpretavam e incorporavam uma personagem queexplorava mundos descritos na tela do computador. Os jogos eram essencialmenteverbais, o computador era programado para responder com palavras às opções dojogador. Assim, eram jogos complexos, com uma infinidade de opções, ações e

combinações que proporcionavam liberdade ao jogador. O banco de dados desses jogosera ampliado constantemente.

Com a evolução dos computadores, houve um avanço na parte gráfica dos jogos,o que ocasionou um afastamento dos jogos de computador do RPG clássico. Por isso,existe um grande número de jogos de computador auto-intitulados RPGs que sãoaventuras com elementos característicos de RPG.

Bittencourt e Giraffa (2003) citam que a conceituação de RPG digital refere-se aesses no contexto de ciberespaço, utilizando o computador como uma ferramenta.Descrevem ainda que existem três grupos de RPG para computadores: jogos clássicos,com múltiplos jogadores e os mundos virtuais persistentes.

Os jogos clássicos possuem um único jogador, exploração limitada do cenário, atrama consiste basicamente em coletar objetos, as fichas de personagenssão inspiradas nos RPGs tradicionais e não há possibilidade de criar a personagemprincipal. Alguns exemplos de jogos clássicos são Phantasy Star, Ultima I e Final

Fantasy.

Quanto aos jogos com múltiplos usuários, permitem ampla exploração doambiente, a história possui sub-tramas (alguns permitem a criação de aventuras, como éo caso do Neverwinter Nights), é possível criar e evoluir personagens e utiliza umsistema de regras. Exemplifica-se com os seguintes jogos: Baldur's Gate e NeverWinter

Nights.

Os mundos virtuais persistentes possibilitam que um grande número dejogadores interaja em um mundo virtual, exploração ampla do mundo, tramas nãolineares, possibilidade de interpretação e cooperação, personalização da personagem ecriação de objetos. Como exemplo, cita-se o jogo Ultima Online.

O jogo em desenvolvimento caracteriza-se como um RPG educacionalcomputadorizado, com determinados aspectos, elementos e objetivos que serão descritosna seção seguinte.

4. Jogo “Taltun – A Terra do Conhecimento”

O Projeto RPGEDU (Role-Playing Game Educacional) tem o objetivo de desenvolverum jogo do tipo RPG educacional computadorizado onde serão abordados conteúdosdas disciplinas de Ciências Naturais, Geografia, História, Língua Portuguesa eMatemática de 5ª a 8ª séries do Ensino Fundamental. O nome desse jogo será “Taltun –A Terra do Conhecimento”.

Battaiola (2000) define jogo computadorizado como um sistema composto portrês partes básicas: enredo, motor e interface interativa. O enredo define o tema,objetivos e seqüência do jogo. A interface interativa controla a comunicação entre omotor e o jogador atribuindo graficamente um estado novo do jogo. O motor é omecanismo que controla as reações do jogo em relação às ações do jogador.

4.1. Enredo, Interface e Motor

O enredo do jogo em desenvolvimento envolve a conquista de gemas que podemabrir o Templo do Saber, onde se encontra o conhecimento do Mundo de Taltun, essedividido em quatro reinos, devido ao fato de existirem personagens de diferentes raças eclasses inseridas no jogo: Azon – reino de anões, Mizun – reino de humanos, Taus –

reino de elfos e Iorlas – reino de magos-humanos, além destes reinos, existe a Ilha deMur. O jogador deve percorrer os quatro reinos, descobrindo partes de seu passado,realizando atividades didáticas (missões de RPG com conteúdos didáticos) e atividadesde jogabilidade (que utilizam os atributos específicos do jogador), para impedir que ovilão conquiste as gemas e tome todo o conhecimento para si, assim, dominando omundo do jogo.

As gemas são conquistadas através da aquisição de pontos de conhecimento porparte do jogador, que nesse jogo têm a função que os pontos de experiência têm emRPGs tradicionais. Os pontos de conhecimento são adquiridos através da realização deatividades didáticas, essas se dão por duas formas: através de interação com o cenárioou interação com NPCs (Non-Personal Characters) ou seja, personagens não-jogáveisque interagem com o jogador.

A interface foi elaborada de acordo com a divisão que alguns autores Bethke(2003), Clua e Bittencourt (2005) fazem em jogos: interface out game e in game. Ainterface out game é referente aos menus presentes fora do jogo, como o menu inicial,novo jogo e opções. No planejamento desta, uma vez que foram definidas todas as telas,estas foram relacionadas através do fluxo de menus. A interface in game é aquela queexibe informações sobre o usuário em tempo de jogo como HUD (Heads Up Display),inventário e missões, tanto em andamento, como as concluídas. A aparência levou emconta o uso de metáforas em interfaces [Lévy 2000, Braga 2004] como o uso de umlivro na tela inicial e, do mesmo aberto em diferentes situações em que o usuário estará,como ilustra a Figura 1.

Figura 1. Aplicação de metáfora na interface do jogo

O outro elemento de jogos computacionais é o motor, também conhecido comoengine. Para isso, foi utilizado o OGRE (2006) (Objectc-oriented Graphics Rendering

Engine) que é um motor gráfico de código aberto (open-source) que funciona na maioriadas plataformas existentes [de Farias et al 2005]. Esse motor aborda os aspectos gráficosdo jogo e, além deste, foram utilizadas diferentes APIs (Application Programming

Interface) que tratam de diversos aspectos como as colisões e aplicação da física noambiente OPAL (2006) (Open Physics Abstraction Layer) e tratamento de sons OpenAL

(2006) (Open Audio Library).

Devido ao fato do jogo computadorizado em questão ser do tipo RPG, certosaspectos, tais como alguns elementos de RPG, foram abordados. Na seção posterior,descreve-se a utilização desses elementos no jogo “Taltun – A Terra do Conhecimento”.

4.2. Abordagem de Elementos de RPG

No jogo em desenvolvimento faz-se uso de determinados elementos de RPG:

• Atributos: Força, Constituição, Destreza e Poder Mágico;

• Pontos de Experiência (XP);

• Player Character - Jogador;

• Non-Player Characters – Personagens Não-Jogáveis.

Os atributos são elementos importantes de RPG, caracterizam o personagemjogador e definem suas habilidades específicas e limitações. No jogo em questão, ospontos de força atuam diretamente sobre as aptidões de levantar, puxar e empurrarobjetos. O atributo constituição implica diretamente nos pontos de vida, que são umademarcação para determinar a saúde do personagem e a stamina, que define o podermental ou físico de resistir a fadiga e cansaço e está relacionada com quanto opersonagem pode locomover-se no cenário e/ou correr. Como o atributo destreza refere-se a coordenação motora, agilidade, reflexos e equilíbrio da personagem, sua aplicaçãoestará relacionada a manipulação de objetos, ataques a distância, ou seja, lançamento defeitiços e em desvio de ataques, como de bolas de fogo, por exemplo.

Figura 2. Menu Novo Jogo

Nos RPGs tradicionais, ao término de cada aventura, o personagem recebepontos de experiência (XP), estes pontos podem aprimorar as vantagens e habilidadesdo personagem. No jogo em desenvolvimento, os pontos de conhecimento tem a funçãodos pontos de experiência, ou seja, representam os pontos que o jogador adquire nodecorrer do jogo quando realiza “missões didáticas”. Esses pontos podem ser adquiridosapenas através da realização das atividades didáticas, ou seja, atividades que envolvemconteúdos das disciplinas de Ciências Naturais, Geografia, História, Língua Portuguesae Matemática, de 5ª a 8ª séries do Ensino Fundamental.

O personagem jogador ou PC é responsável e tem o controle das ações de um oumais personagens. O personagem do jogador será Hero, da raça humana, suas

habilidades poderão ser configuradas de acordo com o desejo do usuário ou através deum sistema determinado (Figura 2).

Os NPCs ou personagens não jogáveis são controlados pelo sistema, atuamcomo coadjuvantes da trama e interagem com o jogador. Os NPCs do jogo são dediferentes raças, dentre elas: anões, humanos e elfos. Como exemplo, cita-se Alps

Dumen, um personagem que vive nas montanhas e é guardião da gema do Reino deAzon (Figura 3).

Figura 3. NPC Alps Dumen

5. Desenvolvimento do Ambiente

O jogo em desenvolvimento tem fins educacionais, devido a este fator, percebeu-se anecessidade de contextualizar os conteúdos didáticos abordados com o ambiente.Assim, realizou-se uma pesquisa referente a aspectos biogeográficos, para odesenvolvimento do mapa do mundo (Figura 4) e a aspectos históricos, para a seleçãodas arquiteturas adotadas.

Após a realização da pesquisa, criou-se fichas para descrição de cenários, devidoa necessidade de detalhamento e referenciamento destes, para a elaboração dos desenhosque enviou-se, posteriormente para a modelagem dos ambientes do jogo. Essas fichasforam desenvolvidas especificamente para cada tipo de cenário: abertos, como florestas,montanhas e desertos e fechados, como castelos, cidades e templos.

Figura 4: Mapa do mundo de Taltun

Para a modelagem dos ambientes em três dimensões necessita-se de desenhosespecíficos de determinadas partes do cenário. As fichas de descrição de cenários foramdesenvolvidas com o objetivo de gerar desenhos que pudessem suprir essasnecessidades. Os desenhos referentes aos três primeiros reinos foram concluídos, osdemais continuam em andamento.

Em relação aos terrenos, existem três tipos de desenhos específicos necessários:

• o mapa geral, que abrange uma grande área e mostra a localização dos cenáriosespecíficos;

• o mapa específico refere-se a uma pequena região do mapa geral, abrange maisdetalhes que o anterior, mostra alguns como, por exemplo, neve no topo damontanhas, localização de construções e caminhos que o personagem podepercorrer;

• a visão em perspectiva se faz útil por mostrar a diferença de tamanho dosobjetos, como por exemplo, diferença de altura de montanhas e especificação detexturas como grama, terra e pedras.

Quanto aos objetos, percebeu-se a necessidade de um maior detalhamento:

• a visão em perspectiva do ambiente é útil para a modelagem de detalhes geraisdesses pois, realça a relação entre os objetos e representa o tamanho e a posiçãodesses no cenário;

• o detalhamento do objeto se faz necessário dependendo de seu nível, umaimagem específica auxilia a captar traços relevantes e objetos que não aparecemna imagem geral, esse tipo de desenho fica melhor com cores;

• a dimensão do cenário exemplifica o tamanho do personagem com relação aotamanho do cenário;

• a interiorização mostra os objetos arquitetônicos que possuem interior detalhadonecessitam de uma planta baixa, mostrando salas e objetos importantes comopilares, tronos e escadas, por exemplo;

• por último, há a necessidade de uma imagem em perspectiva e colorida dointerior do cenário em questão.

Os seguintes itens constam nas fichas de cenários abertos: localização (no mapado mundo), período histórico, altitude, aspectos biogeográficos, flora, tipo de terreno ereferências (imagens).

As fichas de cenários fechados possuem itens específicos para o detalhamento docenário e sua arquitetura: localização, período histórico, tipo de construção, habitantes,descrição da edificação com suas divisões, detalhes arquitetônicos, altitude e referências(da arquitetura específica e do ambiente).

6. Cenários no Jogo

De acordo com Farago (2003), a aprendizagem contextual é um conceito que incorporauma investigação recente da ciência cognitiva, além de ser uma reação às teoriasessencialmente direcionadas (behaviorismo). O ensino contextual refere-se aaprendizagem como um processo complexo e não mecânico. Através do ensinocontextualizado, o educando processa informações ou conhecimento, fazendo com que

esse passe a ter sentido, sendo interiorizado. Supõe-se que a mente naturalmente busqueo significado no contexto e nas relações.

No jogo em desenvolvimento utiliza-se aspectos biogeográficos e históricos reaiscom o objetivo de gerar uma maior imersão e apresentar as informações de formacontextualizada. Assim, gerando um maior envolvimento entre o usuário e ocomputador.

Segundo Passerino (1998), bons jogos educativos devem apresentardeterminadas características, dentre elas, destaca-se:

• o trabalho com representações virtuais coerentemente;

• a disposição de informações que possam ser apresentadas de diversas maneiras,tais como: imagens, textos, sons, etc. de forma clara e objetiva;

• a exigência de concentração, coordenação e organização por parte do jogador;

• o trabalho com a disposição espacial das informações;

• a possibilidade de um envolvimento entre o jogador e o computador de formagratificante.

Alguns jogos fazem uso de arquiteturas específicas para elaboração de seusambientes, um exemplo dessa utilização é vista no jogo [Ubisoft 2006] Heroes of Might

em Magic V (Figura 5). Neste jogo, a cidade dos magos adota um estilo que lembra obizantino e seus personagens utilizam vestimentas típicas da região de criação desteestilo, tais como turbantes e criaturas mitológicas, como gênios de lâmpadas no deserto.

Para Zuchi (2000), nos jogos de RPG, a fantasia é o principal instrumento, poisalém de tornar a aventura mais interessante, favorece a socialização através daexperimentação de diferentes reações, sentimentos, papéis, pensamentos e situações quepodem ser aceitas na realidade. O exercício constante da imaginação proporcionainstrumentos na interação com a realidade, pois esta não se apresenta de forma linearentre certo e errado, mas sim, como um universo de múltiplas possibilidades.

No aspecto didático, a aprendizagem é significativa quando o aluno incorpora àsestruturas do conhecimento, e estas adquirem significado a partir da relação com seuconhecimento prévio. Segundo Marangon e Lima (2002), apenas quando o educandosai da disciplina e consegue contextualizar é que há ligação com a vida. Através dacontextualização é possível criar relações com o conhecimento prévio do aluno.

Figura 5: Cidade do jogo Heroes of Might and Magic V

Ausubel (1982) cita que a aprendizagem significativa se dá quando a novainformação ancora-se em conceitos previamente existentes na estrutura cognitiva doaprendiz. Vygotsky (1988) descreve o desenvolvimento do indivíduo como resultado deum processo sócio-histórico, dando ênfase ao papel da linguagem e aprendizagem. Aquestão central é a aquisição de conhecimentos pela interação do sujeito com o meio.

Considerando-se a contextualização referente a aprendizagem significativa, afantasia como instrumento que proporciona interação com a realidade e a diferenciaçãonos objetivos propostos em um jogo de RPG, que optou-se por desenvolver os cenáriosutilizando elementos reais, tais como aspectos biogeográficos específicos (clima,vegetação, tipo de solo, altitude, entre outros) e arquiteturas históricas. As atividadesdidáticas, que são os objetivos propostos no jogo em desenvolvimento, têm suaabordagem de modo contextualizado com o cenário.

7. Missões Didáticas Contextualizadas

Para Bolzan (2003), uma das particularidades do RPG refere-se ao cumprimento dosobjetivos propostos na aventura ou campanha. Sendo que esses, não são relativos avencer, mas sim, a completar uma história. Nem sempre o objetivo proposto éalcançado, mas o personagem continua e tem a possibilidade de tentar novamente.

Figura 6: Placa relacionada com uma atividade didática de História

No jogo em questão, o jogador realiza atividades didáticas, que têm a função dasmissões em aventuras de RPGs convencionais. As atividades didáticas se dão dealgumas formas diferenciadas, através de interação com os NPCs que, podem solicitardeterminadas tarefas ao jogador ou através da interação direta com o cenário. Aabordagem dessas tarefas é alterada até quatro vezes, caso o jogador erre. Após essenúmero, sempre há a opção de tentar novamente desde o início.

Apresenta-se a seguir a descrição de duas atividades implementadas, ambascontextualizadas com o cenário. Uma das atividades refere-se a disciplina de História ea utilização de arquiteturas históricas no jogo, a outra, a disciplina de Geografia e aabordagem de elementos presentes no ambiente.

Figura 7: Inscrição na placa descrevendo algumas arquiteturas

O cenário das Montanhas Selba é constituído por uma cadeia de montanhasnevadas com determinados caminhos que o jogador pode percorrer. Dentre essasmontanhas, localiza-se o Castelo de Azon, que é habitado pela monarquia deste reino.Em frente ao castelo, há uma placa (Figura 6) que primeiramente, o jogador nãoconsegue visualizar o que está escrito nitidamente. Mas, se clicar nessa placa, poderávisualizá-la em uma tela (Figura 7). Essa, contém descrições de quatro arquiteturashistóricas: bizantina, grega, romana e gótica. O jogador é questionado sobre qualarquitetura os anões utilizaram na construção do castelo.

Figura 8: Atividade de Geografia sobre Pontos Cardeais

Em outra atividade, um NPC anão solicita ao jogador que vá até umadeterminada região das Montanhas Selba e solucione um enigma, conquistando assim,uma bússola que deverá ser entregue ao mesmo NPC. Como bonificação, o jogadorreceberá 15 pontos de conhecimento, de acordo com a pontuação lógica do jogo. Apósa conclusão da tarefa, o NPC lhe avisará que caso também queira uma bússola poderáretornar e solucionar outro enigma. Depois que conquistar sua própria bússola, aatividade é desabilitada.

Não há noção temporal no jogo em desenvolvimento, sendo assim não houvenecessidade de utilização de luz dinâmica. As sombras do ambiente sãofixas, devido ao uso de luz estática. Porém, podem ocorrer aparentes alterações dassombras devido a visão perspectiva da câmera, como na sombra das pedras quereferenciam os pontos cardeais Leste e Oeste.

O objetivo das atividades didáticas ou missões do jogo contextualizarem-se com

o cenário é de gerar uma maior imersão no ambiente apresentado. Assim, as missõestornam-se parte do jogo, abordando os conteúdos didáticos de forma contextualizadacom o que está sendo visualizado pelo jogador.

8. Conclusão

Devido a relevância da contextualização na aprendizagem significativa, verifica-se anecessidade do desenvolvimento de um ambiente que insira o jogador no contexto dojogo, gerando imersão. Para elaboração de tal ambiente, faz-se necessária a adoção deuma metodologia específica. Principalmente, fazendo-se uso de características reais,como arquiteturas históricas.

Percebe-se a importância da presença maciça de profissionais da área deeducação, tanto no momento de elaboração das fichas de cenários, como no momento damodelagem das imagens obtidas. Essa presença é fundamental para obter-se bonsresultados quanto a fidelidade às arquiteturas selecionadas no ambiente virtual, bemcomo sua vegetação, clima e hidrografia, dentre outros aspectos.

O processo de desenvolvimento adotado mostra-se eficaz, pois é visível que asfichas de descrição de cenário facilitam o trabalho dos desenhistas, através de suariqueza de dados e detalhamento. Assim, os artistas têm melhores condições de repassarinformações aos modeladores através de suas ilustrações.

Para validação relativa a utilização das arquiteturas históricas, vegetação, clima ehidrografia, quanto a imersão do usuário no ambiente do jogo, pretende-se desenvolverum futuro projeto de observação. Após a implementação do jogo, tem-se o objetivo deque estudantes de quinta a oitava séries do Ensino Fundamental tenham contato com omesmo, sendo avaliadas desta forma, a interação dos jogadores com o jogo e o grau deimersão destes, no ambiente.

Referências

Andrade, R. F. F., Barcia, R. M. e Pezzi, S. (2004). O Aprendizado na InternetUtilizando Estratégias de Roleplaying Game. In: Congresso Nacional de AmbientesHipermídia para Aprendizagem – CONAHPA, Florianópolis, Santa Catarina.

Ausubel, D. P., (1982). A aprendizagem significativa: a teoria de David Ausubel. SãoPaulo: Moraes.

Bethke, E., (2003). Game Development and Production. Wordware Publishing, 2003.

Bioware, Corp. (2006) “Neverwinter Nights – Official Page”, http://nwn.bioware.com/,Setembro.

Bioware, Corp. (2006) “Baldur's Gate – Official Page”,http://www.bioware.com/games/baldurs_gate/, Setembro.

Bittencourt, J. R.; Giraffa, L.M.M. (2003). A Utilização dos Role Playing GamesDigitais no Processo de Ensino-Aprendizagem. Relatório Técnico, PontifíciaUniversidade Católica do Rio Grande do Sul, Porto Alegre.

Bolzan, R. F. F. A. (2003). O Aprendizado na Internet Utilizando Estratégias deRoleplaying Game (RPG). Tese de Doutorado, Universidade Federal de SantaCatarina, Florianópolis.

Braga, A. S., (2004). Design de interface: as origens do design e sua influência naprodução da hipermídia. Dissertação de Mestrado, Pontifícia Universidade Católicade São Paulo, São Paulo.

Clua, E. W. G. e Bittencourt, J. R., 2005. In: XXIV Jornadas de Atualização emInformática do XXV Congresso da Sociedade Brasileira de Computação, Capítulo 3:Desenvolvimento de Jogos 3D: Concepção, Design e Programação. SociedadeBrasileira de Computação.

De Farias, T., Pessoa, S., Teichrieb, V. e Kelner, J., (2005). Tutorial: O Engine GráficoOGRE 3D, Simpósio Brasileiro de Jogos para Computador e Entretenimento Digital,São Paulo.

Eletronic Arts, Inc. (2006) “Ultima Online Visitor Center”,http://www.uo.com/ageofshadows/viscent.html, Setembro.

Farago, J. L., (2003). Do ensino da história da matemática à sua contextualização parauma aprendizagem significativa. Dissertação de Mestrado, Universidade Federal deSanta Catarina, Florianópolis.

Final Fantasy Insider. (2006) “The Ultimate Resource”, http://www.ffinsider.net/,Setembro.

Lévy, P.., 2000. A inteligência coletiva: por uma antropologia do ciberespaço. SãoPaulo: Loyola.

Marangon, C., Lima, E., (2002). Os novos pensadores da educação. Revista NovaEscola, São Paulo: Abril, Agosto, n. 154, 19-25.

Moro, F., Tobaldini, M. A., Brancher, J. D., (2004). Problemas Heurísticos deMatemática para Jogos de Computador. Anais do Sbgames, Outubro.

Ogre. (2006) “Ogre”, http://www.ogre3d.org/, Agosto.

Opal. (2006) “Opal”, http://opal.sourceforge.net, Agosto.

OpenAL. (2006) “OpenAL”, http://www.openal.org/, Agosto.

Passerino, L., (1998) “Citing references: Avaliação de jogos educativoscomputadorizados”, http://www.c5.cl/ieinvestiga/actas/tise98/html/trabajos/jogosed/Universidade Luterana do Brasil, Agosto.

Shepherd, Eric. (2006) “Ultima I – Review”,http://www.a2central.com/reviews/ultima1/, Setembro.

Star, Phantasy. (2006) “The Phantasy Star Pages”, http://www.phantasy-star.net/,Setembro.

Ubisoft, (2006) “Heroes of Might and Magic V”,http://www.mightandmagic.com/HeroesV/uk/home.php, Agosto.

Vygotsky, L., (1988). Linguagem, desenvolvimento e aprendizagem. São Paulo: Ícone.

Zuchi I. (2000). O Desenvolvimento de um Protótipo de Sistema Especialista Baseadoem Técnicas de RPG para o Ensino de Matemática. Dissertação de Mestrado,Universidade Federal de Santa Catarina, Florianópolis.

Sistema Integrado e Visualizacao de Conteudos de 5a a 8a

Series Utilizando X3DLuis Biondo, Andre Brandao, Michele Tobaldini1, Jacques Brancher1

1 Universidade Regional Integrada do Alto Uruguai e das MissoesCampus de Erechim, Brasil

{lfbiondo,brandaoihc,matobaldini}@gmail.com, jacques@uri.com.br

Resumo. Este artigo descreve um ambiente virtual para a web que apresentaconteudos de 5a a 8a series do Sistema Brasileiro de Ensino Fundamental. Osoftware oferece aos usuarios uma maneira para explorar conteudos didaticosdas disciplinas de Ciencias Naturais, Geografia, Historia, Lıngua Portuguesa eMatematica, disponibilizados em modulos no ambiente virtual, de acordo comsua complexidade. Para o desenvolvimento deste ambiente, foi utilizada a tec-nologia X3D. Por fim, o sistema oferece uma alternativa para os usuarios lo-calizarem informacoes de uma maneira diferenciada e grafica, com a utilizacaode interacao nao-imersiva.

1. IntroducaoO ensino fundamental brasileiro possibilita aos estudantes uma aprendizagem em salasde aula, com contato direto com professores. Ainda que a criatividade de profissionais daarea pedagogica auxilie no processo de aquisicao de conhecimento, por vezes estudantespodem necessitar de um atrativo a mais para buscar conteudos de uma forma diferenciada.Com o desenvolvimento da computacao e aplicacao da mesma na educacao, tornou-sepossıvel simular ambientes tridimensionais (3D) virtuais para a navegacao de pessoas emlugares de difıcil acesso, dependendo do caso.

A Realidade Virtual surge como opcao para que estudantes tenham uma alterna-tiva diferenciada para a aprendizagem. Atraves da imersao proporcionada pela realidadevirtual, deseja-se que os estudantes adquiram conhecimento pois a interatividade despertamaior interesse na aprendizagem [Pinho 1996]. Alguns aspectos colaboram para a reali-dade virtual ser utilizada na educacao entre eles pode-se destacar: maior motivacao dosusuarios, o poder de ilustracao da Realidade Virtual para alguns processos e objetos emuito maior do que outras mıdias, permite que o aprendiz desenvolva o trabalho no seuproprio ritmo, nao restringe o prosseguimento de experiencias ao perıodo da aula regu-lar, permite que haja interacao, e desta forma estimula a participacao ativa do estudante[Pantelidis 1995].

Partindo-se desta premissa, a proposta do presente trabalho e apresentar um am-biente 3D, construıdo em X3D [Resources b] para visualizacao de conteudos de 5a a 8a

series do Ensino Fundamental. Inicialmente, academicos das areas especıficas, com ex-periencia pedagogica, selecionaram os conteudos didaticos das areas de Ciencias Naturais(Biologia, Fısica e Quımica), Geografia, Historia, Lıngua Portuguesa e Matematica, vistosneste perıodo do aprendizado estudantil. A seguir, identificaram os assuntos abordados,organizando-os desde os mais faceis ate os mais difıceis, considerando o grau de com-plexidade desses. E importante ressaltar que, devido a grande quantidade de conteudos

didaticos, apenas alguns de cada disciplina foram escolhidos, tendo em vista os maisessenciais para os alunos das series abordadas.

Assim, este artigo apresenta um ambiente de visualizacao de conteudos de 5a a8a series, dividido em modulos. Para este fim, o texto esta dividido da seguinte forma:No item 2, e feita uma breve revisao bibliografica, na sequencia sao apresentados algunstrabalhos relacionados. Na secao 4, e apresentado o sistema de organizacao da estruturados conteudos didaticos. A seguir, e abordada a implementacao, bem como as telas devisualizacao de conteudos do sistema. Por fim, as conclusoes e trabalhos futuros seraoapresentados.

2. Realidade Virtual e Educacao

A aplicacao de tecnicas de RV na educacao possibilita a producao de ambientes que po-dem facilitar a aprendizagem de alunos, oferecendo uma alternativa complementar paraadquirir o conhecimento oferecido em sala de aula [Nakamoto et al. 2004]. Tambemdeve-se destacar que o uso de RV possibilita que Ambientes Virtuais proporcionem aosusuarios uma sensacao de imersao pois os mesmos podem navegar e interagir em espacostridimensionais gerados por processamento computacional [Zottino et al. 2004] tornandoassim a RV relevante no que diz respeito a aplicacao na educacao.

Ainda que a aplicacao da Realidade Virtual imersiva torne a interacao e envolvi-mento mais real, solucoes nao-imersivas sao satisfatorias mesmo sem o uso de capacetesou salas de projecao. Oferecer aos usuarios sistemas em que os mesmos possam se movi-mentar, ver, ouvir e manipular objetos torna a aprendizagem mais interessante do queaprender somente em sala de aula.

Os alunos tem diferentes maneiras de adquirir conhecimento com maior facili-dade, podendo ser por meios visuais, verbais ou auditivos [Braga 2001]. A utilizacao deambientes computacionais possibilita que sejam exploradas diferentes modos de apren-dizagem, oferecendo aos usuarios de diversos perfis a utilizacao de um mesmo sistema deauxılio ao ensino [Braga 2001].

Oferecer aos estudantes a oportunidade de navegar em um ambiente virtualfazendo com que os mesmos possam “caminhar” em um sistema possibilita a tarefa deaprendizagem uma alternativa a mais, deferenciando-se do paradigma de apenas abordarconteudos nas escolas com o professor expondo a disciplina, ainda que muitos profes-sores possam utilizar de bons metodos e com resultados interessantes ate os dias de hoje.A RV induz os estudantes a explorar o ambiente modelado de acordo com o contextodo conteudo a ser abordado e possibilita que os estudantes possam estar em lugares quedificilmente poderiam estar na vida real.

Ambientes Virtuais, atraves da imersao, interacao e envolvimento, tornam-se lo-cais ideais para se buscar vivencias multiplas pois, esse mundo virtual nada mais e do queum trabalho multidisciplinar, desenvolvido por especialistas de diferentes areas em buscade um objetivo comum. Esses ambientes multidisciplinares permitem aos usuarios umaaprendizagem mais ampla e integrada exatamente por ser um ambiente rico de possibili-dades [Braga 2001].

3. Trabalhos Relacionados

Diferentes pesquisas sobre este tema sao feitos, no entanto, o presente trabalhodestaca dois que tem grande relacao com o assunto tratado: o Sistema Con-struiRV [Peruzza and Zuffo 2004] e a aplicacao de Humanos Virtuais na Educacao[Ieronutti and Chittaro 2005].

O Sistema ConstruiRV [Peruzza and Zuffo 2004] utiliza o modelo Construtivistade Educacao e foi desenvolvido para a Internet. Trata-se de um ambiente de aprendizagemmultidisciplinar e que esta dividido em salas onde diferentes conteudos sao abordadossimultaneamente. O fato de possibilitar a simultaneidade de atividades e gracas ao usode Java3D e RMI caracterizando um Ambiente Virtual Distribuıdo. Neste sistema, oestudante acessa as salas virtuais inicialmente atraves de uma pagina em que o mesmoopta por qual ambiente ele deseja explorar. Cada usuario tem sua representacao atravesde uma forma humana virtual para ele poder interagir tanto com o ambiente como comoutras pessoas, tambem, representadas com sua devida forma. Trata-se de um sistemaonde a interacao e nao-imersiva uma vez que nao utiliza dispositivos de interacao nao-convencionais, como luvas, capacetes, etc.

O trabalho de aplicacao de Humanos Virtuais na Educacao[Ieronutti and Chittaro 2005] apresenta um estudo dos aspectos relevantes na modelagemde Humanos em Ambientes Virtuais Educacionais (Educational Virtual Environments- EVE) utilizando X3D. Tal artigo trata de uma proposta de se programar humanosvirtuais 3D que realizem a tarefa de ajuda a estudantes, por razao da inviabilidade domundo real de haver um professor para auxiliar cada aluno quando o mesmo explora umambiente. Para atingir tal objetivo, foram levadas em conta algumas camadas (aspectos)basicas de modelagem de humanos propostas por [Funge et al. 1999]: geometrica(trata da aparencia), cinematica (trata das articulacoes), fısica (trata de animacoes),comportamental (trata de como que o humano virtual respondera as acoes do usuario) e,finalmente, cognitiva (trata de como que o conhecimento e adquirido).

Foram desenvolvidos tres diferentes modulos para o desenvolvimento do sistemapara tratar de cada camada: Modulo Comportamental (Behavioral Engine), Modulo deExecucao (Execution Engine) e Modulo de Apresentacao (Presentation module). OModulo Comportamental e referente a camada comportamental, o Modulo de Execucaotrata das camadas cinematica, fısica e geometrica ja, o Modulo de Apresentacao trata daapresentacao das mensagens textuais apresentadas ao usuario, ou seja, a camada cogni-tiva.

A relacao que os dois trabalhos mencionados tem com o desenvolvido e quetrata-se de um sistema multidisciplinar em que o aluno pode entrar em salas de disci-plinas especıficas. No entanto, o ConstruiRV adota o modelo Construtivista e no pre-sente caso, e utilizado o modelo Dinamico. Outro fator diferente e que o sistema de[Peruzza and Zuffo 2004] utiliza a interacao nao-imersiva de visao em terceira pessoa, ouseja, o usuario pode visualizar o seu avatar que o representa ao explorar o ambiente. Emrelacao ao sistema desenvolvido, utiliza a interacao nao-imersiva de visao em primeirapessoa, o que faz com que os “olhos” do usuario seja a tela.

No que diz respeito ao trabalho de [Ieronutti and Chittaro 2005], ambos os sis-temas utilizam X3D nas suas implementacoes mas, o presente trabalho, por utilizar a

visao em primeira pessoa, nao aborda a questao de humanos virtuais. Outro fator comumentre os dois trabalhos relacionados e o aqui exposto e que todos sao sistemas que podemser acessados pela Internet, possibilitando facil acesso aos estudantes.

4. Organizacao Estrutural dos Conteudos DidaticosAusubel [Ausubel 1970] considera primordial tornar a educacao individualizada, cadaaluno deve ser tratado num nıvel adequado as suas potencialidades e o processo de ensinodeve ser realizado de modo que o aluno progrida de acordo com as suas possibilidades,o que pode ser obtido atraves da variacao do tempo, natureza do conteudo e nıvel de di-ficuldade do conteudo. Vygotsky [Vygotsky et al. 1988] descreve o desenvolvimento doindivıduo como resultado de um processo socio-historico, dando enfase ao papel da lin-guagem e aprendizagem. A questao central e a aquisicao de conhecimentos pela interacaodo sujeito com o meio.

O aplicativo apresentado, possibilita a interacao, que se da atraves do usuario(sujeito) e o computador (meio), permitindo que este, navegue de acordo com suas po-tencialidades e o ensino ocorra de acordo com o nıvel do aluno. De acordo com Zuchi[Zuchi 2000], o uso adequado de computadores pode apresentar uma melhoria e eficienciano processo de ensino-aprendizagem, tornando a construcao do conhecimento mais cria-tiva e prazerosa. O computador pode transformar-se em um recurso facilitador que, asso-ciado ao aspecto ludico do processo ensino-aprendizagem, passa a ser percebido como umpoderoso recurso pedagogico, com o qual cada aluno constroi sua propria aprendizagem.

O sistema de organizacao da estrutura dos conteudos didaticos se da atraves demodulos, essa escolha esta condicionada por sua capacidade para estimular o aluno e porsua pertinencia para integrar conteudos. Segundo Sacristan [Sacristan 2000] o modulofacilita a motivacao do aluno, atraves da coerencia entre conteudos, permite estabelecerrelacoes entre diversos conteudos, permite conectar os conteudos com atividades praticas,habilidades diversas que nao costumam depender de conteudos especıficos, favorece aordenacao do trabalho em grupos de diferente nıvel ou ritmo de progresso, marca ciclosde atividade para conteudos com uma coerencia interna, assegura o significado de certosobjetivos e parcelas curriculares.

A selecao e estruturacao dos conteudos abordados deu-se atraves de pesquisasrealizadas por academicos de cada area especıfica, considerando a area cognitivista ea teoria de Piaget sobre a construcao do conhecimento. A area cognitivista abordaquestoes sobre a memoria de trabalho, atencao, percepcao, representacao de conheci-mento, raciocınio, criatividade e resolucao de problemas. A teoria construtivista de Pi-aget, segundo Becker [Becker 1994], define que ocorre a construcao do conhecimentoquando acontecem acoes fısicas ou mentais sobre objetos, provocando o desequilıbrio,resultam em assimilacao (processo cognitivo que consiste na incorporacao de elementosdo meio externo a um esquema ou estrutura do sujeito, assim, ampliando seus esquemas)ou, acomodacao (modificacao de um esquema ou estrutura em funcao das particulari-dades do objeto a ser assimilado) e assimilacao dessas acoes e, assim, em construcao deesquemas ou conhecimento.

Como fontes para a selecao e estruturacao dos conteudos didaticos de 5a a 8a

series do Ensino Fundamental, utilizou-se os PCNs, Parametros Curriculares Nacionais- Terceiro e Quarto Ciclos e livros didaticos conceituados das disciplinas de Ciencias

Naturais, Geografia, Historia, Lıngua Portuguesa e Matematica. Os PCNs constituemuma base nacional comum nos currıculos e servem de eixo norteador na revisao e/ouelaboracao da proposta curricular das escolas [de Educacao Basica ].

5. Implementacao

A implementacao do ambiente, esta dividida em basicamente dois modulos: o principalque agrupa todas as disciplinas em forma de stands, como se fosse uma feira, deixandotodas as disciplinas em um mesmo nıvel e proporcionando uma visao geral das mesmas.O outro modulo e formado pelas estruturas particulares de cada disciplina, em forma deplataforma, onde os usuarios navegam e visualizam os conteudos de forma resumida, uti-lizando um mini-navegador aberto dentro do ambiente 3D. Para a modelagem do ambienteforam utilizados dois editores: o Vizx3D e o VrmlPad.

O editor Vizx3d, da empresa Virtock Technologies [in X3D ], foi utilizado prin-cipalmente para a insercao das propriedades essenciais do padrao X3D e VRML. Dentreas propriedades pode-se destacar a iluminacao, a texturizacao, os aspectos de navegacao(altura e velocidade de locomocao pelo ambiente), a deteccao de colisao, os pontos devisualizacao no ambiente e a insercao de alguns nos especıficos dos padroes X3D eVRML. Um exemplo de no dos padroes mencionados e o no FOG, responsavel peloefeito de neblina nas estruturas. Esse, foi utilizado tambem para insercao de sensores noambiente e principalmente para modelagem das animacoes do mesmo.

O editor VrmlPad, da empresa Parallel Graphics [(a 3D VRML company) ], foiutilizado para a insercao e configuracao do prototipo, ou seja, um no do tipo PROTOresponsavel por abrir o navegador dentro do ambiente, disponıvel em [v.2 ].

A utilizacao de editores visuais (graficos) e relevante devido ao fato de propor-cionar uma maior agilidade na modelagem dos ambientes. O processo de modelagemvisual, se comparado a uma modelagem com um editor texto, e muito mais intuitivo edinamico, dispensando um grande numero de testes (“compilacoes”), a fim de verificara posicao correta dos objetos no espaco tridimensional. Isso comprova uma tendenciaque a propria WEB 3D indica que, praticamente todas as modelagens 3D serao, em umfuturo bem proximo, feitas atraves de editores visuais, deixando a parte de codificacaoda linguagem a cargo desses softwares, permitindo aos modeladores mais liberdade paraexercitar a criatividade [Resources b].

A seguir sera mostrada uma descricao mais detalhada de cada um dos modulos.

5.1. Modulo Principal

As disciplinas foram agrupadas em stands, citado na secao anterior. Cada stand pos-sui um micro-ambiente respectivo para cada disciplina, Matematica, Fısica, Portugues,Geografia, Historia, Biologia e Quımica, como mostra a Figura 1. Cada um dos micro-ambientes foi modelado tentando representar alguma cena ou objetos que identifiquemcada uma das disciplinas por suas particularidades, ou seja, o stand de Biologia, comanimais e plantas, Matematica com figuras geometricas, Fısica com engrenagens, navesespaciais, e assim por diante, como mostra a Figura 2.

Os objetos utilizados em cada stand foram, em sua maioria, coletados em variossites especializados em modelos 3D e Computacao Grafica, como o site [Rocky3d ]. Os

Figura 1. Ambiente principal - agrupamento das disciplinas em stands

Figura 2. Particularidades das disciplinas

modelos e a estrutura principal (paredes) em X3D, foram desenvolvidos utilizando o edi-tor Vizx3D, que tambem e responsavel pela conversao dos mais complexos formatos 3DSpara o VRML.

Como mencionado anteriormente, a estrutura principal foi modelada no formatoX3D e os micro-ambientes em VRML compactado. Esses foram modelados utilizandoum no de agrupamento chamado anchor que serve para agrupar objetos e fornecer apropriedade de hiperlink para os mesmos. Assim, em qualquer lugar dentro do ambi-ente que o usuario clicar, abrira o ambiente em forma de plataforma de cada disciplina[Mes et al. 1997]. Foi utilizado esse formato por dois motivos: (i) por que modelos emVRML nao precisam de validacao para estar em conformidade com o padrao, como oX3D, o que torna a abertura dos arquivos mais rapida, principalmente por serem variosobjetos dentro de cada ambiente, e (ii) com o formato compactado, os arquivos ficammenores, em torno de 10%.

Dentro de cada stand foi colocado um no Inline, “chamando” os micro-ambientesde cada disciplina, esse no serve para referenciar outros ambientes ou objetos para dentrodo ambiente principal. Isso deixa o arquivo mais leve e enxuto, pois permite que objetossejam modelados separadamente, evitando grande aglomeracao de codigo em um unicoarquivo [Resources a].

5.2. Modulo Secundario

A modelagem das estruturas dos conteudos de cada disciplina foi feita em forma deplataformas no formato X3D, seguindo a logica da classificacao dos mesmos, ou seja,respeitando a hierarquia interna de cada disciplina. Cada conteudo esta representado poruma plataforma que tem uma estrutura em forma de quadro negro, modelado em VRML,que contem um no do tipo sensor, responsavel pela chamada do prototipo (PROTO). AFigura 3 mostra um exemplo de quadro negro com um dos conteudos da disciplina dematematica. Esse prototipo, por sua vez, tem a capacidade de abrir uma extensao do IEdentro do ambiente 3D permitindo a visualizacao dos conteudos no mesmo. Dentro doambiente apenas e configurado a chamada externa a esse prototipo e suas propriedadesbasicas, como URL, dimensao e posicao do navegador na cena.

Figura 3. Exemplo de quadro negro com explicacao de um dos conteudos dematematica

A escolha por se usar o VRML em conjunto com o X3D se deu pelas seguintesrazoes: (i) o prototipo usado para abrir o navegador no ambiente e projetado para o for-mato VRML, ou seja, nao e preciso reescrever o codigo para adaptar ao novo padrao e(ii) para evitar o excesso de conteudo para a validacao do padrao X3D, agilizando a aber-tura do ambiente. Outra razao, (iii) para mostrar que os dois padroes sao compatıveis,comprovando uma das caracterısticas do X3D, que tudo que existe em VRML pode serreaproveitado.

No ambiente de cada disciplina, foram implementadas algumas funcoes para fa-cilitar a navegacao do usuario. Entre as funcoes, pode-se destacar o mapa de localizacaopara cada disciplina que, em diversos pontos do ambiente, em forma de paineis, auxiliamo usuario a localizar-se no ambiente. A Figura 4 ilustra o mapa de localizacao, no caso,da disciplina de Fısica.

Entre os objetos modelados, pode-se destacar dois botoes, um para o usuario podervoltar ao modulo principal, possibilitando a escolha de uma outra disciplina e, um se-gundo botao com funcao de fechar o navegador interno do ambiente. Programou-se esseultimo botao porque cada quadro negro ativa um novo navegador e, consequentemente,cada navegador aberto precisa de um dispositivo que o feche. Sem isso, o usuario deve-ria memorizar onde ele abriu cada navegador para poder fechar e tambem acarretaria emmais linhas de codigo para modelar a estrutura necessaria para essa funcao. A Figura 4tambem expoe tais funcionalidades.

Figura 4. Mapa de localizacao em forma de painel da disciplina de Fısica e Fun-cionalidades, mapa de localizacao e botoes de navegacao

Uma vez que os usuarios tem a possibilidade de navegar entre micro-ambientespara explorar os conteudos programaticos, foram implementados caminhos que seassemelham a corredores em 3D. E atraves desses que os alunos podem ter uma imersaono sistema e interacao pois podem escolher qual dos corredores estes usuarios desejampercorrer. A Figura 5 ilustra os corredores em 3D.

Figura 5. Corredores em 3D

Os conteudos de cada disciplina, visualizados neste modulo, estao em arquivos noformato XML, que servem como base de dados para o ambiente. Como esses arquivosnao sao legıveis, ou melhor, estao sem uma formatacao que facilite a leitura do mesmopelo usuario, optou-se em utilizar uma solucao simples, uma folha de estilo XSL para for-matar e transformar as informacoes no padrao HTML [Kay 2002]. Para a transformacaoe visualizacao dos conteudos atraves do navegador interno do ambiente, foi utilizado umscript Java que carrega o arquivo XML na memoria utilizando o parser XMLDOM. Esseparser faz a formatacao do XML em HTML utilizando a folha de estilo XSL, tambemcarregada na memoria, e depois reescreve para o usuario somente o conteudo em um siteHTML. Essa conversao do XML para HTML ocorre inteiramente no usuario (cliente)evitando assim, excessivo trafego de informacoes pela internet.

6. Conclusoes e Trabalhos Futuros

Atraves do desenvolvimento do presente trabalho e estudo de trabalhos relacionados,verifica-se que a possibilidade de utilizacao da Realidade Virtual na Educacao. Os prin-cipais aspectos da RV (imersao, interacao e envolvimento) podem ser positivos e expoemalternativas que fogem do cotidiano escolar, motivando os estudantes a adquirir conhec-imento, nao so dentro da sala de aula, mas em ambientes virtuais. No presente caso,devido a forma de interacao dar-se em primeira pessoa, buscou-se uma maior sensacao deimersao no ambiente.

A organizacao estrutural dos conteudos didaticos em modulos motiva o usuario,atraves da coerencia entre os assuntos, a estabelecer relacoes entre diversos conteudos.Assim, permitindo que o estudante aborde os conteudos, do mais simples e, no decorrerda navegacao pelo ambiente virtual, explore assuntos mais complexos.

O ambiente torna-se mais abrangente devido ao desenvolvimento do sistema servoltado para a Internet. Assim, possibilitando que alunos de diversas localidades acessemo ambiente virtual. Evidenciando a importancia do desenvolvimento de sistemas uti-lizando X3D, associado com o VRML.

A continuacao do desenvolvimento do presente sistema, promovendo um ambi-ente multi-usuario, como no trabalho ConstruiRV [Peruzza and Zuffo 2004] e um possıveltrabalho futuro. Tornando assim, a interacao com o sistema, melhor e mais interessante aoponto de vista do estudante, alem de possibilitar a ideia do Peer-tutoring. A ideia basicadesse, consiste em fazer com que alunos com conhecimentos mais avancados ensinemoutros com menor domınio sobre determinado conteudo.

Outra alternativa de continuidade, como trabalho futuro, seria utilizar a ideia dotrabalho de [Ieronutti and Chittaro 2005] e desenvolver humanos virtuais, mais precisa-mente, professores virtuais que poderiam explicar aos alunos o conteudo que os mesmosdesejam explorar. Ainda no mesmo contexto, poderia-se estudar a possibilidade de inserirsons no ambiente virtual o que poderia tornar o sistema mais atrativo para os estudantes.

Para a verificacao da validade do ambiente, pretende-se aplica-lo em escolas, obje-tivando determinar se ha necessidade de alteracoes para melhorias no sistema e confirma-lo como uma possibilidade alternativa de auxiliar estudantes a buscar conteudos didaticosde uma maneira interativa atraves do uso do computador.

Finalmente, para validacao relativa a utilizacao do ambiente, e possıvel arealizacao de um estudo comportamental de usuarios frente ao sistema, com o objetivode verificar se os alunos realmente tiram proveito dos aspectos da RV e se e adequada aorganizacao estrutural dos conteudos didaticos.

Referencias

(a 3D VRML company), I. P. P. Disponıvel em: (http://www.parallelgraphics.com/).Acesso em: 06 janeiro, 2005.

Ausubel, D. P. (1970). Theory and Problems of Child Development.

Becker, F. (1994). O que e construtivismo? In FDE, editor, SIGGRAPH99: 26th Confer-ence On Computer Graphics, volume 20 of Ideias, Sao Paulo.

Braga, M. (2001). Realidade virtual e educacao. In Revista de Biologia e Ciencias daTerra, volume 1.

de Educacao Basica, S. I. S. Parametros curriculares nacionais.

Funge, J., Tu, X., and Terzopoulos, D. (1999). Cognitive modeling: Knowledge, reason-ing, and planning for intelligent characters. In Press, N. Y. A., editor, Proceedings ofSIGGRAPH99: 26th Conference On Computer Graphics, pages 29–38.

Ieronutti, L. and Chittaro, L. (2005). Employing virtual humans for education and trainingin x3d/vrml worlds. In Revista Computers & Education.

in X3D, I. V. R. T. D. A. Disponıvel em: (http://www.vizx3d.com/). Acesso em: 10janeiro, 2005.

Kay, M. (2002). XSLT Referencia do Programador. Alta Books, Rio de Janeiro, 2ndedition.

Mes, A., Moreland, J., and Nadeau, D. (1997). VRML 2.0. New York: John Wiley &Sons, 2nd edition.

Nakamoto, P., Guimaraes, M., Cardoso, A., Mendes, E., and Takahaschi, E. (2004). Con-struindo um laboratorio virtual de eletrodinamica baseado no paradigma de mapas con-ceituais. In Proceedings of VII Symposium on Virtual Reality in the Schools, pages231–242, Sao Paulo.

Pantelidis, V. (1995). Reasons to use virtual reality in education. In Proceedings of VR inthe Schools, volume 1.

Peruzza, A. and Zuffo, M. (2004). Analise da contribuicao da realidade virtual para aeducacao atraves do sistema contruirv. In Proceedings of VII Symposium on VirtualReality in the Schools, pages 265–276, Sao Paulo.

Pinho, M. (1996). Realidade virtual como ferramenta de informatica na educacao. InAnais do Simposio Brasileiro de Informatica na Educacao, Belo Horizonte.

Resources, W. C. D. http://www.web3d.org/x3d/overview.html. Acesso em: 20 abril,2005.

Resources, X. F. W. C. D. Disponıvel em: (http://www.web3d.org). Acesso em: 20 abril,2005.

Rocky3d, I. Disponıvel em: ( http://www.rocky3d.com/). Acesso em: 03 janeiro, 2005.

Sacristan, J. G. (2000). O Currıculo: Uma Reflexao sobre a Pratica. ArtMed, 3 edition.

v.2, I. W. Disponıvel em: (http://www.wildpeaks.com). Acesso em: 02 janeiro, 2005.

Vygotsky, L. S., Luria, A. R., and Leontiev, A. N. (1988). Linguagem, Desenvolvimentoe Aprendizagem. Icone/EDUSP, Sao Paulo.

Zottino, R., Calonego, N., Abackerli, A., Kirner, T., and Kirner, C. (2004). Ambientevirtual distribuıdo web para maquinas de medir coordenadas utilizando shout3d e rmi.In Proceedings of VII Symposium on Virtual Reality in the Schools, pages 255–264,Sao Paulo.

Zuchi, I. (2000). O desenvolvimento de um prototipo de sistema especialista baseado emtecnicas de rpg para o ensino de matematica. Master’s thesis, Universidade Federal deSanta Catarina.

Uma Exper iência de Ensino-Aprendizagem em uma disciplina de Programação

Mauricio Capobianco Lopes1

1Departamento de Sistemas e Computação Universidade Regional de Blumenau (FURB) – Campus IV

Rua Braz Wanka, 238 - 89035-160 - Blumenau– SC – Brazil

Resumo: Este artigo descreve uma experiência com um método de ensino-aprendizagem em uma disciplina de programação enfatizando os processos de avaliação combinados com este método. A ênfase da experiência aqui apresentada está na diversificação destes métodos e dos instrumentos e critérios de avaliação visando voltá-los efetivamente para a aprendizagem dos estudantes, além de tentar extrapolar elementos estritamente técnicos considerados no ensino de programação.

1 Introdução

A avaliação da aprendizagem é um processo em permanente discussão entre pesquisadores de Educação e de todas as áreas de conhecimento, os quais estão sempre em busca de seu formato ideal. Entretanto, este é um objetivo difícil de ser alcançado uma vez que avaliar significa comparar o real com o ideal e, em um processo educativo, esta é uma tarefa complexa e subjetiva que implica em julgamentos sujeito a muitos questionamentos.

Entre os maiores desafios da avaliação da aprendizagem estão a definição das estratégias mais coerentes para que o aluno apreenda o conhecimento desejado e dos objetivos do processo avaliativo. Estes componentes são fundamentais para facilitar a escolha dos instrumentos e critérios mais adequados para avaliação. Além disso, a própria natureza dinâmica do processo educacional faz com que os avaliadores sempre devem reconsiderar e reavaliar os seus processos de avaliação.

A avaliação não pode estar dissociada da metodologia de ensino-aprendizagem empregada pelo professor. Anastasiou e Alves (2004, p.79-98), por exemplo, apresentam diversas “estratégias de ensinagem”, descrevendo cada estratégia, sugerindo dinâmicas das atividades e a forma e os critérios de avaliação e buscando fornecer ferramentas para diversificar a avaliação.

Silva (2006, p.15) também destaca que “a diversidade de instrumentos avaliativos precisa estar inserida em uma sistemática, atender uma metodologia própria da teoria e da prática da avaliação educacional e adequá-la à natureza do objeto avaliado (...)” , ou seja, os instrumentos de avaliação devem ser diversificados para permitir melhorar a compreensão sobre o sujeito que está sendo avaliado.

Particularmente na área de conhecimento de programação de computadores muitas são as discussões sobre as metodologias dos processos de ensinar e aprender e dos processos avaliativos mais adequados para os estudantes aprenderem a programar computadores. Eventos como o Workshop de Ensino de Informática (WEI) ou o

Simpósio Brasileiro de Informática na Educação (SBIE) apresentam constantemente relatos de experiências nesta linha, a se destacar o trabalho de Santos e Costa (2006) que faz um interessante apanhado sobre publicações realizadas sobre o assunto. Também o trabalho de Fernandes (2002) que apresenta a unificação de quatro linhas pedagógicas buscando uma formação mais completa de um estudante de programação. Já Pimentel, França e Omar (2003) apresentam importantes considerações sobre os problemas enfrentados nos processo de ensino-aprendizagem de programação e propõem uma ferramenta tutorial inteligente para auxiliar o professor e coordenação no acompanhamento dos estudantes.

No entanto, em pesquisas informais com colegas de trabalho de diversas instituições, percebe-se que, via de regra, o processo de avaliação das disciplinas de programação das IES continua centrado na avaliação somativa, ou seja, o professor quantifica o desempenho dos seus alunos baseados nos objetivos definidos em seu plano de ensino-aprendizagem, fazendo esta verificação através de provas práticas conceituais e de implementação de trabalhos práticos em uma linguagem de programação, onde o aluno deve demonstrar seu conhecimento em programação. Também o critério de avaliação normalmente é centrado na resposta a uma única pergunta: o aluno aprendeu a programar? A partir daí para o processo avaliativo, constrói-se uma estrutura de controle em nível de seleção muito simplificada (e, inclusive, já orientada a objetos!): se aluno.aprendeuProgramar() então sistema.escreva (“Aprovado”) senão sistema.escreva (“Reprovado”). fim se

Mas não é este o objetivo final de uma disciplina de programação? Em tese sim, mas este artigo procura demonstrar que em uma disciplina de programação é possível fazer uma avaliação formativa, apresentada por Hadji (2001, p.20) como a forma de favorecer o sujeito aprendente, e defendida por Romanowski e Wachowicz (2004, p.127), que destacam que “a qualidade da argumentação, a percepção aguçada e crítica no exame de dados, a capacidade da articulação de teoria e prática, as habilidades de organização das respostas com logicidade, clareza e coerência, os estilos de fala e escrita, o emprego adequado de princípios e normas formam um conjunto de aprendizagens ao qual se pode atribuir a distinção acadêmica” .

Desta forma, pretende-se demonstrar neste artigo uma experiência de aplicação de diversas estratégias de ensino-aprendizagem em uma disciplina de programação, com ênfase na diversificação dos processos de avaliação, transcendendo apenas um aspecto da formação de um estudante de nível superior em uma disciplina de programação de computadores, qual seja, a aprendizagem de programação.

2 O Contexto

A disciplina de que trata o presente objeto de estudo é denominada de Tópicos em Programação I e ocorre na quarta fase do curso, sendo que nas fases anteriores os estudantes já tiveram conteúdos relacionados a algoritmos e estruturas de dados e às linguagens C e Java. A disciplina tem por objetivo abordar alguns aspectos e formas de construção de programas não abordadas em disciplinas anteriores, tais como: interface gráfica, programação baseada em eventos, programação concorrente e programação distribuída.

Antes desta nova abordagem, a disciplina enfatizava a ferramenta Delphi, a qual foi substituída em função do colegiado do curso optar por retirar o ensino da linguagem Pascal do currículo, mantendo apenas C e Java. Na época, o processo avaliativo da disciplina era feito de forma tradicional, baseado em 2 provas práticas em laboratório (com maior peso) e 1 trabalho final (com menor peso). Na prova prática (realizada individualmente), o aluno tinha 3 horas/aula para resolver um determinado problema dado em um enunciado. Já no trabalho final (realizado em equipe), tinha que ser desenvolvido um sistema com uma certa complexidade utilizando o ambiente. Por tratar-se de tema livre, apareciam os mais variados tipos de implementação, tais como, softwares comerciais, jogos, chats, editores de texto, entre outros, dificultando o estabelecimento de critérios de avaliação que contemplassem os diferentes tipos de sistema.

Também outros questionamentos eram levantados à época: será que a prova é um instrumento que mede a real capacidade de um aluno em resolver um problema de programação? Será que a ênfase em uma disciplina de programação não deve ser os trabalhos de implementação? Em uma disciplina de programação deve-se avaliar apenas a habilidade técnica do aluno em resolver um determinado problema?

Junto com estas perguntas, outras situações também eram incômodas, tais como, o tempo restrito que o estudante tinha para fazer uma prova de programação, fazendo com que a complexidade do problema apresentado pelo professor tivesse que ser reduzida e a dificuldade em controlar a autoria dos trabalhos de implementação, sobretudo em épocas de Internet, minimizando-se desta forma a importância do trabalho prático como instrumento de avaliação.

Assim, a partir do segundo semestre de 2004, quando a disciplina passou a abordar uma nova linguagem de programação, decidiu-se também mudar o seu enfoque passando a abordar os conteúdos desejados através da implementação de jogos (de entretenimento) na linguagem Java e revendo-se os métodos de ensino-aprendizagem e as práticas avaliativas, para dar um efetivo significado ao objeto de estudo e, de fato, favorecer o aluno a apreender o conhecimento desejado.

3 As Estratégias Utilizadas

As três principais estratégias de ensino-aprendizagem utilizadas atualmente na disciplina incluem:

a) aulas expositivas dialogadas;

b) estudo de textos;

c) soluções de problemas.

Combinadas com diferentes instrumentos de avaliação estas estratégias permitem ampliar a compreensão do professor sobre o sujeito aprendente que, em última instância, precisa ser avaliado por força dos regulamentos institucionais.

As aulas expositivas dialogadas são utilizadas para introduzir e permitir a discussão sobre os conceitos abordados ao longo da disciplina. Além disso, o professor constrói junto com os alunos soluções computacionais sobre os problemas abordados, visando clarificá-los na prática e permitir a discussão acerca do que foi feito. Assim, além de

estudar os conceitos e ver sua aplicação, os alunos são instados a discutir as implementações realizadas, articulando teoria e prática. Neste caso, não são aplicados instrumentos específicos de avaliação para verificar se os alunos efetivamente apreenderam os conteúdos abordados, pois não se pretende que o sujeito saiba reproduzir conceitos, mas sim o aplique de fato, o que será verificado através de trabalhos de implementação.

O estudo de texto também tem por objetivo apresentar conceitos abordados na disciplina e é combinado com outras estratégias, visando explorar o texto lido, de modo que se desafie o estudante a fazer de fato uma análise sobre o tema proposto. As estratégias combinadas com o estudo de texto e que são efetivamente utilizadas como instrumentos de avaliação são o debate e a resenha.

No debate os estudantes lêem um texto em sala de aula tratando dos aspectos teóricos e metodológicos aplicados ao desenvolvimento de jogos. Em seguida, cada aluno responde a um conjunto de 10 questões propostas pelo professor, para o qual ele tem três opções de resposta - concordo totalmente, concordo em parte e discordo totalmente – a qual deve ser devidamente justificada. Depois de cada aluno produzir seu documento individual, os estudantes são reunidos em grupos de 4 a 6 onde devem discutir suas respostas e produzir uma única resposta do grupo para as mesmas 10 questões. Este instrumento, além de permitir explorar questões conceituais apresentadas no texto, faz com que o aluno faça uma reflexão e emita sua opinião sobre os conceitos abordados e, mais do que isto, confronte sua opinião com os demais colegas da classe. Ao final da discussão do grupo, é promovido então um debate onde cada equipe e o professor apresentam suas considerações sobre os temas abordados. Assim, são três momentos diferentes de reflexão sobre o mesmo texto: individual, no pequeno grupo e no grande grupo.

Ressalta-se que o objetivo não é produzir um documento final com um gabarito, mas permitir a discussão sobre as questões apresentadas. Por ser uma atividade realizada em sala de aula, o professor pode avaliar o estudante sob diversos aspectos, tais como, o domínio conceitual, a qualidade e profundidade de sua argumentação, a participação e o comportamento do aluno no grupo de discussão, além da qualidade de sua produção textual, alcançando o objetivo de se transcender a avaliação apenas sob o aspecto do aprendizado técnico de programação.

Especificamente em uma disciplina de programação, existem diversos temas adequados para esta discussão, tais como, métodos de resolução de problemas e práticas de programação, que normalmente suscitam discussões acaloradas entre os estudantes.

Na resenha, cada estudante individualmente deve ler e fazer uma resenha crítica de no máximo 2 folhas sobre um artigo relacionado ao contexto da disciplina. A resenha pode ser baseada em um texto indicado pelo professor ou pode ser de um texto de livre escolha do próprio estudante. Neste segundo caso, o professor tem mais trabalho, pois tem que ler os textos escolhidos por cada estudante, mas, por outro lado, diversifica mais seu conteúdo bibliográfico, além de perceber os temas de interesse e de relevância para os estudantes.

Com este instrumento, o professor pode avaliar, por exemplo, a capacidade de leitura e interpretação de texto, a coerência na formulação de idéias e a própria

habilidade de produção de um texto, que são atividades normalmente desconsideradas em um processo avaliativo em disciplinas de programação, onde normalmente se avalia a capacidade do aluno em formular soluções algorítmicas ou em uma linguagem de programação para um determinado problema.

Outra estratégia de ensino-aprendizagem utilizada na disciplina é a concretização dos objetos de estudo através de soluções de problemas., sendo aplicada do seguinte modo: três jogos desenvolvidos em conjunto entre professor e estudantes, denominados de trabalhos de unidade e um jogo desenvolvido exclusivamente pelos estudantes denominado de trabalho final. Estes trabalhos têm o objetivo de aplicar os conhecimentos discutidos e construídos através das outras estratégias já apresentadas.

Os trabalhos de unidade são dimensionados para que se possa contemplar os elementos fundamentais do programa da disciplina através de soluções mais amplas e complexas, permitindo que se trabalhe com poucos exercícios, mas oportunizando aos estudantes trabalhar com sistemas com um número maior de linhas de código. Assim, antes de cada implementação, professor e estudantes elencam um conjunto de requisitos, os quais devem contemplar o tema em estudo e devem ser totalmente implementados no jogo proposto. Alguns destes requisitos são implementados em sala de aula com a participação e orientação do professor, uma vez que muitos deles envolvem conceitos ou técnicas não vistas anteriormente pelos estudantes, sendo que outros são implementados em trabalhos extra-classe. Nem todos os requisitos têm sua base conceitual discutida em sala de aula, de modo a fomentar a autonomia do estudante para a pesquisa e estudo de novos temas.

Por serem trabalhos feitos de forma gradativa, o professor pode ir fazendo o seu acompanhamento e fornecendo constantes feedbacks quanto às soluções implementadas, cumprindo um dos principais pilares do processo avaliativo que é permitir ao estudante rever e reforçar o seu aprendizado e ao professor a oportunidade de revisar e replanejar seus métodos.

Nos trabalhos de unidade, a avaliação final é feita pelo atendimento aos requisitos, como em qualquer disciplina de programação, mas com uma percepção mais acurada sobre o envolvimento, domínio e criticidade do estudante frente ao objeto de estudo.

O outro instrumento de avaliação utilizado é o trabalho final que consiste na implementação completa de um jogo de entretenimento na linguagem Java. Neste trabalho os estudantes devem se impor um desafio sendo este o instrumento central de avaliação na disciplina. A aplicação deste instrumento envolve quatro momentos diferentes:

a) contrato de trabalho: após o primeiro mês do início das aulas, os estudantes, organizados em equipes, apresentam a proposta de jogo que desejam implementar. Esta proposta consiste na descrição detalhada do jogo: regras, condições de vitória, técnicas de implementação, uso em rede, etc. O jogo não precisa ser inédito, ou seja, podem ser implementados jogos que já existem. Nesta apresentação discute-se com as equipes a complexidade do sistema a ser desenvolvido (nem tão simples – que envolva uma pequena base conceitual e de implementação, nem tão complexo – que não possa ser implementado em função do tempo disponível). Esta proposta deve ser entregue na forma

textual, seguindo um modelo proposto pelo professor de modo que se estabeleça um “contrato” , ou seja, o que for definido nesta proposta, deverá ser “entregue” pela equipe e será um dos critérios nos quais será baseada a avaliação do trabalho. Assim como na resenha, utilizam-se critérios tais como, organização, logicidade, clareza e concisão na apresentação das idéias e produção de um texto. Além do texto, a equipe também faz uma apresentação oral da proposta para os demais colegas. Com isto, permite-se aos demais estudantes da turma, opinar e dar sugestões sobre o trabalho dos colegas, enriquecendo a proposta e ampliando o conjunto de idéias para outros trabalhos. Outro objetivo da apresentação oral é a exposição do estudante a uma platéia, com caráter formal, onde pode-se observar, avaliar e orientar sobre questões como postura, oratória e articulação, possibilitando um momento para ajudá-lo a transpor uma barreira que é muito comum para os estudantes de computação e informática: a apresentação pública. Ressalta-se que este contrato é diferenciado de acordo com o que cada grupo estabelece como desafio para si próprio, ou seja, prevalece a capacidade e a vontade de cada grupo a desenvolver um trabalho dentro de seus próprios limites. Cabe ao professor apenas provocar o desafio.

b) apresentação prévia: 45 dias após o contrato ser negociado, os estudantes devem apresentar alguma implementação já concluída. Coloca-se como meta que nesta época, pelo menos metade do trabalho já esteja concluído. É o momento em que o professor dedica um maior tempo a cada equipe, observando se as soluções encaminhadas estão adequadas, tirando dúvidas e apontando dicas e soluções para a continuidade do trabalho, ou seja, é fundamentalmente um momento de crítica, retroalimentação e feedback. Também é importante se reavaliar o contrato, observando se a equipe terá condições de cumprí-lo efetivamente até o final do semestre letivo;

c) apresentação final: na penúltima aula do semestre, as equipes fazem uma apresentação do sistema implementado ao professor. Neste momento o professor não tira mais dúvidas. Ele observa se todos os requisitos constantes no contrato foram atendidos, avalia a jogabilidade do jogo, se o software possui erros, a arquitetura utilizada na implementação e a clareza e concisão do código fonte implementado. Também olhando o código fonte, o professor questiona os estudantes, sobretudo no uso de técnicas e soluções não realizadas ou discutidas em sala de aula. Esta é uma estratégia importante para verificar se os estudantes de fato são os autores do software apresentado. Outros aspecto fundamental neste processo é a oportunidade que o estudante tem de se auto-avaliar. Assim, cada um se manifesta sobre sua participação no trabalho e opina, perante a sua equipe, se a nota proposta pelo professor é justa ou não. Este tipo de avaliação é interessante, pois confronta a própria equipe, permitindo identificar os autores que mais se dedicaram ao trabalho e proporcionando, inclusive, a atribuição de notas diferentes para os integrantes de cada equipe;

d) apresentação pública: na última aula do semestre letivo, cada equipe faz a apresentação pública do seu trabalho para todos os colegas da turma, que o avaliam. O professor entrega um formulário para cada estudante com os

critérios que devem ser observados na avaliação. Os estudantes não atribuem notas aos trabalhos dos colegas, mas sim fazem um rankeamento na ordem de sua preferência. Este é um dos momentos mais interessantes do processo de avaliação da disciplina, pois novamente expõe os estudantes a uma apresentação pública, mas desta vez para defender um trabalho de sua autoria, devidamente concluído. Também coloca os demais estudantes na condição de avaliadores tornando-os efetivamente co-autores no processo avaliativo da disciplina. É muito interessante observar este processo, pois muitas vezes, ao fazer a avaliação do colega, o estudante não se prende apenas aos aspectos técnicos do trabalho apresentado, mas também acaba refletindo suas preferências pessoais, tanto pelo tipo de jogo, quanto pela empatia com a equipe que está apresentando. Assim, nas experiências vivenciadas até o momento com este tipo de avaliação, mesmo um trabalho tecnicamente muito superior aos outros, dificilmente obtém unanimidade no rankeamento pelos colegas.

4 Os Resultados Alcançados

A experiência adotada até o presente momento com o método aqui apresentado tem demonstrado ganhos de qualidade em diversos aspectos do processo ensino-aprendizagem, comparando-se com o método adotado anteriormente:

a) quanto à formação: quando são instados e motivados a construírem seu próprio aprendizado, em desafios complexos, mas factíveis, os estudantes têm demonstrado grande empenho, levando a uma formação técnica mais duradoura, à medida que é necessário construir algo e, já se sabe, que a melhor forma de aprender a fazer algo é? Fazendo! Além disso, conforme já destacado em momentos anteriores, consegue-se trazer elementos tais como, produção de texto, habilidade de argumentação e articulação, capacidade de avaliação e auto-avaliação, trabalho em equipe, entre outros, para uma disciplina que aparentemente é extremamente técnica com um objetivo muito claro que é o de avaliar a capacidade do estudante em formular programas de computador. Este elementos ampliam a formação de um sujeito que será inserido em um ambiente que não vai exigir-lhe apenas a técnica.

b) quanto à relação professor-estudantes: o simples fato de não se utilizar provas de conhecimento através de instrumentos específicos já diminui em muito a animosidade nesta relação, resultando em cobranças menos estressantes tanto para o professor quanto para os estudantes, permitindo, portanto, uma relação menos tensa e mais aberta, à medida que ois estudantes também participam mais do processo;

c) quanto à aprendizagem: a participação dos estudantes nas aulas foi ampliada sobretudo pela utilização de metodologias mais participativas e de instrumentos de avaliação de mais longo prazo, ou seja, que não são aplicados em um único momento. Isto tem tornado, de fato, os estudantes como sujeitos ativos do processo ensino-aprendizagem;

d) quanto ao comprometimento: ao avaliarem a si e aos colegas os estudantes são confrontados com suas próprias ações no percurso da disciplina,

permitindo que ele faça uma reflexão sobre seu mérito efetivo. Assim, o auto-julgamento demonstra ser uma “cobrança” muito mais efetiva para o estudante e aumenta o seu comprometimento no sentido de provar a si mesmo sua capacidade e empenho;

e) quanto ao conhecimento do professor sobre o sujeito aprendente: uma das maiores dificuldades do ensino é lidar com classes numerosas e com sujeitos em diferentes níveis de conhecimento e interesse. Ao possibilitar que o estudante defina a complexidade dos desafios que tem para resolver, o professor conhece melhor as diferenças técnicas e motivacionais entre seus diferentes alunos e pode aplicar instrumentos e estratégias diferenciadas para cada um deles.

Obviamente existem ainda desafios e dificuldades a serem superados, sobretudo quando o estudante e a instituição de ensino não conseguem lidar com determinadas mudanças naquilo que vem sendo feito, ou que é o tradicional e exigido pelos regulamentos. Algumas destas dificuldades são:

a) o estudante e a instituição perceberem que não é necessário a aula tradicional onde o professor explica e ele passivamente fica sentado em sua carteira esperando que alguém lhe dê as soluções para todos os seus problemas. Muitas vezes o professor é acusado de “não dar aula” ou de não ter ministrado conteúdos necessários para a confecção dos trabalhos, por exemplo;

b) a não existência de provas individuais como instrumento de avaliação em uma disciplina de programação, além de não ser muito bem visto pela instituição, gera mais acomodação naqueles estudantes que costumam “se aproveitar” dos colegas na confecção dos trabalhos, sendo que seus efeitos nefastos são percebidos apenas no momento da auto-avaliação, sendo esta uma questão que tem que ser lembrada constantemente pelo professor ao longo da disciplina. Mesmo assim, alguns alunos ainda chegam “acomodados” ao final do semestre letivo;

c) a própria avaliação não faz parte da cultura dos estudantes, pois normalmente ele esta ali para ser avaliado e não para avaliar. A auto-avaliação e a avaliação pelos pares ainda precisa de um processo de amadurecimento;

d) lidar, também na avaliação, com trabalhos em níveis de complexidade diferentes, uma vez que os estudantes com maior conhecimento anterior normalmente se impõem maiores desafios que os demais, criando diferentes níveis de trabalho. Assim, a avaliação deve estar centrada no alcance dos objetivos por parte do estudante, independente de seu nível de dificuldade. O professor pode e deve estar ciente disto em sua avaliação, mas os pares dificilmente estarão.

5 Considerações finais

Não há dúvida quanto à complexidade inerente aos processos de ensino-aprendizagem, sobretudo em uma sociedade cada vez mais sobrecarregada de tarefas, onde tudo é urgente e onde o tempo é cada vez mais escasso, tanto para estudantes quanto para professores. Desta forma, cabe aos professores o desafio de buscar métodos

mais produtivos e menos burocráticos no espaço de ensino-aprendizagem. A experiência apresentada neste artigo vai neste sentido.

Com o trabalho realizado até o momento verificamos que mesmo em disciplinas de programação de computadores, onde historicamente tem se privilegiado o conhecimento técnico e a avaliação individual, é possível e necessária a diversificação dos métodos de ensinar e aprender e, sobretudo, dos processos avaliativos, privilegiando a qualidade necessária de formação técnica para o estudante. Não se espera com isto ter ou apresentar uma fórmula de sucesso completa e acabada, mas sim, enriquecer o debate em torno da melhoria da qualidade destes processos nas disciplinas de programação, que sem dúvida, são fundamentais na formação dos sujeitos que atuarão em Computação e Informática, além de ampliar o olhar sobre a sala de aula de modo a construir um processo de avaliação que passe a ter significado e ser, de fato, formativo.

Cabe ressaltar, finalmente, a importância fundamental dos processos de formação docente neste contexto. A participação do autor deste artigo nos programas de formação docente da Pró-Reitoria de Ensino da Universidade Regional de Blumenau, desde 2003, exerceu papel importante nas mudanças efetivadas na disciplina, uma vez que a formação técnica predominante em professores da área de Computação e Informática normalmente faz com que eles repliquem modelos através dos quais foram educados. Assim, os processos de formação, além de permitirem o aprofundamento de discussões didático-pedagógicas e a troca de experiências com outros docentes, alertam o professor sobre a necessidade de estar atento e em constante reflexão sobre suas práticas educativas, de forma a considerar e analisar outras e novas possibilidades nos processos de ensino-aprendizagem, visando, sobretudo a motivação e o comprometimento, tanto seu, quanto do sujeito aprendente.

6 Referências

ANASTASIOU, Léa das Graças Camargos; Ensinar, aprender, apreender e processos de ensinagem. In: ANASTASIOU, Léa das Graças Camargos; ALVES, Leonir Pessate. (org.). Processos de ensinagem na universidade: pressupostos para as estratégias de trabalho em aula. 3. ed. Joinville : UNIVILLE, 2004. 144 p, il.

ANASTASOU, Léa das Graças Camargos; ALVES, Leonir Pessate. Processos de ensinagem na universidade: pressupostos para as estratégias de trabalho em aula. 3. ed. Joinville : UNIVILLE, 2004. 144 p, il.

FERNANDES, Jorge Henrique Cabral. Ensino introdutório de computação e programação: uma abordagem concreta, construtivista, linguística e histórica. In: X Workshop sobre Educação em Computação, 2002, Florianópolis - SC. XXII Congresso da Sociedade Brasileira de Computação - SBC2002. Porto Alegre - RS: SBC- Sociedade Brasileira de Computação, 2002. v. I, p. 81-81.

HADJI, Charles. A avaliação, regras do jogo: das intenções aos instrumentos. Porto : Porto Ed, 1994. 190p. (Colecção ciências da educação, 15). Tradução de: L´evaluation, regles du jeu.

___________. Avaliação desmistificada. Porto Alegre : ArTmed, 2001. 136p. (Biblioteca ARTMED. Fundamentos da educação). Tradução de: L´évaluation démystifiée.

PIMENTEL, Edson Pinheiro; FRANÇA, Vilma Fernandes; OMAR, Nizam. A caminho de um ambiente de avaliação e acompanhamento contínuo da aprendizagem em programação de computadores. In: III Workshop de Informática na Educação Computação do Estado de Minas Gerais, 2003, Poços de Caldas - MG. III Workshop de Informática na Educação Computação do Estado de Minas Gerais, 2003. v. 1.

ROMANOWSKI, Joana Paulin; WACHOWICZ, Lílian Anna. Avaliação formativa no ensino superior: que resistências manifestam os professores e os alunos? In: ANASTASIOU, Léa das Graças Camargos; ALVES, Leonir Pessate. (org.). Processos de ensinagem na universidade: pressupostos para as estratégias de trabalho em aula. 3. ed. Joinville : UNIVILLE, 2004. 144 p, il.

SANTOS, Rodrigo Pereira; COSTA, Heitor Augustus Xavier. Análise de metodologias e ambientes de ensino para algoritmos, estruturas de dados e programação aos iniciantes em computação e informática. In: Infocomp Journal of Computer Science, vol. 5, nº 1, março de 2006.

SILVA, Janssen Felipe da. Práticas avaliativas e aprendizagens significativas: em diferentes áreas do currículo.4. ed. São Paulo : Mediação, 2006. 107 p, il.

Uma Abordagem Inspirada em Insetos Sociais para aOtimização da Densidade de Redes de Sensores Sem Fio

Carlos Henrique Drumm e Paulo Roberto Ferreira Jr.Instituto de Ciências Exatas e Tecnológicas - Centro Universitário Feevale

RS 239, 2755 - Novo Hamburgo – RS – CEP 93352-000

{carlos.drumm, paulo.ferreira.jr}@gmail.com

Resumo. Este trabalho aborda a utilização dos processos cinergéticos,

verificados em colônias de insetos sociais, aplicados ao gerenciamento e

controle de Redes de Sensores Sem Fio utilizadas no sensoriamento de regiões

de difícil acesso. Mais especificamente, é verificada a aplicabilidade desta

abordagem frente ao controle da densidade mais adequada de uma rede de

sensores para cobrir eficazmente uma área desejada, com a menor utilização

possível de recursos, visando o prolongamento da vida útil desta rede.

IntroduçãoA crescente capacidade de integração de circuitos como micro-sensores, computação debaixa potência e comunicação sem fio em unidades compactas, permitiu a criação deuma arquitetura denominada de Rede de Sensores Sem Fio (RSSF). As RSSFpossibilitam que o sensoriamento de certas áreas de interesse, porém de difícil acesso,seja feita de maneira remota, sendo que estes sensores remetem as grandezas captadasatravés de elementos de comunicação sem fio (rádio freqüência).

Toda essa quantidade de instrumentos de medição e manipulação de dados einformações exige um gerenciamento preciso para que se obtenha um maior benefíciode sua utilização. Diferentemente das redes de comunicação normais, onde os nóspossuem alimentação de energia relativamente constante, tem uma boa capacidadecomputacional e não tem um objetivo específico, as Redes de Sensores Sem Fio sãobastante limitadas. Nas RSSFs os nós têm seu fornecimento de energia limitado à suabateria, seu poder computacional é reduzido por questões de economia de energia e seufoco de atuação é bem explicito, além de que sua característica de conectividade ad hoc

difere das redes tradicionais. A forma usual de gerência de rede mantém o controlecentralizado em nós especializados, constituindo assim uma estrutura fortementehierárquica e dependente destes nós de controle. Essa proposição de arquitetura degerenciamento traz consigo problemas como a centralização dos processos de controle egerência da rede. Considerando que a proposta do gerenciamento remoto de uma RSSFesta vinculado ao fato de esta esteja localizado em uma área de difícil acesso aos seremhumanos, presume-se que esta possa ter aspectos agressivos, o que aumentaria em muitoas chances de que algo ocorra com os nós de controle, desabilitando assim parte dosensoriamento da rede.

A pesquisa com colônias de insetos sociais (formigas, abelhas, cupins, etc)(THERAULAZ, BONABEAU, DENEUBOURG, 1998), tem mostrado que indivíduossimples, quando imbuídos com um objetivo e interagindo com seus pares, podemsolucionar problemas complexos. As colônias de insetos sociais fazem isso sem quehaja algum indivíduo comandando ou controlando, ou seja, todo o processo se dá deforma descentralizada. Ao contrário do que se possa imaginar, a rainha da colônia não

exerce nenhuma função de coordenação, cabendo a ela tão somente as funçõesreprodutivas. Esta forma adaptativa de dinamicamente alocar a execução de tarefascomplexas (construir e manter o ninho, reproduzir e criar a prole, alimentar todos osmembros da colônia, etc) entre os indivíduos da colônia, onde o comportamento desta éafetado tanto por condições internas (tamanho, quantidade de comida disponível, épocado ano, etc) como externas (predadores, condições climáticas, etc), tem inspirado novosmodelos que foram bem vindos e bem absorvidos em aplicações de SistemasMultiagentes (SMA).

As redes planas (não hierárquicas), sem elementos especializados no controle, tendem aser menos susceptíveis a perda de gerência principalmente porque todos os elementossão responsáveis pelo bom andamento da rede. Uma abordagem utilizando SMAs,baseada na plasticidade da divisão de trabalho sas colônias de insetos sociais, poderápropiciar uma revisão do processo de gerenciamento hierárquico, centralizado.

Este trabalho foi estruturado da seguinte forma: na seção 1 se discorre sobre o que sãoas RSSF , Nós Sensores e gerenciamento das RSSF; na seção 2 há uma descrição dométodo que este trabalho se propõe a realizar; na seção 3 aborda-se uma breve descriçãosobre Colônias de Insetos Sociais que, segundo o que é apresentado, demonstra umaforma inovadora para a auto-organização de Sistemas Multiagentes; no capítulo 4 há asdescrições dos experimentos construídos; na seção 5 são expostos os resultados obtidos;na seção 6 há uma comparação dos resultados expostos; e, finalmente, tem-se asconclusões sobre o que foi realizado neste trabalho.

1. Redes de Sensores Sem FioConforme Loureiro (LOUREIRO, et al. 2002), desde a década de 90, a microeletrônicaproporcionou enormes avanços para a computação, sendo que uma das áreas agraciadasfoi a dos microsensores. O tamanho reduzido, baixíssimo consumo de energia,processamento de dados local, capacidade de comunicação sem fio com outroselementos e redução no custo de produção, são alguns dos aspectos mais contundentesdesta evolução dos sensores eletrônicos. Estas capacidades permitiram a criação de umnovo tipo de rede, denominada de Rede de Sensores Sem Fio (RSSF). Uma RSSF éformada por um conjunto de dispositivos compactos e autônomos, chamados de nóssensores. Em alguns casos, uma RSSF também pode ser composta de dispositivosatuadores que permitem ao sistema controlar parâmetros do ambiente que está sendomonitorado.

Os nós sensores da rede são distribuídos por uma área e comunicam-se formando umarede ad-hoc, sendo que também percebem o ambiente com o objetivo de coletar dadossob determinados fenômenos. Os nós sensores podem processar os dados coletadoslocalmente e enviá-los a um ou mais Pontos de Acesso (PA). Sendo assim, as RSSF sãouma ferramenta de sensoriamento distribuído de fenômenos, processamento edisseminação de dados coletados e informações processadas para um ou maisobservadores (RUIZ, 2003). O potencial de observação e controle do mundo realpermite que as RSSFs se apresentem como uma solução para diversas aplicações demonitoração e controle, tais como monitoração ambiental, gerenciamento de infra-estrutura, biotecnologia, monitoração e controle industrial, segurança pública e deambientes em geral, áreas de desastres e risco para vidas humanas, transporte, medicina

e controle militar. Por essas capacidades, as RSSFs têm recebido bastante atenção dacomunidade de pesquisa, pois propõe novos desafios e oportunidades. A expectativa éque os Nós Sensores venham a ter um baixo custo comercial, possibilitando que venhama ser utilizados em larga escala, inclusive em aplicações de cunho doméstico. As RSSFssão fortemente dependentes da sua aplicação. Assim, o projeto e o desenvolvimento dearquiteturas de nós sensores está diretamente ligada à aplicação que se desejadesenvolver. Segundo Ruiz (RUIZ, s.d), deve-se procurar a simplicidade no trato dasRSSFs, buscando a aderência aos fatos que as diferenciam das redes usuais, que são odinamismo e a escassez de recursos dos nós.

As RSSFs têm diversas características especificas que as tornam significativamentediferentes das redes tradicionais. Isto significa que algoritmos distribuídos tradicionais,como protocolos de comunicação e eleição de líder, assim como paradigmas degerenciamento, devem ser revistos antes de serem usados diretamente nesse tipo derede. Além de tudo isso, as RSSFs também herdaram os problemas típicos das redessem fio, incluindo as altas porcentagens de erros de comunicação e dificuldade nocontrole do consumo de energia.

2. Gerenciamento da Densidade de Nós SensoresComo dito no início deste trabalho, redes hierárquicas demonstram uma condição deque, se nós intermediários apresentam algum problema, todo setor sobre o qual o nótem precedência é inviabilizado até que o problema seja sanado. Se considerarmos quea proposta de gerenciamento da densidade de nós sensores esta relacionada ao fato deque estes não puderam ser posicionados no local de sensoriamento porque o mesmo éinóspito e de difícil acesso, então, podemos considerar que são grandes aspossibilidades de que estes nós sensores e lideres também sofram com as agruras daregião, aumentando de maneira considerável a probabilidade de que estes sejamretirados de operação por alguma agressão sofrida. Dentro deste contexto, acentralização do gerenciamento da rede pode ser um empecilho ao seu bomfuncionamento, pois isso aumentaria o fluxo de comunicação entre o ponto de acesso eo nós sensores, o que provocaria uma rápida degradação do abastecimento de energiados mesmos, pois este é o componente que mais restringe o poder de atuação dosNSSF.

Apresentado este panorama, percebe-se que uma possível solução para este problemaseria descentralizar o gerenciamento da RSSF numa topologia plana (sem hierarquia)distribuída, o que nos remete a área de SMA (Sistemas MultiAgentes), a qual secaracteriza, justamente, pela descentralização do processamento, distribuindo as tarefasentre os Agentes integrantes do sistema. Entretanto, a pura e simples distribuição doprocessamento entre agentes não resolveria de maneira eficaz o problema de gerência ecoordenação da rede em si (agentes precisam coordenar-se através de alguma política),por isso que se pretende estudar uma nova e promissora abordagem na coordenação doSMA para compor a RSSF. Esta nova abordagem, provinda da área da biologia teórica,se refere aos estudos feitos junto a colônias de insetos sociais, os quais propiciaram acriação de novos algoritmos de coordenação e divisão do trabalho, ampliando o poderde auto-organização dos nós sensores interpretados como agentes dentro da rede. Ouseja, a proposta deste trabalho se sedimenta no estudo e simulação de um sistemamultiagentes para a auto-organização de uma RSSF, que pela própria natureza de sua

construção é uma rede distribuída, baseada nos conceitos de auto-organização detarefas encontrados nas colônias de insetos sociais (formigas, abelhas, cupins, etc).

3. Insetos Sociais

Os insetos sociais possuem uma das estratégias de sobrevivência mais bem sucedidas danatureza, por isso, há uma imensa quantidade e variedade destes. Segundo Wilson(WILSON, 2000), existem mais espécies de formigas em 1 quilômetro quadrado de umafloresta brasileira do que todas as espécies de primatas existentes no mundo, e umasimples colônia de formigas possuem mais habitantes do que todos os elefantes e leõesda África somados.

Baseado nos estudos e observações realizadas pelos entomologistas a respeito dascolônias de insetos sociais, foram concebidos modelos teóricos e matemáticos sobre suaorganização (GORDON, 2000).

Um dos modelos apresentados mais recentemente, já por pesquisadores da computação,pretende ser um modelo genérico que cobre todos os aspectos que envolvem a divisãodo trabalho nas colônias (BONABEAU, THERAULAZ, DORIGO, 1999)(THERAULAZ, BONABEAU, DENEUBOURG, 1998). Em (THERAULAZ,BONABEAU, DENEUBOURG, 1998) são apresentados outros modelos nesta linha esão discutidas as diferenças entre tais modelos e o modelo do autor. Neste modelo cadaindivíduo da colônia tem um limiar de resposta a estímulos para realizar determinadatarefa. Um Indivíduo passa a executar uma tarefa quando o estímulo para executar estatarefa ultrapassa seu limiar associado.

Seja s a intensidade de um estímulo associado a uma atividade em particular, onde spode ser o número de encontros com outros indivíduos, uma concentração química ouqualquer outro fator quantitativo que possa ser sentido por um indivíduo. O limiar deresposta θθθθ, expresso em unidades de intensidade de estímulo, é uma variável interna quedetermina a tendência de um indivíduo responder ao estímulo s a realizar a tarefaassociada. Segue uma possível função para a probabilidade de um indivíduo atender aresposta a um estímulo. Outras funções podem levar ao mesmo padrão de resultadosesperado pelo modelo.

onde:T j = Tendência da Tarefa j no Limiar θ em função do Estimulo s para o Individuo i.s j = Estímulo Associado a Tarefa j.θθθθ�i j = Limiar de Resposta do Indivíduo do Tipo i para a Execução da Tarefa j.

Baseado nesta idéia, o autor deste modelo apresenta funções para determinar o estímuloassociado a cada tarefa sj em função do número total de tarefas e de suas características.São discutidas também funções para a determinação do θ θ θ θ i j que fazem com que seuvalor varie conforme a tarefa é executada pelo indivíduo considerando tempo deexecução, qualidade, a especialização do individuo na execução da tarefa, etc. O modeloem questão será utilizado futuramente para compor uma abordagem de coordenaçãopara Agentes atuando na gerência de Redes de Sensores sem Fio.

4. Experimentos

O processo de simulação foi dividido em 4 partes: geração dos dados dos Sensores SemFio simulados; simulação da Rede de Sensores Sem Fio Plana (sem gerencia) – RSSF-P;simulação de uma Rede de Sensores Sem Fio Gerenciada de forma Hierárquica – RSSF-GH; simulação de uma Rede de Sensores Sem Fio Gerenciada com base na heurística deseleção inspirada na relação das Colônias de Insetos Sociais (GerenciamentoDistribuído) – RSSF-GD.

Para que as simulações fossem cumpridas de maneira uniforme e inequívoca, e para quese demonstre e evidencie as diferenças dos processos, é necessário que estes sejamfeitos com base nos mesmos conjuntos de dados, ou seja, os mesmos sensores, com omesmo alcance, posicionados nas mesmas coordenadas, cobrindo a mesma área e comas mesmas quantidades de energia. Neste contexto, estabeleceu-se algumas premissaspara a criação dos conjuntos de dados, que são elas:• a unidade de área adotada para a simulação é o m2 (metro quadrado);• a unidade de tempo dos períodos, para as simulações, será o Dia (24 horas);• foram gerados 12 grupos de dados, para garantir-se a validade estatística das

simulações, dos quais se fará uma média com os resultados obtidos na simulação decada conjunto;

• a área de sensoriamento mede 600 metros por 600 metros (600m × 600m), o queproporciona uma área total de 360 mil metros quadrados (360.000m2);

• alcance dos sensores é 15 metros, o que fornece uma cobertura de 706,86m2

(metros quadrados), por sensor;• cada conjunto de dados tem 600 sensores, distribuídos aleatoriamente pela área

acima descrita, cujos quais permitiriam sensoriar uma área de aproximadamente424.116m2, se corretamente posicionados respeitando área de abrangência de cadasensor.

• os sensores têm energia para, na condição mínima, 90 dias de operação, sendo queum dia de operação consome uma unidade de energia, ou seja, cada sensor tem nomínimo 90 unidades de energia;

• a energia máxima dos sensores é inferior a 15% do seu mínimo, então, a energiamáxima de um sensor não ultrapassa 103 unidades de energia;

A partir destas características básicas, construiu-se o primeiro simulador, ou, a primeirafase da simulação, que é o gerador randômico (aleatório) de Sensores Sem Fio. Nestafase, foram gerados 12 conjuntos de dados com 600 sensores, distribuídosaleatoriamente pela área de sensoriamento (600×600) pré-definida. Cabe ressaltar queem cada conjunto de dados gerado, os sensores possuem posicionamentos diferentes ecapacidades energéticas diferentes, dentro do escopo definido.

4.1 Rede Plana

A segunda fase consiste na simulação da RSSF-P, onde não há qualquer tipo de gerênciasobre os sensores, tão pouco da Rede. Nesta simulação, cada período de tempo pré-determinado (1 dia) desconta uma unidade de energia do sensor. Sendo assim, onúmero de períodos de vida da RSSF é igual a do tempo de vida do sensor com o maiornível de energia (mínimo de 90 dias e máximo 103 dias). Esta simulação fornece a basede análise, para que se confirme, ou não, se o método proposto de Gerenciamento

Distribuído da RSSF, baseado no comportamento de Colônias de Insetos Sociais temvalidade para o contexto.

Ao final desta fase da simulação, tem-se 12 conjuntos de 600 sensores, ordenadossegundo suas coordenadas (X e Y) no plano. Este ordenamento nos permite executaruma busca seqüencial dos sensores próximos entre si. Utilizando a formula de Pitágoras,pode-se definir se há a interseção de varredura entre dois sensores.

22 )'"()'"( yyxxd −+−=onde:d: distância entre a posição dos dois sensores emanálise;x”: coordenada do eixo X do sensor atual na seqüênciade análise;x’: coordenada do eixo X do sensor anterior naseqüência de análise;y”: coordenada do eixo Y do sensor atual na seqüênciade análise;y’: coordenada do eixo Y do sensor anterior naseqüência de análise.

Uma vez definida a distância entre os sensores, e esta for menor que a soma dosalcances dos sensores, então está configurada a interseção da cobertura dos sensores.Então, como ilustrado na Figura 1, a área de interseção é calculada pela diferença daárea do triangulo abc e do setor descrito pelo ângulo �. Esta diferença é a área da corda

bc, que multiplicada por 2 fornece a área da interseção que é retirada da área decobertura do sensor que esta sendo analisado. E assim, sucessivamente até o fim dossensores. Após o cálculo da área útil de cada sensor, é feito o somatório da área total decobertura, respeitando a condição do sensor estar ativo ou não. Em uma Rede Plana, ouseja, sem gerenciamento, a condição do sensor estar ativo ou não, se dá exclusivamentepelo fato do mesmo ter energia ou não para funcionar.

Figura 1 – Representação do Cálculo da Área de Interseção de Cobertura dos Sensores

Seqüência de Cálculo:�= Arco cos((distancia / 2) / raio)�= �* 2Área do Setor bc = ((�* (alcance)2) / 360) * �Área do Triangulo abc = (((sen(�) * alcance) * 2) * (distancia / 2)) * 2

Área da Interseção = (Área do Setor – Área do Triangulo) * 2

4.2 Rede Hierárquica Gerenciada

A terceira fase, consiste na simulação de uma RSSF Gerenciada, de forma Hierárquica,com base em parâmetros rígidos e arbitrados. Nesta simulação, estabeleceu-se que, paraum sensor permanecer em funcionamento, este deveria ter, como área útil, pelo menos20% de sua área total de varredura. O procedimento para o cálculo da área útil decobertura de cada sensor e da área de cobertura total segue os mesmos critérios dasimulação da rede sem gerencia - RSSF-P.

Esta classe de rede caracterizada por conter, não somente os nós de sensoriamento, mastambém, nós com características de controle e gerenciamento. Estes, atuam comointermediários entre os nós de sensoriamento e o sorvedouro (captação dasinformações), inserindo mais um estágio na transmissão dos dados. Esta situação, seobservado o aspecto de que as RSSFs necessitam de um gerenciamento remoto maisapurado quando não se tem acesso físico (regiões de difícil acesso - penhascos, ilhas,pântanos, etc) à ela, implica em um grave problema. Cada nó de controle, assume aresponsabilidade de gerenciamento de um setor da rede. Os nós de sensoriamento sevinculam a um nó de controle pela proximidade com ele, dentro da sua capacidade decobertura. Neste contexto, já que o ambiente se mostra agressivo, há uma grandeprobabilidade de que algo possa acontecer com este nó de controle, pois se comparadocom os nós de sensoriamento, estes são em menor número. O fato de que algo impeça onó de controle de efetuar sua tarefa, tem impacto direto no resultado efetivo da redehierárquica, que perde muito de sua efetividade. Para demonstrar este fato inserimos, nasimulação de RSSF-GH uma queda do nó de controle número 5 no período 78.

4.3 Rede Gerenciada pela Heurística dos Insetos Sociais

A quarta fase, ou seja, o principal objetivo deste trabalho, consiste na simulação docomportamento de uma RSSF Gerenciada, tomando por base a heurística docomportamento de Colônias de Insetos Sociais. O processo de gerenciamento da Redede Sensores Sem Fio (RSSF), visa a prolongar a vida útil da mesma, pois, se dois oumais sensores “caírem” muito próximos, os dados captados e transmitidos por eles sãopresumivelmente idênticos, tirando a validade da informação, pois esta só ocasionarámais tempo de processamento e gasto de energia desnecessária.

Então, o processo de gerenciamento da Rede, pretende identificar, baseado nascoordenadas de cada Sensor, em função do raio de varredura do mesmo, calculando aárea de interseção entre os sensores, procurando verificar sua proximidade ou não. Ovalor percentual da área de abrangência resultante (área de varredura descontada a áreade interseção), será a informação de estimulo para que se possa obter a tendência paraque o Sensor permaneça ligado ou não, se este ainda possuir energia que sustente oprocesso a que foi destinado. O limiar de resposta do individuo (θθθθ), para o inicio dasimulação, é de 0,5. Após, foram utilizados os valores de 0,2 e 0,8, para que se possaaferir e confirmar os resultados obtidos. Nesta simulação, os procedimentos para ocálculo da área útil de cobertura dos sensores e a área de cobertura total permanecem osmesmos da simulação da rede sem gerencia. Entretanto, o fato de um sensor estar ativo acada período de tempo, está ligado probabilisticamente, segundo a aplicação da formula

descrita anteriormente, à área de cobertura útil deste sensor, além é claro, de ter energiapara sua operação.

5. Resultados

Os resultados apurados revelaram aspectos bem distintos em cada simulação, sendo quetodas se mostraram dentro do esperado. Os dados levantados e aqui expostosforneceram subsídios valiosos para as considerações finais deste trabalho.

5.1 Rede Plana

A RSSF-P obteve um comportamento estável e dentro do esperado, onde, cada sensoruma vez identificado só alterava seu comportamento e seu estado quando este eradesligado por falta de energia. Nota-se, na Figura 2, que a RSSF-P, por não existirinterferência alguma, opera com cem por cento (100%), de sua capacidade de cobertura,e com todos os sensores ativos, até o período 90 (noventa), que é a capacidadeenergética mínima de cada sensor. Após, observa-se um declínio contundente de suacapacidade de cobertura até o período 103 (capacidade energética máxima), isso devido,ao desligamento dos sensores por falta de energia.

Cobertura da Rede Plana

0,00%20,00%40,00%60,00%80,00%

100,00%120,00%

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99

Periodos (Dias)

Áre

a(%

)

Figura 2 - Área de Cobertura ao longo do Tempo de Vida da RSSF-P.

5.2 Rede Hierárquica Gerenciada Sem Queda dos Nós de Controle

Na simulação de uma rede hierarquia gerenciada, pode-se ver que após a aplicação docritério de desligamento, e a conseqüente desativação dos sensores que nele seencaixavam, esta se comporta de maneira parecida com uma rede plana. A redeutilizando o mesmo conjunto de sensores até o consumo total de sua energia. Suaprincipal mudança reside no fato de que, quando os sensores ativos são desligados porfalta de energia, estes modificam a aplicação do critério arbitrado sobre os sensoresdesligados. Então, se os sensores que haviam sido desativados, agora não mais seencaixam no critério de desativação, por influencia de um sensor agora desligado,podem ser reativados. Considerando que os sensores, antes desligados, mas agora emfuncionamento, possuem seu reservatório de energia como no inicio (1º Período), então,o tempo de vida da rede será prolongado para além do tempo de vida do sensor de maiorreserva de energia. Na Figura 3, pela semelhança da curva do gráfico a partir do período90 (mínimo de energia dos sensores), evidencia o mesmo comportamento da RedePlana. Como também verifica-se a extensão da sobre vida da rede, obtida pela economiade energia na aplicação dos critérios de desativação dos sensores. A aderência dos

sensores aos critérios arbitrados fez com que estes, desativados no inicio do processo,sejam ativados mais tarde.

Cobertura Hierarquica Sem Queda de Setor

0,00%20,00%40,00%60,00%80,00%

100,00%120,00%

1 21 41 61 81 101

121

141

161

181

201

221

241

261

281

Periodos (Dias)

Are

a(%

)

Figura 3 - Área de Cobertura ao longo do Tempo de Vida da RSSF-GH,Sem Queda de Setor de Cobertura.

5.3 Rede Hierárquica Gerenciada com Queda de Um Nó de Controle

Como já explicado no capítulo anterior, as RSSF Hierárquicas apresentam um sérioproblema, pois como estas são utilizadas em ambientes inóspitos, existe uma grandeprobabilidade de que um nó de controle venha a sofrer avarias, e assim deixar defuncionar. Este fato implica na perda de comunicação dos sensores que deste nódependiam, criando um vácuo de cobertura da área de sensoriamento. Na simulação estetipo de situação é demonstrado a partir do período 78, ocorrendo com o nó de controledo setor nº 5. Na Figura 4, a queda vertical da área de sensoriamento, mostra bem, oquão sério é este problema de queda de um nó de controle, e como isto pode refletir naefetividade da RSSF.

Cobertura Hierarquica com Queda de Setor

0,00%20,00%40,00%60,00%80,00%

100,00%120,00%

1 20 39 58 77 96 115

134

153

172

191

210

229

248

267

286

Periodos (Dias)

Are

a(%

)

Figura 4 - Área de Cobertura ao longo do Tempo de Vida da RSSF-GH,Com Queda de Setor de Cobertura.

Vale ressaltar que, apesar da queda de um setor, neste caso especifico, representar umnono (1/9) da cobertura, a representatividade disso na área total de cobertura pode sermaior ou menor, dependendo da concentração (densidade) de sensores associados a estesetor.

5.4 Rede Gerenciada pela Heurística dos Insetos Sociais

Sendo a heurística da divisão do trabalho nas colônias de Insetos Sociais, um processoprobabilístico, esta característica é emprestada no gerenciamento da RSSF. Em cada

período de tempo, o conjunto de sensores ativos é diferente do período anterior. Estetipo de comportamento forneceu à RSSF, além de prolongar efetivamente o tempo devida dela, um aspecto de rotatividade. Apesar de não utilizar 100% da sua capacidade decobertura, esta rotatividade pode, virtualmente garantir, em momentos diversos, aobtenção de informação sobre todo o perímetro coberto. Vale salientar que no período 1de todas as simulações, já estão estabelecidos os procedimentos de conduta de toda asimulação em voga. Na Figura 5 (a, b e c), pode-se perceber com clareza, umadegradação mais suave da área de cobertura da RSSF, e uma extensão acentuada da vidaútil da RSSF.

Cobertura Média para �de 0.2

0,00%20,00%40,00%60,00%80,00%

100,00%120,00%

1 23 45 67 89 111

133

155

177

199

221

243

265

287

309

Periodos (Dias)

Are

a(%

)

(a) Limiar de Resposta do Individuo de 0.2.

Cobertura Média para �de 0.5

0,00%

20,00%

40,00%

60,00%

80,00%

100,00%

1 26 51 76 101

126

151

176

201

226

251

276

301

326

Periodos (Dias)

Are

a(%

)

(b) Limiar de Resposta do Individuo de 0.5.

Cobertura Média para �de 0.8

0,00%

20,00%

40,00%

60,00%

80,00%

1 26 51 76 101

126

151

176

201

226

251

276

301

326

351

Periodos (Dias)

Are

a(%

)

(c) Limiar de Resposta do Individuo de 0.8.Figura 5 - Área de Cobertura ao longo do Tempo de Vida da RSSF-GD

6 DiscussãoNa Figura 6, os gráficos sobrepostos demonstram claramente os resultados obtidos nasestratégias aplicadas para gerenciamento da RSSF. Pode-se verificar que o traçado daRede Plana acaba por desaparecer na sobreposição dos gráficos traçados, pois seutraçado é quase idêntico ao da rede hierárquica, apesar de básico e ser o menor resultadoobtido.

Comparativo de Coberturas

0,00%20,00%40,00%60,00%80,00%

100,00%120,00%

1 19 37 55 73 91 109

127

145

163

181

199

217

235

253

271

289

307

325

Período (Dias)

Áre

a(%

)

Rede Plana Rede Hierárquica Sem QuedaRede Hierárquica Com Queda Rede Distribuída � 0.2Rede Distribuída � 0.5

Figura 6 – Comparativo sobreposto dos resultados obtidos

Concomitantemente a Tabela 1 demonstra, numericamente, os resultados sintéticos dassimulações executadas onde tem-se uma macro visão de todos os processos de formarápida e direcionada . Analisando esta tabela, nota-se que, levando em conta que jamaishaverá uma cobertura de 100% da área demarcada, pela natureza de imprevisibilidadedo processo de distribuição aleatória dos sensores na superfície, a seleção de um dosmétodos simulados, principalmente o da Rede Distribuída, fica a critério do que seespera retirar como beneficio da rede, se mais cobertura relativa ou mais tempo de vida.Sendo que a heurística baseada em insetos sociais pode fornecer uma melhoria amambos os critérios, bastando para isso, ajustar o Limiar Interno dos Indivíduos (θθθθ).

Tabela 1 – Síntese dos Resultados Obtidos das Simulações

Rede Plana Rede Hierárquica Rede Distribuída

Sem QuedaCom Queda θθθθ 0,2 θθθθ 0,5 θθθθ 0,8

Média de Cobertura entrePeríodo 1 a 90 100% 100% 93,84% 95,94% 82,33% 73,35%

Tempo Excedente (Dias) 12 203 203 224 252 270

Média de Cobertura do TempoExcedente 67,05% 13,69% 7,76% 23,26% 29,51% 32,43%

7. Conclusões

Neste trabalho, foram inicialmente discutidos aspectos das RSSFs e sua gerência, temaque atualmente tem um grande impacto sobre como o controle ambiental, seja qual for oambiente desde a Floresta Amazônica até a sala de estar ou escritório das pessoas, vêmsendo realizado. Foi mostrado também que ainda são incipientes os métodos de

administração e gerência das RSSFs. Além disso, foi abordada a possibilidade deutilização de Sistemas Multiagentes (SMA) coordenados com base na teoria de divisãode trabalho e coordenação de colônias de Insetos Sociais.

Considera-se que no processo proposto, os sensores são distribuídos aleatoriamente(arremessados). Isto implica necessariamente na não cobertura de toda a área proposta,pela simples impossibilidade de garantir que todos os sensores estejam posicionados deforma eqüidistante, sem que existam sobreposições de cobertura. Sendo assim, pode-seafirmar que nestas condições, não existe a possibilidade de 100% de cobertura da áreadesejada. Conseqüentemente, se não há como cobrir integralmente a área desejada, poisesta é de difícil acesso físico, resta a maximização do tempo de vida da RSSF. Nestecontexto, a aplicação da heurística de seleção de trabalho de colônias de insetos sociais,no intuito de melhorar o desempenho e maximização da vida útil de uma RSSF, semostrou efetiva. Além disso, o processo probabilístico para ativar e desativar ossensores faz com que exista uma mobilidade da área coberta, propiciando uma varredurade toda a área possível de ser sensoriada, em momentos diferentes.

No que tange a outros tipos de redes, especialmente as hierárquicas, esta rede distribuídaobtém vantagens significativas, pois como podemos perceber, além de conseguir daruma vida útil mais significativa para a RSSF, ela não esta sujeita a problemas de quedasdos nós de gerência, que acabam por retirar grande parte do poder de cobertura daRSSF.

ReferênciasBONABEAU, E.; THRAULAZ, G.; DORIGO, M. Swarm Intelligence: from natural to

artificial systems. [S.l.]: Oxford Univ Press, 1999.

GORDON, D. M. Ants at Work: how an insect society is organized. [S.l.]: Free Press,Simon and Schuster, 2000.

LOUREIRO,Antonio Alfredo Ferreira; Nogueira, José Marcos Silva; Ruiz, LinnyerBeatrys; Mini, Raquel Aparecida de Freitas. Redes de Sensores sem Fio. Artigo.Jornada de Atualização em Informática. 2002

RUIZ, Linnyer Beatrys. Sobre o Impacto do Gerenciamento no Desempenho das Redesde Sensores Sem Fio. Artigo. WCSF 2003. Departamento de Ciência daComputação. Universidade Federal de Minas Gerais. Belo Horizonte - MG. 2003

THERAULAZ, G.; BONABEAU, E.; DENEUBOURG, J. Response ThresholdReinforcement and Division of Labour in Insect Societies. 1998.

WILSON, E. O. Sociobiology: The New Synthesis. [S.l.]: Harvard Univ Press, 2000.

Evolução do Caminhar de Robôs Móveis SimuladosUtilizando Algoritmos Genéticos

Milton Roberto Heinen1 e Fernando Santos Osório1

1Universidade do Vale do Rio dos Sinos (UNISINOS)Computação Aplicada - PIPCA

CEP 93022-000 - São Leopoldo - RS - Brasil

miheinen@gmail.com, fosorio@unisinos.br

Resumo. Este artigo descreve o sistema LegGen, responsável pela geração docaminhar para robôs dotados de pernas de forma automática em um ambienterealístico simulado. Nesta abordagem o caminhar é definido através da utili-zação de três abordagens diferentes, que são o uso de um autômato definindoos ângulos de cada junta do robô, o uso de Locus Based Gait e de uma meiaelipse para a definição da movimentação dos membros durante o caminhar. Osparâmetros de cada uma das abordagens são otimizados através do uso de Al-goritmos Genéticos. Para a validação dos modelos, foram realizados diversosexperimentos utilizando robôs de quatro e seis patas, simulados utilizando oambiente ODE. O artigo faz uma comparação das várias abordagens, e indicaquais que são mais apropriadas para a modelagem do caminhar e quais mode-los de robôs são mais eficientes.

1. IntroduçãoOs robôs móveis autônomos tem atraído a atenção de um grande número de pesquisado-res, devido ao desafio que este novo domínio de pesquisas propõe: dotar sistemas de umacapacidade de raciocínio inteligente e de interação com o meio em que estão inseridos[Medeiros 1998]. Atualmente os robôs móveis atuam em diferentes áreas, como desar-mamento de bombas, exploração de ambientes hostis, e a condução de veículos de formasemi-autônoma [Batavia et al. 1996]. A maioria dos robôs móveis desenvolvidos até omomento se deslocam através do uso de rodas, o que facilita bastante o controle, masimpede que eles sejam capazes de se deslocarem em ambientes irregulares, pois estes am-bientes possuem diversos desníveis e degraus [Knight and Nehmzow 2002]. Assim, paraque um robô móvel possa se deslocar livremente em ambientes irregulares, ele precisariaser dotado do mesmo mecanismo de locomoção utilizado pelos seres humanos e a maioriados seres vivos, ou seja, ele precisaria de pernas [Bekey 2005, Pfeifer and Scheier 1999].

Mas o desenvolvimento de robôs com pernas que consigam se deslocar livrementeem ambientes irregulares é uma tarefa bastante árdua, que exige a configuração de diver-sos parâmetros relativos ao caminhar. A configuração manual destes parâmetros exigemuitas horas de um especialista humano, e os resultados obtidos são sub-ótimos e de-pendentes da arquitetura específica do robô [Chernova and Veloso 2004]. Desta forma,seria interessante realizar a configuração do caminhar de forma automática, através dautilização de alguma técnica de Aprendizado de Máquina [Mitchell 1997]. Uma das téc-nicas de Aprendizado de Máquina mais adequadas para solucionar este tipo de problemasão os Algoritmos Genéticos (AG) [Goldberg 1989], pois segundo a Teoria da Evolução

Natural das Espécies [Darwin 1859], os mecanismos de locomoção utilizados pelos seresvivos são um resultado da Evolução Natural, o que torna o uso de Algoritmos Genéti-cos uma solução natural para este tipo de problema [Pfeifer and Scheier 1999]. Do pontode vista computacional, os Algoritmos Genéticos também são bastante adequados paraa configuração do caminhar em robôs com pernas, pois conseguem realizar uma buscamulti-critério em um espaço multi-dimensional e não necessitam de informações locaispara a correção do erro nem do cálculo do gradiente [Mitchell 1996].

O objetivo deste artigo é descrever o sistema LegGen [Heinen and Osório 2006a,Heinen and Osório 2006b, Heinen and Osório 2006c, Heinen and Osório 2006d], que éum simulador capaz de realizar a configuração do caminhar de robôs com pernas de formaautomática através do uso de Algoritmos Genéticos. Este artigo está estruturado da se-guinte forma: A Seção 3. descreve os Algoritmos Genéticos e a biblioteca de softwareGAlib, que foi utilizada nas simulações; A Seção 4. descreve o uso de simulação baseadaem física; A Seção 5. descreve as possíveis formas de se configurar o caminhar de robôscom pernas; A Seção 6. descreve o sistema desenvolvido, chamado de LegGen, e os robôsutilizados nas simulações; A Seção 7. descreve os experimentos realizados e os resultadosobtidos; e a Seção 8. traz as conclusões finais e as perspectivas futuras.

2. Trabalhos relacionadosO controle de locomoção em robôs com pernas é um problema de busca em um es-paço de estados multidimensional que vem desafiando os pesquisadores a várias décadas[Bekey 2005]. Este controle requer a especificação e a coordenação dos movimentos detodas as pernas do robô, enquanto são considerados fatores como a estabilidade e a fricçãoem relação a superfície de contato (solo) [Kohl and Stone 2004]. Esta é uma área de pes-quisas que tem uma clara ligação com o controle de locomoção realizado pelos animais,e muitos das pesquisas realizadas até o momento se inspiram no caminhar realizado poranimais como os mamíferos e os insetos [Reeve and Hallam 2005].

O controle do caminhar em robôs com pernas é uma área de pesquisas que vemsendo explorada a bastante tempo. Como trabalhos pioneiros nesta área podemos destacaros primeiros robôs com pernas realmente independentes, como o Falso Pônei (PhonyPony) desenvolvido por Frank e McGhee [McGhee 1976], onde cada junta foi controladapor uma simples máquina de estados finita, até o muito bem sucedido controle algorítmicode bípedes e quadrúpedes desenvolvido por Raibert [Raibert 1986].

Na área de controle inteligente de robôs dotados de pernas, os primeiros trabalhosdatam do final dos anos 80 e início dos anos 90, como por exemplo o trabalho de Lewis[Lewis et al. 1992], que utilizou Algoritmos Genéticos para a evolução dos controladoresde um robô de seis pernas (hexapod). Neste trabalho, o controlador foi evoluído em umrobô cujo caminhar era inspirado no caminhar dos insetos. Através de vários estágiosde evolução, seu comportamento foi sendo modificado até atingir um caminhar razoavel-mente satisfatório. Bongard [Bongard and Pfeifer 2002] evoluiu os parâmetros de umaRede Neural Artificial dinâmica utilizada para controlar diversos tipos de robôs simula-dos. Busch [Busch et al. 2002] utilizou Programação Genética para evoluir os parâmetrosde controle de diversos tipos de robôs, simulados utilizando o pacote de software Dyna-Mechs1. Jacob [Jacob et al. 2005] utilizou Aprendizado por Reforço para o controle de

1DynaMechs – http://dynamechs.sourceforge.net/

um robô de quatro pernas (tetrapod) simulado através da biblioteca de software ODE.Reeve [Reeve and Hallam 2005] utilizou Algoritmos Genéticos para a evolução dos pa-râmetros de diversos modelos de Redes Neurais utilizadas para o controle de diversostetrapods simulados utilizando o DynaMechs.

Na maioria das abordagens descritas acima, a função de fitness utilizada foi adistância percorrida pelo robô durante um certo período de tempo. Embora esta funçãode fitness seja largamente utilizada, ela pode fazer com que a evolução privilegie formasde caminhar pouco estáveis em detrimento de soluções um pouco mais lentas porém muitomais estáveis [Golubovic and Hu 2003]. Em nossos estudos, além da distância percorridapelo robô, foram utilizadas como critério de fitness informações sensoriais, provenientesde um giroscópio simulado a fim de se garantir que os caminhares obtidos fossem tantorápidos quanto estáveis [Heinen and Osório 2006a, Heinen and Osório 2006b].

3. Algoritmos Genéticos

Os Algoritmos Genéticos (AG) são métodos de busca estocástica baseados na Teoria daEvolução Natural das Espécies [Darwin 1859], criados por John Holland nos anos 60[Holland 1975]. Os Algoritmos Genéticos trabalham com uma população de soluçõesiniciais, chamadas cromossomos, que através de diversas operações vão sendo evoluídasaté que se chegue a uma solução que melhor atenda a algum critério específico de avali-ação. Para que isto ocorra, a cada geração os cromossomos são avaliados segundo umafunção que mede o seu nível de aptidão, chamada de função de fitness. Os cromossomosque tiverem o melhor fitness são selecionados para darem origem a próxima geração, atra-vés de operações como cruzamentos e mutações. Desta forma, a tendência é que a cadageração o conjunto de soluções vá sendo melhorado, até que a solução que atenda aosobjetivos desejados [Mitchell 1996].

Para a implementação dos Algoritmos Genéticos no sistema LegGen, foi selecio-nada a biblioteca de software GAlib2, desenvolvida por Matthew Wall do MIT. A GAlibfoi selecionada por ser uma das mais completas, eficientes conhecidas bibliotecas de soft-ware para a simulação de Algoritmos Genéticos, e também por ser uma solução gratuitae de código aberto, baseada na linguagem de programação C++.

No sistema desenvolvido, foi utilizado 0 algoritmo genético com populações so-brepostas (overlapping populations) proposto por [De Jong 1975], e foram adotados ge-nomas do tipo real (números de ponto flutuante). Para se reduzir o espaço de busca, foramutilizados alelos para limitar o conjunto de valores gerados para cada atributo. O tipo decruzamento escolhido foi o cruzamento em um ponto , e o esquema de seleção adotadofoi o stochastic remainder sampling selector, que segundo [Goldberg 1989] possui umdesempenho superior ao esquema da roleta (roulette wheel selector). O método de escala(scaling) do fitness utilizado foi o sigma truncation, que permite que o fitness assumavalores negativos.

4. Simulação baseada em física

Para que uma simulação de robôs móveis seja realista, diversos elementos do mundo realdevem estar presentes no modelo de simulação, para que os corpos se comportem de

2GAlib – http://www.lancet.mit.edu/ga/

forma similar à realidade. Em especial, é necessário que um robô sofra quedas se nãofor bem controlado ou se não estiver bem posicionado, e que colida contra os objetos doambiente de forma realista. Para que isto ocorra, é necessário que as leis da física sejammodeladas no ambiente de simulação (gravidade, inércia, fricção e colisão). Atualmenteexistem várias bibliotecas de software disponíveis para a implementação de simulaçõesbaseadas em física. Após o estudo de diversas possibilidades, optou-se pela utilização deuma biblioteca de código aberto e gratuita chamada Open Dynamics Engine (ODE)3.

A biblioteca ODE permite a realização de simulações da dinâmica de corpos rígi-dos articulados com bastante realismo do ponto de vista físico. Com ela, é possível criardiversos corpos rígidos, e estes podem ser conectados através de juntas de vários tipos.Para a movimentação das juntas, é possível que sejam aplicadas forças diretamente aoscorpos, ou podem ser utilizados motores angulares, que estão disponíveis no ambienteODE. Um motor angular é um elemento que pode ser conectado a dois corpos articula-dos, e que possui uma velocidade e uma força máxima. Com o uso de juntas e motoresangulares, é possível que sejam reproduzidas as diversas articulações presentes em umrobô real, em seres humanos e nos animais.

5. Geração do caminharEm um robô dotado de pernas, o caminhar pode ser gerado de diversas formas. Umadas alternativas possíveis consiste na utilização uma máquina de estados, onde cada es-tado é determina o ângulo desejado para cada uma das juntas do robô. Nesta abordagem,o controlador continuamente realiza a leitura dos ângulos de cada uma das juntas, paraverificar se elas já atingiram os valores desejados. Em robôs reais, os ângulos das jun-tas podem ser obtidos através da leitura de sensores (encoders) instalados nas mesmas[Dudek and Jenkin 2000]. Desta forma, o controle do caminhar é realizado da seguinteforma: inicialmente o controlador verifica se as juntas já atingiram os ângulos desejados.As juntas que não tiverem atingido são movimentadas (os motores são ativados), e quandotodas elas tiverem atingido os seus respectivos ângulos, o autômato passa para o estadoseguinte. Se alguma das juntas não tiver atingido o ângulo desejado após um limite detempo, o estado é avançado independente desta.

Para que haja sincronia nos movimentos, é importante que todas as juntas atinjamos ângulos desejados praticamente ao mesmo tempo, o que é possível com a aplicação deuma velocidade angular específica para cada uma das juntas, calculada através da fórmula:

Vij = V ri(αij − αij−1) (1)

onde Vij é a velocidade aplicada ao motor da junta i no estado j, αij é o ângulo da juntai no estado j, αij−1 é o ângulo da junta i no estado anterior (j − 1), e V ri é a velocidadereferencial do estado i, utilizada para controlar a velocidade do conjunto. A velocidadereferencial V r é um dos parâmetros do caminhar otimizados pelo Algoritmo Genético. Osoutros parâmetros são os ângulos desejados de cada uma das juntas para cada estado. Paralimitar o espaço de busca, o Algoritmo Genético gera apenas valores dentro do intervalomáximo e mínimo de cada junta.

Outra forma de se controlar o caminhar, conhecida como locus based gait, consistena utilização de um autômato no qual é determinado, para cada estado, a posição em

3ODE – http://www.ode.org

que os endpoints (“pés”, “patas”, extremidades inferiores das pernas) do robô devemse encontrar em relação aos eixos x, y e z [Wyeth et al. 2003]. Esta abordagem é útilprincipalmente em robôs bípedes, onde o número de graus de liberdade por extremidade(número de juntas) supera o número de dimensões. Já em robôs com menos de quatrograus de liberdade por perna, esta abordagem não é tão eficiente, pois não haverá umaredução do espaço de estados (número de parâmetros).

Pelo fato de os robôs utilizados neste trabalho terem graus de liberdade apenas noplano sagittal (eixo z), as posições dos endpoints precisam ser calculas apenas nos eixosx e y, o que torna esta abordagem interessante em robôs com mais de dois graus de liber-dade por extremidade, que é o caso do Hexa3J (Figura 2(a)) e do Tetra3J (Figura 2(b)).Para se calcular as posições desejadas de cada junta, é necessário calcular a cinemáticainversa, mas este cálculo não precisa ser em tempo real – os ângulos podem ser calcu-lados antecipadamente e gravados em uma tabela similar a da abordagem anterior. Nosistema LegGen, utilizou-se a implementação descrita em [Press et al. 1992] do métodode Powell [Brent 1973] (Powell’s Direction Set) para o cálculo da cinemática inversa.

Outra forma de se controlar o movimento das pernas do robô é modelar o deslo-camento dos endpoints através de alguma função cíclica, como por exemplo uma meia-elipse. A Figura 1 ilustra esta abordagem.

Figura 1. Trajetória definida por uma meia-elipse [Golubovic and Hu 2003]

Com o uso da meia-elipse, os únicos parâmetros que precisam ser otimizados sãoa posição do centro da elipse de cada perna em relação aos eixos x, y e z, a altura e alargura de cada elipse, o tempo de duração total do ciclo e tempo de duração da parteem que a perna está em contato com o solo. A principal vantagem desta abordagem éque teoricamente ela reduz o espaço de busca, tornando o aprendizado mais eficiente. Aprincipais desvantagens são: (i) a meia elipse restringe muito os movimentos possíveis,dificultando o caminhar em superfícies irregulares; (ii) a cinemática inversa precisa sercalculada de forma rápida e eficiente.

6. Sistema propostoO Sistema LegGen é um sistema desenvolvido para realizar a configuração do caminharem robôs simulados dotados de pernas de forma automática. Ele foi implementado uti-lizando a linguagem de programação C++ e as bibliotecas de software ODE e GAlib,descritas anteriormente. O sistema LegGen recebe como entrada dois arquivos, um des-crevendo o formato e as dimensões do robô e o outro descrevendo os parâmetros de simu-lação. A Tabela 1 mostra os parâmetros utilizados pelo sistema LegGen, com os valoresutilizados nas simulações.

Tabela 1. Parâmetros do Sistema LegGenParâmetro Descrição ValorCrossover Taxa de cruzamentos 0,80Mutation Taxa de mutação 0,08Population size Tamanho da população 50Number of generations Número de gerações 100Number of states Número de estados do autômato 4Time of walk Tempo de caminhada 60Velocity min Velocidade relativa máxima 0,0Velocity max Velocidade relativa mínima 1,0

Os parâmetros crossover, mutation, population size e number of generations sãousados diretamente pela biblioteca GAlib para definir o funcionamento do Algoritmo Ge-nético. O parâmetro number of states define o número de estados do autômato finito, oparâmetro time of walk define o tempo em que cada indivíduo irá caminhar durante a ava-liação do fitness (este tempo é relativo ao relógio da simulação, e não ao tempo do mundoreal), e os parâmetros velocity min e velocity max definem a faixa na qual as velocidadesrelativas (V r) serão geradas pelo Algoritmo Genético.

O funcionamento do sistema LegGen ocorre da seguinte forma: inicialmente oarquivo que descreve o robô é lido, e o robô é criado no ambiente virtual de acordo com asespecificações presentes neste arquivo. Em seguida, os parâmetros do sistema LegGen sãolidos (Tabela 1), e o Algoritmo Genético é inicializado e executado até que seja atingidoo número de gerações desejado. A avaliação dos indivíduos ocorre da seguinte forma:

• O robô é colocado na orientação e na posição inicial do ambiente virtual;• O genoma é lido, e a partir dele é montada a tabela de controle do robô;• A simulação física é realizada por um tempo determinado (60 segundos);• Durante a simulação física, são coletadas as informações sensoriais;• O fitness é calculado e retornado para a GAlib.

Para o cálculo da função de fitness, as seguintes informações sensoriais precisamser calculadas: distância percorrida pelo robô (D); e taxa de estabilidade (G); A distânciaD é calculada pela fórmula:

D = Px1 − Px0 (2)

onde D é a distância percorrida pelo robô em relação ao eixo x (movimento para frenteem linha reta), Px0 é a posição inicial e Px1 é a posição final em relação ao eixo x.

A taxa de instabilidade é calculada usando a variação das posições do robô noseixos x, y e z. Esta variações são coletadas durante a simulação física, simulando umsensor do tipo giroscópio/acelerômetro, que é um sensor que está presente em algunsmodelos de robôs [Dudek and Jenkin 2000]. A taxa de instabilidade G (Giroscópio) écalculada através da equação [Golubovic and Hu 2003]:

G =

√

∑ni=1

(xi − x)2 +∑n

i=1(yi − y)2 +

∑ni=1

(zi − z)2

n(3)

onde n é o número de amostras coletadas, xi, yi e zi são os dados coletados pelo giroscópiosimulado no instante i, e xx, xy e xz são as médias das leituras realizadas pelo giroscópio,

calculadas através das equações:

x =

∑ni=1

xi

n, y =

∑

n

i=1yi

n, z =

∑ni=1

zi

n(4)

O fitness F é calculado através da fórmula:

F = D/(1 + G) (5)

Pela análise da função de fitness, se observa que o indivíduo mais bem qualificado éaquele que possui a melhor relação entre velocidade e estabilidade, de forma que as me-lhores soluções são aquelas mantém o compromisso entre estes dois critérios de avaliação[Golubovic and Hu 2003].

Durante a simulação, se um robô afastar as quatro patas do chão ao mesmo tempopor mais de um segundo, a simulação deste indivíduo será imediatamente interrompida,pois é muito provável que este robô tenha sofrido alguma queda, e portanto não há neces-sidade de continuar a simulação deste indivíduo até o final do tempo estabelecido.

6.1. Robôs Modelados

Conforme consta em sua documentação, a biblioteca ODE possui uma complexidadecomputacional de ordem O(n2), onde n é o número de corpos presentes no mundo físicosimulado. Deste modo, para manter a velocidade da simulação em um nível aceitável,é preciso modelar os corpos da forma mais simples possível. Por este motivo, todos osrobôs simulados foram modelados com objetos simples, como retângulos e cilindros, eeles possuem apenas as articulações necessárias para a tarefa de caminhar. Assim, ele-mentos como a cabeça e a cauda não estão presentes em nenhum dos modelos de robôssimulados. Para manter o projeto dos robôs simples, as juntas utilizadas nos membrosse movimentam apenas em torno do eixo z em relação ao robô (o mesmo movimento donosso joelho), pois as simulações realizadas até o momento foram todas com o robô acaminhando em linha reta. No futuro, o sistema será estendido para aceitar modelos derobôs com juntas mais complexas.

(a) Hexa3J (b) Tetra3J (c) Hexa2J (d) Tetra2J

Figura 2. Modelos de robôs utilizados nas simulações

Inicialmente foram modelados e testados diversos tipos de robôs, até que se che-gou aos quatro modelos principais, mostrados na Figura 2. O modelo da Figura 2(a),chamado de Hexa3J, possui seis pernas e três partes por perna. As partes que entram emcontato com o solo (pés ou patas) são mais largas que o restante das pernas, de modo a

dar um maior apoio ao robô. O modelo da Figura 2(b), chamado de Tetra3J, é similar aoda Figura 2(a), mas possui apenas quatro pernas. Nestes dois robôs, o ângulo das juntasde cada uma das patas (αp) é calculado através da fórmula:

αp = −

n∑

i=1

αi (6)

onde αi é o ângulo da junta i e n é o número de juntas em cada perna. Utilizando a Fór-mula 6, as patas do robô ficam sempre paralelas ao solo. O modelo de robô da Figura 2(c),chamado de Hexa2J, é similar ao da Figura 2(a), mas possui apenas duas articulações porperna, e todos os ângulos das juntas são calculados pelo Algoritmo Genético, sem utilizara Fórmula 6. O modelo da Figura 2(d), chamado de Tetra2J, possui quatro pernas e duasarticulações por perna. A Tabela 2 mostra as dimensões dos robôs em centímetros.

Tabela 2. Dimensões dos robôs simuladosCorpo Coxa e canela Pata

Robô x y z x y z x y zHexaL3J 0,80 0,15 0,30 0,05 0.15 0,05 0,08 0,05 0,09TetraL3J 0,45 0,15 0,25 0,05 0,15 0,05 0,08 0,05 0,09HexaL2J 0,80 0,15 0,30 0,05 0,15 0,05 - - -TetraL2J 0,45 0,15 0,25 0,05 0,15 0,05 - - -

Similar ao que acontece na maioria dos mamíferos de quatro pernas, as patas dosrobôs das Figuras 2(a) e 2(b) são um pouco mais largas que o restante das pernas, de formaa dar ao robô uma maior base de sustentação, permitindo assim uma maior estabilidade.A Tabela 3 mostra os limites máximos e mínimos das juntas dos robôs da Figura 2. Osrobôs modelados possuem todas as pernas idênticas entre si.

Tabela 3. Limites mínimos e máximos das juntasPernas frontais Pernas traseiras

Robô Quadril Joelho Tornozelo Quadril Joelho TornozeloHexaL3J [-60◦;15◦] [0◦;120◦] [-90◦;30◦] [-60◦;15◦] [0◦;120◦] [-90◦;30◦]TetraL3J [-60◦;15◦] [0◦;120◦] [-90◦;30◦] [-60◦;15◦] [0◦;120◦] [-90◦;30◦]HexaL2J [-60◦;15◦] [0◦;120◦] – [-60◦;15◦] [0◦;120◦] –TetraL2J [-60◦;15◦] [0◦;120◦] – [-60◦;15◦] [0◦;120◦] –

7. ResultadosPara a descoberta do modelo de robô mais indicado para ser construído, diversos experi-mentos foram realizados. Os primeiros experimentos visavam descobrir se era vantajosoconstruir robôs com quatro ou seis pernas, e se os robôs precisavam de dois ou três seg-mentos por perna. O ideal seria construir um robô que utilizasse o menor número possívelde articulações, a fim de se reduzir os custos associados. Além destes testes, foram feitostestes para verificar qual forma de modelar o caminhar que era mais indicada: utilizaruma tabela de ângulos (Ângulos), locus based gait (Locus) ou a meia elipse (Elipse).No caso dos experimentos com a meia elipse, além dos experimentos realizados com o

passo chamado de “Trote” (duas pernas são levantadas ao mesmo tempo), também foramfeitos testes com o passo chamado de “Caminhar” (apenas uma perna por vez é afastadado chão). A Tabela 4 mostra os resultados obtidos nos experimentos realizados.

Tabela 4. Resultados obtidos nos experimentosF D G

E Robô Método Passo x S x S x S

01 Hexa3J Ângulos Trote 43,86 9,38 71,35 18,02 0,59 0,1002 Hexa2J Ângulos Trote 52,26 7,23 76,53 7,58 0,45 0,1103 TetraL3J Ângulos Trote 30,82 3,58 50,82 7,88 0,61 0,2104 TetraL2J Ângulos Trote 8,44 9,25 18,30 20,26 0,86 0,4405 Hexa3J Locus Trote 30,20 3,82 64,29 4,99 1,06 0,3806 Hexa2J Locus Trote 35,08 3,59 66,45 8,47 0,62 0,1007 TetraL3J Locus Trote 13,00 9,31 20,79 14,54 0,42 0,2508 TetraL2J Locus Trote 5,10 1,35 8,60 3,03 0,58 0,2509 Hexa3J Elipse Trote 22,68 5,81 27,22 8,62 0,16 0,0610 Hexa2J Elipse Trote 3,30 0,57 5,03 0,67 0,34 0,1611 TetraL3J Elipse Caminhar 14,50 2,86 17,89 3,80 0,22 0,0312 TetraL2J Elipse Caminhar 2,72 0,10 3,71 0,18 0,19 0,07

Cada um dos experimentos foi repetido cinco vezes com sementes aleatórias dife-rentes, e ao final foram calculadas a média e o desvio padrão das informações sensoriaisobtidas. A primeira coluna é o número do teste, a quinta e a sexta coluna mostram, res-pectivamente, a média e o desvio padrão do fitness, a sétima e a oitava coluna mostrama média e o desvio padrão da distância percorrida pelo robô, e as duas últimas colunasmostram a média e o desvio padrão do índice de instabilidade do robô. Observando osresultados da Tabela 4 pode-se tirar as seguintes conclusões:

• Os robôs de seis pernas são mais velozes que os de quatro pernas;• Os robô de Hexa2J é um pouco mais veloz que o Hexa3J;• Os robô TetraL2J não conseguiu se deslocar de maneira satisfatória;• O experimentos realizados com a tabela de ângulos tiveram melhores resultados;• O passo trote é mais veloz que o caminhar, e nem por isso é mais instável.

A primeira conclusão é justificada pelo fato de os robôs de seis pernas possuíremestabilidade estática no trote, o que faz com que eles possam empregar maiores veloci-dades sem o risco de tombar com facilidade. A segunda e a terceira conclusão mostramque um robô de seis pernas não necessita de patas, por ser estável estaticamente, mas ode quatro pernas sim. A quarta conclusão, que demonstra uma maior eficiência dos expe-rimentos realizados utilizando a tabela de ângulos pode se dever em parte às dificuldadesassociadas ao cálculo da cinemática inversa em tempo real, o que faz com que o endpointnem sempre siga a trajetória planejada. A última conclusão mostra que o uso do trote norobô de quatro pernas com patas é tão estável quanto o caminhar, e no robô de quatropernas sem patas nem este tipo de andar melhorou os resultados obtidos.

A Figura 3(a) mostra a relação entre o fitness e o número de gerações em um expe-rimento. Os pontos vazados (em vermelho) mostram o fitness do melhor indivíduo a cada

geração, e os pontos preenchidos (em azul) mostram o fitness da média da população. OGráfico da Figura 3(b) mostra a relação entre a estabilidade e a velocidade dos indivíduosde cinco experimentos distintos utilizando o Tetra3J.

(a) Gerações x Fitness (b) Velocidade x Estabilidade

Figura 3. Gráficos de evolução das soluções

Pode-se notar que existe uma certa relação direta entre a velocidade e a insta-bilidade, pois boa parte dos experimentos segue quase que uma diagonal secundária nográfico. O ideal seria ter as soluções o mais próximo possível do eixo x e o mais afastadopossível do eixo y, de forma a maximizar a velocidade e minimizar a instabilidade. AFigura 4(a) mostra um andar realizado por um robô Tetra3J4 e a Figura 4(b) mostra ocaminhar de um robô Hexa2J.

(a) Tetra3J (b) Hexa2J

Figura 4. Exemplos de caminhar utilizando os robôs Tetra3J e Hexa2J

8. Conclusões e perspectivasPelos experimentos realizados, pode-se constatar que os robôs de seis pernas são bastanterápidos e estáveis, podendo inclusive se abrir mão de endpoints com uma maior super-fície de apoio, a exemplo do que acontece na maioria dos insetos. Em robôs de quatropatas, endpoints com um maior ponto de apoio são necessários para um caminhar estável.Ambos os modelos de robôs são viáveis de serem construídos fisicamente.

4Vários vídeos de demonstração estão disponíveis em http://www.inf.unisinos.br/~osorio/leggen

Em relação ao tipo de passo, o “trote” provou ser um passo bastante eficiente,inclusive no robô de quatro patas. Em relação a forma de se modelar o caminhar, apesardas diferenças não serem significativas, o uso da tabela de ângulos provou ser tão eficienteou mais do que as outras duas abordagens, sendo escolhido para ser utilizado nas próximassimulações. O uso da elipse não tornou o aprendizado mais fácil, nem com a incorporaçãode pré-conhecimentos (da forma do caminhar ser similar a uma meia elipse) no modelo,e além disso torna o caminhar menos generalizado.

As perspectivas futuras incluem tornar o caminhar possível em superfícies irre-gulares e subida de escadas, bem como a construção de um robô físico conforme as es-pecificações de um dos melhores modelos aprendidos, para assim validar o sistema emcondições reais.

Referências

Batavia, P., Pomerleau, D., and Thorpe, C. (1996). Applying advanced learning algo-rithms to alvinn. Technical Report CMU-RI-TR-96-31, Carnegie Mellon University(CMU), Pittsburgh, PA, USA.

Bekey, G. A. (2005). Autonomous Robots: From Biological Inspiration to Implementationand Control. The MIT Press, Cambridge, MA, USA.

Bongard, J. C. and Pfeifer, R. (2002). A method for isolating morphological effects onevolved behaviour. In Proceedings of the 7th International Conference on Simulationof Adaptive Behaviour (SAB), pages 305–311, Edinburgh, UK. The MIT Press.

Brent, R. P. (1973). Algorithms for Minimization without Derivatives. Prentice-Hall,Englewood Cliffs, NJ, USA.

Busch, J., Ziegler, J., Aue, C., Ross, A., Sawitzki, D., and Banzhaf, W. (2002). Automaticgeneration of control programs for walking robots using genetic programming. In Proc.European Conf. Genetic Programming (EuroGP), pages 258–267, Berlin, Germany.

Chernova, S. and Veloso, M. (2004). An evolutionary approach to gait learning for four-legged robots. In Proceedings of the IEEE/RSJ International Conference on IntelligentRobots and Systems (IROS), Sendai, Japan. IEEE, IEEE Press.

Darwin, C. (1859). Origin of Species. John Murray, London, UK.

De Jong, K. A. (1975). An Analysis of the Bahavior of a Class of Genetic AdaptativeSystems. Doctoral thesis, University of Michigan, Ann Arbor, MI, USA.

Dudek, G. and Jenkin, M. (2000). Computational Principles of Mobile Robotics. Cam-bridge University Press, Cambridge, UK.

Goldberg, D. E. (1989). Genetic Algorithms in Search, Optimization and Machine Lear-ning. Addison-Wesley, Reading, MA, USA.

Golubovic, D. and Hu, H. (2003). Ga-based gait generation of sony quadruped robots. InProceedings of the 3th IASTED International Conference on Artificial Intelligence andApplications (AIA), Benalmadena, Spain.

Heinen, M. R. and Osório, F. S. (2006a). Applying genetic algorithms to control gait ofphysically based simulated robots. In Proceedings of the IEEE Congress on Evolutio-

nary Computation (CEC), Vancouver, Canada. IEEE World Congress on Computatio-nal Intelligence (WCCI).

Heinen, M. R. and Osório, F. S. (2006b). Gait control generation for physically basedsimulated robots using genetic algorithms. In Proceedings of the International JointConference 2006, 10th Ibero-American Conference on AI (IBERAMIA), 18th BrazilianSymposium on AI (SBIA), LNCS, Ribeirão Preto - SP, Brazil. Springer-Verlag.

Heinen, M. R. and Osório, F. S. (2006c). Neural networks applied to gait control of phy-sically based simulated robots. In Proceedings of the International Joint Conference2006, 9th Brazilian Neural Networks Symposium (SBRN), Ribeirão Preto, SP, Brazil.IEEE Press.

Heinen, M. R. and Osório, F. S. (2006d). Uso de algoritmos genéticos para a configu-ração automática do caminhar em robôs móveis. In Anais do Encontro de RobóticaInteligente (EnRI), Campo grande, MS, Brazil. UFMS, UCDB.

Holland, J. H. (1975). Adaptation in Natural and Artificial Systems. University of Michi-gan Press, Ann Arbor, MI, USA.

Jacob, D., Polani, D., and Nehaniv, C. L. (2005). Legs than can walk: Embodiment-basedmodular reinforcement learning applied. In Proc. IEEE Int. Symposium on Computati-onal Intelligence in Robotics and Automation (CIRA), pages 365–372, Espoo, Finland.

Knight, R. and Nehmzow, U. (2002). Walking robots - a survey and a research proposal.Technical Report CSM-375, University of Essex, Essex, UK.

Kohl, N. and Stone, P. (2004). Policy gradient reinforcement learning for fast quadrupedallocomotion. In Proceedings of the IEEE International Conference on Robotics andAutomation (ICRA), pages 2619–2624, New Orleans, LA, USA. IEEE, IEEE Press.

Lewis, M. A., Fagg, A. H., and Solidum, A. (1992). Genetic programming approach to theconstruction of a neural network for control of a walking robot. In Proc. of IEEE Inter-national Conf. on Robotics and Automation (ICRA), pages 2618–2623, Nice, France.

McGhee, R. (1976). Robot locomotion. Neural Control of Locomotion, pages 237–264.

Medeiros, A. (1998). Introdução à robótica. In Anais do XVII Encontro Nacional deAutomática, volume 1, pages 56–65, Natal, RN, Brazil. 50a Reunião Anual da SBPC.

Mitchell, M. (1996). An Introduction to Genetic Algorithms. MIT Press, Cambridge, MA.

Mitchell, T. (1997). Machine Learning. McGrall-Hill, New York, USA.

Pfeifer, R. and Scheier, C. (1999). Understanding Intelligence. The MIT Press, Cam-bridge, MA, USA.

Press, W., Teukolsky, S., Vetterling, W., and Flannery, B. (1992). Numerical Recipes inC: The Art of Scientific Computing. Cambridge Univ. Press, Cambridge, MA, USA.

Raibert, M. H. (1986). Legged Robots That Balance. MIT Press, Cambridge, MA, USA.

Reeve, R. and Hallam, J. (2005). An analysis of neural models for walking control. IEEETransactions on Neural Networks, 16(3):733–742.

Wyeth, G., Kee, D., and Yik, T. F. (2003). Evolving a locus based gait for a humanoidrobot. In Proceedings of the IEEE/RSJ International Conference on Intelligent Robotsand Systems (IROS), volume 2, pages 1638–1643, Las Vegas, NV, USA. IEEE Press.

AS-MCOE: Tutor inteligente modelado em AgentSpeak(L)

Rodrigo R. V. Goulart, Alexandre O. Zamberlam

1FEEVALE, PROPTEC, Grupo de Pesquisa em TINovo Hamburgo, RS, Brasil

{rodrigo, alexz }@feevale.br

Resumo.Este artigo relata a investigacao e partes da implementacaorealizadas no projeto AS-MCOE, que tem como objetivo avaliar a utilizacaode tutores inteligentes no ensino de ecologia, dando continuidade ao trabalhodesenvolvido no ambiente MCOE. O tutor e os agentes dessas propostas estaosendo implementados com a tecnica BDI (Belief, Desire and Intention) por meioda linguagem AgentSpeak(L) e do interpretador Jason. Esses agentes estaoinseridos em um jogo, construıdo atraves da Golden T Game Engine (GTGE),kit de desenvolvimento em Java para jogos.

1. Introducao

O projeto AS-MCOE (AgentSpeak(L) MCOE) se caracteriza pela investigacao cientıficados avancos pedagogicos e tecnologicos decorrentes da utilizacao de tecnicas deInteligencia Artificial no ensino de criancas, jovens e adultos. O objeto dessa pesquisa saoos jogos educacionais, os quais destacam-se pela popularidade e insercao na comunidadeinfanto-juvenil, e que ate o presente momento nao agregam a tutoria artificial comoum diferencial comercial e/ou pedagogico. A finalidade desse projetoe desenvolverum estudo sobre aplicacao de uma tecnica de IA, intitulada BDI (Believes, Desires andIntentionsou Crencas, Desejos e Intencoes), em um jogo educacional e avaliar o processode desenvolvimento e aplicacao do mesmo com alunos do ensino fundamental.

O tema do jogo, proposto inicialmente por Lucia Giraffa em [Giraffa 1999],e deecologia e baseia-se na interacao entre um personagem, comandado pelo aluno, e a cadeiaalimentar de um lago, composta por personagens artificiais inteligentes. O objetivoemanter o equilıbrio da cadeia por meio de “poderes” ou ferramentas que o personagempossui, e as dificuldades relacionadas ao jogo e/ou ao conteudo sao avaliadas por um TutorArtificial que envia mensagens com dicas e explicacoes ao aluno.

Neste trabalho, a modelagem utilizada por Giraffa, proposta por Mora em[Mora 2000], sera substituıda pela de [Rao 1996], cuja linguagem, a AgentSpeak(L),foi implementada por [Hubner et al. 2004]. Esses novos recursos viabilizaram areimplementacao dos experimentos realizados por Giraffa e a sua posterior avaliacao.Al em disso, novas recursos foram utilizadas para o desenvolvimento do jogo: a linguagemJava e oenginepara jogos GTGE.

Finalmente, para uma melhor compreensao do apresentado, este artigo estadividido em 7 secoes. A proxima detalha o ambiente MCOE, sua estrutura, seuscomponentes e sua evolucao. A secao 3 aborda agentes cognitivos baseados em estadosmentais (BDI), conceitos e o contexto na IA. Na secao 4, e detalhada a linguagemde especificacao AgentSpeak(L), bem como o interpretador Jason, ferramentas deoperacionalizacao da maquina de inferencia do comportamento dos agentes no jogo.

A secao 5 apresenta oengineGTGE, responsavel pelo o ambiente do jogo, ou seja, ajogabilidade. Na secao 6,e detalhada a arquitetura do jogo com oenginee o interpretadorJason. Finalmente na secao 7, as consideracoes finais.

2. MCOEEste projeto faz parte de um conjunto de pesquisas sobre softwares educacionaisinteligentes realizadas nosultimos dez anos. O eixo principal de todas elase oMulti Cooperative Environment- MCOE, proposto em [Giraffa 1999] que descreve umambiente composto por um jogo de ecologia e um tutor inteligente.

A pesquisa teve inıcio em 1996 com o jogo Eco-logico, que foi um trabalho deconclusao de curso de graduacao, construıdo com ToolBook [ASYMETRIX 1994] e quetrabalhava somente com a apresentacao de uma cadeia alimentar, exibindo conceitos ealgumas relacoes.

Em 1998, iniciou-se o projeto MCOE, no qual o jogo apresenta ao jogador (aluno)um ambiente em que aparecem inumeros problemas. Ao longo de sua interacao como programa, o aluno deve soluciona-los, por meio de seu conhecimento previo e pelouso de ferramentas que combinadas auxiliarao na construcao de um estrategia de acao.O jogo, cujainterfacee apresentada na Figura 1e composto por um lago onde existeum ecossistema formado por peixes, plantas,agua e microrganismos com um sistemade reproducao em equilıbrio, ate a intervencao de poluentes que provocam alteracoes noseu estado normal. Esses poluentes aparecem de forma aleatoria ao longo do jogo e saocombatidos atraves de ferramentas do personagem, escolhidas livremente por cada aluno,que pode interagir com um colega para construir uma estrategia comum para resolver oproblema da poluicao do lago.

O jogo foi concebido para alunos que estejam frequentando a 3a e 4a seriesdo primeiro grau (ensino fundamental). Ele pode, entretanto, ser utilizado tambempor criancas de outras faixas etarias atraves da configuracoes de seus parametros e dautilizacao de uma metodologia que permita a contextualizacao do ambiente nas atividadesrealizadas pelos alunos. O jogo foi construıdo em Visual C++ e com o pacote de APIsDirectX.

Ja o tutor, que foi construıdo obedecendo o paradigma de agentes cognitivosbaseados em estados mentais BDI, especificado e implementado por meio do ambienteX-BDI [M ora 2000], avalia o relacionamento do jogador com o jogo, propriamente dito,auxiliando o aluno com mensagens de ajuda.

O trabalho desenvolvido por Giraffa [Giraffa 1999], reservou-se a explorar oensino da conscientizacao ecologica com o auxılio de um “tutor” artificial atraves deum ambiente que utiliza a metafora de jogos. O problema abordado e as solucoesapresentadas trouxeram desafios para serem trabalhados.

Em seguida foi desenvolvido o RL-MCOE [Callegari 1999]. Nesse trabalhoeapresentada uma proposta de ampliacao da arquitetura multiagente reativa descrita em[Giraffa 1999], atraves de uma tecnica de aprendizagem por reforco (W-Learning). Essatecnica trouxe resultados que ampliaram a capacidade de exploracao do ambiente de jogo,pois os agentes reativos (peixes) aprenderam novos comportamentos.

Em 2001, foi apresentado o E-MCOE [Goulart 2002], que propoe a introducao

Figura 1. O jogo MCOE.

de um agente mediador no MCOE, mediando as trocas de informacoes entre o jogo e otutor. Essa funcionalidade tambem utilizou agentes reativos modelados com a tecnica deaprendizagem por reforco proposta em [Callegari 1999]. Porem, os agentes aluno e tutorforam codificados de acordo com o modelo BDI de agentes cognitivos. Nesse trabalho,entao, foram levadas em consideracao tarefas/processos externos que normalmente saotratados no modulo tutor. Esses processos externos permitem distribuir a complexidadeda modelagem e supervisao do conjunto de informacoes entre a interacao dos agentes.

Finalmente, em 2005, iniciou-se o projeto AS-MCOE, que, conforme ja descritoanteriormente, tem como objetivo avaliar a utilizacao de tutores inteligentes no ensinode ecologia, dando continuidade ao trabalho desenvolvido no ambiente MCOE. Porem,o tutor e os agentes dessas propostas estao sendo implementados por meio da linguagemAgentSpeak(L) e do interpretador Jason. Os agentes desse estudo estao inseridos em umjogo, construıdo atraves da Golden T Game Engine (GTGE).

Assim, para melhor compreensao da teoria de agentes apresentada, na proximasecao sao abordados os conceitos relacionados a agentes cognitivos baseados em estadosmentais BDI.

3. Agentes Cognitivos

O paradigma orientado a agentes permite um nıvel de abstracao que nao e usual nasmetodologias tradicionais de modelagem e implementacao, istoe, torna explıcitas, no

sistema, certas funcionalidades que antes ficavam apenas subentendidas.A medida emque as aplicacoes tornam-se maiores e mais complexas,e necessario que se utilize nıveisde abstracao que permitam representar os problemas e suas solucoes da forma maisnatural possıvel. Os agentes, como entidades autonomas com capacidade de planejarsuas acoes, reagir e interagir entre si em busca de solucoes para problemas, fornecemrecursos para atingir esse nıvel (mais alto) de abstracao [Zamberlam 2001].

O que caracteriza o agente numa visao mais ampla, conforme em [Giraffa 1999],sao as interacoes que ele realiza com o ambiente e os processos internos que possibilitama realizacao dessas interacoes. A especificacao de quais e como sao esses processosinternose chamada de arquitetura do agente. Dentre as arquiteturas existentes, ha a deagentes cognitivos (deliberativos). Um agente cognitivoe um agente racional que possuialguma representacao explıcita de seu conhecimento e objetivos. Um agente pode ser maiscognitivo do que outro, conforme o grau de racionalidade explıcita de seu comportamento[Oliveira 1996]. Nesse contexto de arquiteturas de agentes cognitivos, ha tambem asarquiteturas baseadas em estados mentais, que adotam uma perspectiva psicologicapara definir a estrutura dos agentes, que sao entidades cujo estadoe constituıdo decomponentes mentais tais como crencas, desejos, capacidades, escolhas e compromissos.

Dentro das arquiteturas baseadas em estados mentais, encontra-se a abordagemBDI (Belief, Desire and Intention). Conforme Wooldridge [Wooldridge 2000],e ummodelo consolidado, por ser amplamente estudado. A ideia basica desta abordageme descrever o processamento interno de um agente utilizando um conjunto elementarde estados mentais como crenca, desejo, intencao e na definicao de uma estruturade controle atraves da qual o agente seleciona racionalmente o curso de suas acoes.Algumas abordagens de arquitetura BDI agregam as nocoes de planos e objetivos,como por exemplo, os trabalhos de Bratman [Bratman 1984, Bratman et al. 1987,Bratman 1989, Bratman 1990], Rao e Georgeff [Rao and Georgeff 1992], Cohen eLevesque [Cohen and Levesque 1987].

As crencas de um agente referem-se ao que o agente acredita sobre o ambienteem que se encontra, sobre os outros agentes e sobre si mesmo [Bratman et al. 1987,Bratman 1989]. E o conhecimento do ambiente de forma explıcita, podendo serincompleto ou incorreto. Os desejos de um agente referem-se aos estados que o agentedeseja atingir (objetivos). Os desejos, num dado momento, podem:

• estar em conflito com as crencas do agente;• ser, simultaneamente, conflitantes com outros desejos;• nao causar diretamente as acoes, mas podem, potencialmente, gerar suas

ocorrencias, deixando por conta das intencoes a realizacao de tais acoes.

As intencoes referem-se a um conjunto de objetivos que o agente deliberoualcancar e que, para tanto, exigiram um comprometimento do agente para realizacao dedeterminadas acoes ou tarefas [Bratman et al. 1987]. O processo de inferencia de umagente BDI inclui, conforme em [Hubner et al. 2004]:

• atualizar crencas, a partir de percepcoes do ambiente;• definir os objetivos possıveis;• deliberar sobre os objetivos que vai tentar alcancar para confirmar as intencoes;• agir com base nas intencos assumidas.

Existem algumas linguagens e ferramentas que possibilitam a modelageme a programacao de agentes BDI, neste trabalho sao abordados:(i) a linguagemAgentSpeak(L); (i) o interpretador Jason e (iii ) o ambiente X-BDI.

4. AgentSpeak(L)A Linguagem AgentSpeak(L), proposta por [Rao 1996],e uma extensao da programacaologica para a construcao de agentes BDI em sistemas de planejamento reativos(reactive planning systems). Sistemas de planejamento reativos sao sistemas que estaopermanentemente em execucao, reagindo a eventos que ocorrem no ambiente em queestao situados atraves da execucao de planos que se encontram em uma bibliotecade planos parcialmente instanciados [Bordini and Vieira 2003]. Essa linguagempermite realizar verificacoes formais, validando os modelos especificados/definidos emaplicacoes.

Segundo [Rao 1996], um agente AgentSpeak corresponde a especificacao de umconjunto de crencas e um conjunto de planos. As informacoes sobre os desejos (osestados futuros a serem atingidos), alem das alternativas disponıveis ao agente paraativar as intencoes (atingir seus objetivos), estao implicitamente representadas nos planos[Hubner et al. 2004].

Planos sao referenciasas acoes basicas de agentes no ambiente, ou seja, um planodetermina uma forma de atingir um determinado objetivo (cabeca do plano). Formadopor um gatilho de evento (denotando o proposito do plano), seguido pela conjuncao decrencas (literais), representando o contexto (consequencia logica das crencas correntesdo agente para um plano aplicavel). O restante do planoe composto por acoes basicas,que o agente deve executar, e/ou subplanos (realizacoes ou testes de verificacao), istoe, objetivos intermediarios que deve tentar atingir, para que o plano tenha sucesso. Asatisfacao de uma pre-condicao e a ocorrencia de um evento ativador sao as condicoespara que um plano possa entrar em execucao [Hubner et al. 2004].

Al em disso, para a implementacao de um agente AgentSpeake necessariaespecificacao das funcoes de selecao de eventos, planos aplicaveis e intencoes do mesmo.As mudancas dos ambiente, os objetivos e as intencoes do agente podem representarum numero significativo de alternativas viaveis de selecao a cada ciclo de execucao dosistema, caracterizando um problema de escalonamento. As funcoes de selecao nao saode responsabilidade da linguagem mas do programador, pois elas podem serunicas paracada agente. Cabe ao ambiente de execucao do programa determinar os criterios paraselecionar, entre os planos habilitados a execucao, aquele que sera executado a seguir.

Para exemplificar a modelagem de planos, o exemplo de codigo a seguir descreveo comportamento de um peixe em perseguir e comer outro peixe de acordo com posicaoe o tipo de presa a sua volta.

+percebe(peixeP, DIRECAO): fome<- mover(DIRECAO).

+colisao(ID, peixeP): fome<- comer(ID).

Considere um peixe de tamanho medio que percebe outro de tamanho pequeno(+percebe(peixeP,DIRECAO)) numa determinada direcao. Considerando seu contexto

atual (fome), seu plano consiste basicamente em se mover na mesma direcao de sua presa(mover(DIRECAO)), cuja acao basica sera executada no ambiente. Alem disso, conforme[Hubner et al. 2004], um agente AgentSpeake composto por:

• +crencae -crencasao eventos que acrescentam (+) ou removem (-) crencas doconjungo de crencas do agente;

• !objetivo e ?objetivo sao objetivos que o agente precisa alcancar (!) atravesda realizacao de um sub-plano, ou verificar se ja consta como alcancado (?),examinando suas crencas;

• acaoe qualquer acao interna ou externa, disponibilizada pelo interpretador para oagente.

4.1. Interpretador Jason

O interpretador Jason, proposto por Hubner em [Hubner et al. 2004],e um sistema paramodelagem e execucao de agentes AgentSpeak. Nelee possıvel descrever planos, crencase o ambiente em que os agentes estao inseridos. Elee distribuıdo na forma de umplug-in da IDE Jedit1, que viabiliza mecanismos para facilitar a configuracao, codificacao eexecucao de um Sistema MultiAgente - SMA (MultiAgent System).

O Jason pode ser executado em tres diferentes modos. O modo normal executa oSMA de forma contınua, ao contrario do mododebug, que executa passo-a-passo a cadaciclo de raciocınio dos agentes. Alem disso, o sistema desenvolvido pode ser integradoa outro sistema, de forma a implementar apenas o raciocınio de agentes inseridos nodesenvolvido. Isso viabiliza, por exemplo, a comunicacao de agentes com sistemaslegados utilizando protocolos de comunicacao diferenciados.

Conforme Hubner [Hubner et al. 2004], Jasone um interpretador completamentedesenvolvido e consolidado para versoes de AgentSpeak(L) com atos de fala (speech-act) para a comunicacao entre agentes. Atraves do ambiente SACI (Simple AgentCommunication Infrastructure), o sistema multiagente Jason pode ser utilizado em redesde computadores. Outra importante caracterıstica em relacao a outros interpretadores deagentes BDI,e que ele foi implementado na linguagem Java, esta disponıvel em codigoaberto (Open Source) e distribuıdo sobre a licenca GNU LGPL.

5. GTGE

Segundo [Studios 2006] oengineGTGE e uma biblioteca/API de programacao multi-plataforma para o desenvolvimento de jogos escrita na linguagem Java. Ela forneceum conjunto de rotinas de alto nıvel para programacao orientada a jogos, a fim de queo programador tenha facil acesso a recursos de hardware, como placas aceleradoras devıdeo e som, e rotinas de jogos comuns, como deteccao de colisoes e o comportamentode personagens.

6. AS-MCOE

Nesta secao sao apresentadas as etapas que compoem a metodologia empregada namodelagem, implementacao e avaliacao do projeto.

1http://www.jedit.org

6.1. Especificacao dos atributos do jogo

O desenvolvimento de um jogo implica na especificacao detalhada dos personagens,suas acoes e percepcoes, alem das leis que regem o ambiente. Neste caso, as acoese percepcoes sao determinadas pelo papel de cada personagem. Um peixe pode, porexemplo, se mover e perseguir outros seres que sejam considerados alimento. Umpersonagem poluidor (que nao e inteligente) e as ferramentas ou “poderes” do jogadorinfluenciam a saude da cadeia alimentar, e todos esses fatores determinam o grau delimpeza do lago, representado no jogo por um objeto chamado ecometro (medidor),calculado a partir da media da energia dos seres vivos. Parte dessas heurısticas eapresentada na Tabela 1 de acordo com um estudo realizado por especialistas apresentadoem [Giraffa 1999].

Retirada ReposicaoPersonagem vs. Interventor Lixo Urbando Pesca predatoria Esgoto domestico Pescar emarea permitida Devolver peixes em reproducaoPeixe Pequeno -5 -30 -10 +10 +20Peixe Medio -5 -20 -10 +10 +20Peixe Grande -5 -10 -10 +10 +15Plantas -10 - -10 +5 +5

Tabela 1. Retirada e reposic ao de energia [Giraffa 1999].

6.2. Modelagem e implementacao de uma interface de software entre oengineGTGE e o interpretador Jason

A integracao do engineGTGE e do interpretador Jasone modelada e implementadapor meio da troca de mensagens entre oKernel, que representa o ambiente numaimplementacao Jason, e o Jogo, que estende a classe Game do pacote GTGE. A Figura 2apresenta o diagrama que descreve os classes de objetos que implementam os conceitos,atributos e relacionamentos do jogo.

A classeKernel representa o tratamento das acoes e percepcoes dos agentes numambiente AgentSpeak. Ela troca mensagens com a classeJogoque modifica o estadodo jogo, modelado pelas demais classes (Ambiente, SerVivo, etc). Por outro lado, essasalteracoes geram, eventualmente, novas percepcoes que sao entao transmitidas aoKernel.Cada personagem inteligente (SerVivo, Tutor ou Aluno), representado graficamente pelaGTGE, infere novas acoes a partir das percepcoes fornecidas peloengine.

6.3. Implementacao do jogo

O jogoe implementado seguindo as especificacoes de “jogabilidade”, interface grafica ehelp onlineutilizados no projeto MCOE. Apenas odesigngrafico foi aprimorado com oauxılio de profissionais daarea de comunicacao que fazem parte da instituicao de ensinoem que a pesquisae realizada. A Figura 3 ilustra o prototipo desenvolvido.

Para esse jogo foram desenvolvidos mecanismos especıficos para o tema emquestao. A cadeia alimentar exige que os personagens possuam um “area de percepcao”,de tal forma que possam decidir as acoes a serem tomadas. Por exemplo, um peixede tamanho “Grande” (vermelho ou a direita na imagem) persegue peixes de tamanho“M edio” (verde ou a esquerda da figura) quando ele esta com fome e estes estao dentrode suaaera de percepcao. A avaliacao daarea de percepcao de cada personageme feitadurante oupdatede cada quadro da animacao.

����� ��������� ����������������� ���������������� ��� �

��� �� !�"!# �$ $ �%������ ���&�('��$ $ �������� ��*)����+'��$ $ �%������ ��� # �$ $ �������� �&�� ��� ����,�-�-�. ����

��� /!0�*��-!� %$ � �

132 4�� ����� /�0� �2 5�6&��*��-!� �$ � �

7�8%� 5��� �0�/�8�6" ���������� 9;:�$ �

7+� 0!<!=(2 � 8�>

? 0�6�8�3 �� � @A���-%)�$ B����� ��3)�:�C��!� �� �. ��:����C�D� ��&��. -��!����3$ ��!C��$ � ��� EF$ ��:�G� B���H+I��

J 0�5��� ? � ?;K

K �L!2 � �� �6�8� ��" . -�����%$���M�-������$�!N �B�)�� !O�B � -%��� ���&� 9�� $ ���+P ��B � -��*� D�%$ ���

Q���/��"�R �$ ���.���S%�$ ���." :�. ��T�'� . �C&�(U%. �!T('! . �C�*������B��$ � ���&� 9�� $ ���%P � :�-&�� ��� ��*��-!� �$ � ���&� 9�� $ ���+P ��B���-&�� ��� ��*��-�$ $ �$ � ����� 9%� $ ������3B�-���%$ � ���&� 9%� $ �!����*�� � �. V�B�-���!� $ -�� ����!�$ �� ��O������� �� ���&� 9%� $ �!���

7%8�2 W�8�*��-!� �$ � C% $ �B���-&�� ��� �

�A/�8� �� 8�7%��� ��2 >�����X����$ �C� $ ��� -!O%��,� ���� �� �

�A/��!0" . ��:�-&��,!-�-�. �������) Y ��$ � ��*. ��:���$ � �

�Z6�[�2 8� �� 8" B���C�� �!O+. ������ ��$�� 9+�$ \% � -"�] -���-&� ] -���-" :�. ��T('! . �C&�(U%. �!T('! . �C"�# )��!C�-�M�����-&�('!)��!C�-�M�����-" ����)��&� O���)��" �������� %U�-�. )� C�-�$�� O������� %U�-�. )� C�-%$" ��������^� 9A:�$ � �* �����$ %U��$ ��-��!�������� _ I`� 9�� $ ���+P � :�-&�� ��� ��*$ ���-!� %$ U��$ ��-����������� _ Ia� 9�� $ ������*�� � �. V�B�-����� $ -�� ���� ����* �����$ !O������� %U�-�. )� C�-%$ � ���+U�-�. )� C�-�$��( ��� ����B���-!O%. )���-%� :!�$ ��-���������*O%. )���-&�� ��� P ��B���-&�� ��� �

" ���%U�-�. )� C�-�$

b%8�� �8��" Y -���-&� ] -���-" ���%�*%M�-���C��$�� EZ�����M!-���C�%$�*:��$ B��:!B���-�� ���&� 9�� $ ���%P(:��$ B��:!B���-���U��$ B��:�B���-%P -�,�Y !� -&� 9�� $ ���%�

� R �$ ��%.��Y -���-

� ] -���-

��:�. �!T('! . �C

��:�. �!T('! . �C

=(�� !>��%c�0�/��" . ��:�-&��,�-�-�. �������) Y ��$ � ��*. ��:���$ � �

d 8�� e�2 L��" %���$ �� ��� C�-�)�,�. " �� � -��(,�-�-�. ����" :!�$ B��:!B���-&� 9A:�$ � ���C� B� -����%V+���$ �� ��� f!� C��� ��� ��*$ ���-!� %V+���$ �� ��� f!� C&�� ��� �

��B���C�% �!O+. ������ ��$

� # )���C�-�M�����-

�!����)!�

Figura 2. Diagrama de classes.

6.4. Modelagem e implementacao em AgentSpeak(L) dos personagens agentes dacadeia alimentar

Os personagens, que fazem parte da cadeia alimentar, foram modelados e implementadosde diferentes formas ao longo dos projetos apresentados na secao 2. Em [Callegari 1999] acadeia alimentar aprende como se comportar ao longo jogo, o que exige um tempo para seestabilizar. No AS-MCOE os personagens inteligentes sao modelados em AgentSpeak(L)para que estes desempenhem o seu comportamento desde o primeiro instante de jogo,sem comprometer a simulacao e o realismo do mesmo. O exemplo de codigo da secao 4,descreve os planos de um peixe “Grande” para perseguir um peixe “Medio”.

6.5. Remodelagem do tutor inteligente proposto em [Giraffa 1999] utilizando alinguagem AgentSpeak(L)

O tutor inteligente proposto por Giraffa foi traduzido para a linguagem AgentSpeak(L),onde questoes particulares de ambas as linguagem tiveram de ser avaliadas. Na linguagemX-BDI, onde o tutor foi originalmente modelado, os desejos sao codificados de formaexplıcita e os planos que permitem realizar estes desejos sao crencas que se tornamrealidade mediante a um conjunto de condicoes. O codigo a seguir exemplifica o desejodo tutor em ajudar os alunos.

DES(tutor, ajudar_alunos).BEL(tutor, ajudar_alunos) if

BEL(tutor, envia_mensagem).

Figura 3. O prot otipo AS-MCOE.

O tutor deseja ajudar os alunos (DES(tutor, ajudaralunos)) e a maneira deconcretizar este desejoe acreditar que ele envia mensagensBEL(tutor, enviamensagem)para os alunos quando for necessario. Para isso, o codigo a seguir exemplifica um exemploque concretiza a crenca do envio de mensagens.

BEL(tutor, envia_mensagem) ifBEL(tutor, next(BEL(aluno, receber_ajuda))),BEL(energia_ecomentro (Ee)),Ee >= 70,Mensagem(16).

A crenca de que o tutor enviou uma mensagem (BEL(tutor, enviamensagem))torna-se verdadeira quando as seguintes condicoes sao satisfeitas: (i) o aluno desejareceber ajuda (BEL(aluno, receberajuda)), (ii) o nıvel do ecometroe bom e esta acimaou igual a 70 e (iii) a acao de enviar mensagem numero 16 foi realizada. Observa-se que acrenca de que o aluno deseja receber ajudae uma condicao futura, colocando um gatilho(trigger) nessa crenca.

Para modelar os desejos e crencas do tutor e demais agentes em AgentSpeak(L),deve-se considerar que nao ha uma representacao explıcita de desejos nessa linguagem.Desejos sao, em AgentSpeak(L), objetivos que podem ser realizados por planossubplanos, ou seja, planos que sao ativados por eventos internos.

+ajuda[source(aluno)] : energia_ecometro(Ee) & Ee >= 70<- mensagem(16).

A sintaxe do codigo anterior descreve um plano para o evento externo em que oaluno (source(aluno)), que tambeme considerado um agente, solicita ajuda do tutor. Esteentao verifica as pre-condicoes para auxiliar o aluno e entao envia uma mensagem.

6.6. Especificacao de um modelo de experimento em sala de aula e avaliacao dosresultados.

Por fim, um experimento em sala de aula esta sendo elaborado com a finalidade de avaliaro aprendizado dos alunos com o jogo, e sera composto pelas seguintes etapas:

1. Avaliar os alunos antes do experimento: com o auxilio dos professores debiologia (e/ou disciplinas corespondentes ou relacionadas) desenvolver o conteudode ecologia abordado na pesquisa e elaborar uma avaliacao que identifiquepontualmente o conteudo;

2. Experimento: desenvolver e aplicar um experimento em laboratorio com umaturma de alunos (cujo ano colegial sera definido). O experimento compreende nasseguintes atividades:

(a) Jogar: disponibilizar o jogo produzido por esta pesquisa aos alunos sobcondicoes controladas de: tempo, coleta de dados sobre a interacao; e

(b) Avaliacao do jogo: compreende a coleta de informacoes sobre asdificuldades e qualidades apresentadas pelo jogo, por meio da observacaoe relato dos alunos durante as atividades.

7. Consideracoes Finais

Este artigo apresenta uma proposta de traducao de um tutor inteligente modelado nalinguagem X-BDI para a linguagem AgentSpeak(L) e a modelagem do comportamentode seres vivos de uma cadeia alimentar nessa mesma linguagem.

O ambiente multiagente implementado neste trabalho baseia-se no paradigma dosjogos eletronicos e se utiliza de umenginede jogos para sua codificacao rapida. OengineGTGE viabilizou, alem da prototipacao rapida, um incremento da performancee da qualidade de interacao, assim como uma melhor integracao para com o ambiente deimplementacao de agentes BDI.

O projeto AS-MCOE esta desenvolvendo experimentos em sala de aula paraavaliacao do jogo e do sistema multiagente implementado, que no entanto nao puderamser relatados neste artigo ate finalizacao do mesmo.

Referencias

ASYMETRIX (1994). ToolBook : user manual. Bellevue, WA.

Bordini, R. H. and Vieira, R. (2003). Linguagens de programacao orientas a agentes:uma instroducao baseada em agentspeak(l).Revista de Informatica Teorica e Aplicada,X(1):7–38.

Bratman, M. (1984). Two faces of intention.The Philosophical Review, v.93, n.3, pages275–405.

Bratman, M. (1989). What is intention? InCohen, Morgan and Pollack, eds. Intetions inComunication. MIT Press.

Bratman, M. (1990).Intention, plans and practical reason. Harvard University Press,Cambridge, MA.

Bratman, M., Israel, D., and Pollack, M. (1987).Toward an architecture for resource-bounded agents. Stanford University, Stanford.

Callegari, D. A. (1999). Aplicando aprendizagem por reforco a uma arquiteturamultiagente para suporte ao ensino de educacao ambiental. Master’s thesis,PPGCC/PUCRS, Porto Alegre.

Cohen, P. and Levesque, H. J. (1987). Intention = choice + commitment. InNATIONALCONFERENCE ON AI, Berlin. Springer-Verlag.

Giraffa, L. M. M. (1999).Uma Arquitetura de tutor utilizando estados mentais.Tese dedoutorado., CPGCC/UFRGS, Porto Alegre.

Goulart, R. R. V. (2002). Utilizando a tecnologia de agentes na construcao de sistemastutores inteligentes em ambiente inteligente. Master’s thesis, PUCRS, Porto Alegre,Brasil. Defesa em dezembro de 2001.

Hubner, J., Bordini, R., and Vieira, R. (2004). Introducao ao desenvolvimento de sistemasmultiagentes com jason. InXII Escola de Informatica da SBC, volume 2, pages 51–89,Guarapuava. UNICENTRO.

Mora, M. D. C. (2000). Um modelo formal e executavel de agentes BDI.Tese dedoutorado., CPGCC/UFRGS, Porto Alegre.

Oliveira, F. (1996). Inteligencia artificial distribuıda. InIV Escola regional de informatica,Canoas, RS. Sociedade Brasileira de Computacao.

Rao, A. S. (1996). AgentSpeak(L): BDI agents speak out in a logical computablelanguage. In van Hoe, R., editor,Seventh European Workshop on ModellingAutonomous Agents in a Multi-Agent World, Eindhoven, The Netherlands.

Rao, A. S. and Georgeff, M. P. (1992). An abstract architecture for rational agents. InInternational Conference on Principles of Knowledge Representation and Reasoning -KR, 3., pages 439–449. Morgan Kaufman.

Studios, G. T. (2006). Golden t game engine. [Online; accessed 27-Junho-2006].

Wooldridge, M. (2000).Reasoning about rational agents. The MIT Press, London.

Zamberlam, A. D. O. (2001). Em direcao a uma tecnica para a programacao orientada abdi. Master’s thesis, PPGCC/PUCRS, Porto Alegre.

AISO-GT: Um Novo Algoritmo Híbrido de Otimização Baseado nos Sistemas Imunológicos Artificiais e na Teoria dos Jogos

André Ferry Barreira 2,3, Carlos Eduardo de Jesus Guimarães Oliveira2,3, Otavio Noura Teixeira1,2,3, Roberto Célio Limão de Oliveira1

1Programa de Pós-Graduação em Engenharia Elétrica (PPGEE), Departamento de Engenharia Elétrica e Computação (DEEC), Universidade Federal do Pará (UFPA)

Caixa Postal 8.619 – 66.075-900 – Belém, PA, Brasil

2Área de Ciências Exatas e Tecnologia (ACET), Centro Universitário do Pará (CESUPA) Av. Gov. José Malcher, 1963 – 66.060-230 – Belém, PA, Brasil

3Movimento Evolucionário e Cooperativo para a Construção do Artificial – MEC2A Av. 16 de Novembro, 881 – 801 – 66.023-220 – Belém, PA, Brasil

{afbarreira,ceguimaraes,onoura}@gmail.com, limão@uf pa.br

Resumo. Este artigo apresenta a proposta de um novo algoritmo de otimização avançada baseado na técnica de Sistemas Imunológicos Artificiais e nos Princípios da Teoria dos Jogos, mais especificamente, na inclusão de uma fase denominada “Interação Social” no algoritmo original. Para isso, são apresentados aspectos relativos aos temas de fundamentação teórica, a proposta do algoritmo em si, e finalmente, uma simulação para exemplificar o seu funcionamento.

1. Introdução

A natureza, em sua perfeição, sempre contorna situações difíceis de maneira a se manter viva. Tendo isso em vista alguns pesquisadores vêm desenvolvendo métodos, processos e algoritmos que, baseados na natureza, simulam computacionalmente o seu comportamento de maneira a resolver problemas matematicamente insolúveis. Assim surgiu a Computação Natural.

Segundo Forrest et al. (1999), um dos mecanismos biológicos mais poderosos existentes é o Sistema Imunológico Humano. Por esse motivo ele tem sido alvo de estudo de muitos pesquisadores na tentativa de desenvolver modelos que possuam as mais importantes de suas características, como por exemplo, a auto-organização.

Em meados de 1980, os cientistas: Farmer, Packard and Perelson publicaram o primeiro estudo sobre as Redes Imunológicas, que daria início ao que hoje é denominado Sistemas Imunológicos Artificiais (AIS – Artificial Immune System).

2. Sistemas Imunológicos (SI)

O Sistema Imunológico é um complexo de células, moléculas e organismos, que juntos funcionam como um mecanismo de identificação capaz de perceber e combater disfunções de suas próprias células e microorganismos invasores. Ele é responsável pela “limpeza” do organismo, retirando células mortas, renovando determinadas estruturas, entre outras funções. Além disso, também age em células alteradas, as quais diariamente surgem no nosso corpo como resultado de mitoses anormais e, caso essas células não sejam destruídas, estas podem vir a se tornar tumores.

As células do SI são altamente organizadas. Cada tipo de célula age de acordo com sua função. Umas são encarregadas de receber ou enviar mensagens de ataque e, em outros casos, mensagens de inibição. Algumas apresentam o inimigo ao “exército” do Sistema para que sejam combatidos e outras liberam substâncias que neutralizam o microorganismo invasor, ou alguma substância liberada por ele. Junto com os outros sistemas, o SI permite a regulação do corpo, garantindo o seu funcionamento estável.

Existem dois sistemas que são responsáveis pelo reconhecimento de microorganismos invasores: Sistema Imunológico Nativo (SIN) e o Sistema Imunológico Adaptativo (SIAd). O SIN é assim chamado porque tem a habilidade de reconhecer certos micróbios e imediatamente destruí-los.

Um importante componente desse sistema é uma classe de proteínas do sangue que tem como função auxiliar os anticorpos no combate aos microorganismos. O aspecto mais importante do reconhecimento do SIN é o fato de induzir a geração de sinais co-estimulatórios que irão resultar na ativação das células T, uma das principais células de defesa, promovendo o início da resposta do Sistema Imunológico Adaptativo.

O SIAd usa receptores de antígenos somáticos que são clonados e distribuídos em dois tipos de linfócitos: células T e B. Esses receptores são gerados por processos aleatórios e, assim, o formato geral da resposta do SIAd é baseado no principio da Seleção Clonal dos linfócitos com particularidades específicas (Burnet, 1978).

3. Sistemas Imunológicos Artificiais (SIA)

Segundo De Castro et al., (2002) os Sistemas Imunológicos Artificiais são sistemas adaptativos inspirados na teoria imunológica e na observação das funções imunológicas, seus princípios e modelos, que são aplicados na resolução de problemas.

A seguir descreve-se os modelos e princípios, e sua relevância para o processo de evolução da população de indivíduos.

3.1. Teoria da Seleção de Clones

O processo de reprodução no Sistema Imunológico é realizado de forma assexuada (clones), dessa maneira se faz necessária uma seleção dos clones para que o sistema possa evoluir. A teoria parte da premissa que para evoluir é preciso reproduzir somente as células que reconhecem os antígenos.

Conforme Burnet (1978), os principais passos da teoria de seleção de clones são:

� Mutacionar as células-clone (cópias dos seus pais) com altas taxas (hipermutação somática);

� Eliminar os linfócitos atualmente diferenciados que apresentem receptores similares;

� Proliferar e diferenciar o contato das células maduras com os antígenos; � A persistência dos clones esquecidos, resistentes à eliminação pelos

antígenos, como base das doenças imunológicas;

3.2. Reforço de Aprendizado e Memória Imunológica

A Teoria de Seleção de Clones por si só não proporciona um eficiente combate aos microorganismos invasores, pois em caso de re-infecção o processo teria que ser iniciado novamente. Conseqüentemente, passa a ser necessária uma memória auxiliar que armazene as configurações das células que apresentam maior adaptabilidade.

Quando o Sistema Imunológico detecta uma célula estranha é iniciado um processo de geração de linfócitos que, de acordo com sua afinidade com o antígeno, é ou não clonado. Em caso de alta afinidade, a célula é clonada e os clones se diferenciam em Células de Memória - responsáveis por manter as configurações das células com maior adaptabilidade, pois possuem um tempo de vida maior - e Células de Plasma, responsáveis pela produção de anticorpos, os quais tem como finalidade o combate às células estranhas.

A primeira resposta do Sistema a um determinado antígeno é lenta, pois os processos de clonagem e mutação ainda serão realizados para geração das células de combate eficientes para aquele determinado antígeno. Já a segunda resposta é mais rápida, pois só é necessário o processo de clonagem nas células de memória as quais resultarão em células de combate eficientes.

3.3. Hipermutação Somática

Durante a clonagem, é realizado um processo de mutação com o objetivo de otimizar as células. O processo é denominado hipermutação somática, e provê as células com maior adaptabilidade uma taxa de mutação baixa, enquanto que, as células com baixa adaptabilidade, as quais são consideradas pobres, tem taxa de mutação mais elevadas.

3.4. Algoritmo AISO

O algoritmo AISO foi desenvolvido baseado no modelo e nos princípios do Sistema Imunológico Humano sendo voltado especificamente para otimização e inspirado no algoritmo Opt-AiNet proposto por De Castro (2002) o qual é extensão do algoritmo AiNet voltado para otimização. O AISO consiste em uma população de células (anticorpos) que são representados por um vetor com valores reais. Cada célula é uma solução em potencial para o problema a ser otimizado.

A população passa por um processo de clonagem, mutação, seleção. O algoritmo utiliza uma memória de células onde são armazenadas as melhores soluções (células) no momento. A estrutura da célula é mostrada a seguir:

As principais características deste algoritmo são: (1) ele determina a localização de múltiplos pontos ótimos; (2) capacidade de manutenção de vários pontos ótimos; (3) demonstra a exploração do espaço de busca.

As principais terminologias utilizadas são:

� Células: indivíduos da população. Não utiliza codificação. São utilizados valores reais no espaço Euclidiano;

� Fitness: representa a adaptabilidade de uma determinada célula em relação à função de avaliação;

� Clone: células que são cópias idênticas de seus pais;

� Clone “Mutacionado”: clone que passou pelo processo de hipermutação somática.

A estrutura do algoritmo:

1. Iniciar a população de células iniciais;

2. Enquanto o critério de parada não for atingido faça:

2.1. Determinar o Fitness de cada célula com a função avaliação

2.2. Gerar N clones para cada célula;

2.3. Cada clone sofre hipermutação somática com taxa proporcional ao Fitness das células pais;

2.4. Determinar o Fitness de todas as células da rede;

2.5. Para cada grupo de clone selecionar o melhor Fitness e remover os outros;

3. Determinar as células com maior fitness e gravá-las na memória;

4. Introduzir uma porcentagem X de células geradas randomicamente.

Os clones sofrem mutação de acordo com a adaptabilidade da célula pai. A taxa de mutação proporcional a fitness é definida da seguinte forma:

C’ = c + α, sendo α= ((1/β) exp(f*))*R(-1.1); (01)

onde α é a taxa de mutação, c é a célula pai, C’ é o clone mutacionado de c, R é um valor randômico que varia entre (–1 e 1). β é um parâmetro que controla a deterioração da função exponencial inversa (valor padrão 10) e f* é o fitness de c normalizado no intervalo de 0 e 1. Para normalizar o valor do fitness é utilizado um valor máximo para a comparação, sendo esse valor o melhor fitness no momento. 4. Teoria dos Jogos

De acordo com Borges (1996) a teoria dos jogos lida com situações de conflito de interesses, onde dois ou mais agentes (ou indivíduos) disputam entre si por algum recurso limitado no ambiente.

A teoria dos jogos descreve problemas reais, fornecendo uma visão geral da situação. Em alguns casos a teoria pode indicar a solução para o problema, entretanto, na maioria dos casos, apresenta a cada indivíduo a melhor forma de agir.

Anatol Rapoport em “Luta, jogos e debates” diz que um agente racional pode ser definido como um indivíduo que age racionalmente. Isso leva a consideração de todas as possíveis conseqüências de seus atos e, a partir disso, se realiza uma certa ordem de preferência entre as conseqüências, baseado em seus próprios atos e na ação que gerou o seu melhor resultado.

Em alguns casos o resultado não depende unicamente da escolha feita por um único indivíduo, mas sim da ação escolhida pelos outros indivíduos, sobre os quais o primeiro indivíduo não possui qualquer controle.

É interessante notarmos que um Agente Humano não toma decisões de acordo com o que (Rapoport, 1996) define como racional, isso é, com a intenção de maximizar seus ganhos. Aqui percebemos a diferença entre Agentes Racionais e Agentes Humanos.

Pode-se identificar todos os elementos necessários para a compreensão do objetivo principal da teoria dos jogos a seguir:

� Jogo: um modelo formal, o que significa que a teoria dos jogos envolve descrições e análises técnicas. É importante notar que os únicos tipos de jogos tratados pela Teoria dos Jogos são os estratégicos;

� Interações: as ações individuais de cada agente afetam os outros agentes;

� Agentes: qualquer indivíduo ou grupo de indivíduos tem capacidade de tomar decisões que afetam outros agentes. O agente no contexto da teoria dos jogos é denominado “jogador”;

� Racionalidade: assumindo que todos os agentes são racionais, significa que eles utilizam o método mais adequado buscando a satisfação dos seus desejos;

� Comportamento Estratégico: isso significa que cada jogador leva em consideração o fato de que todos os jogadores interagem entre si. Dessa maneira, a decisão tomada irá gerar conseqüências aos outros jogadores.

Para exemplificar o jogo, temos o Paradigma do Dilema do Prisioneiro, que pode ser definido tradicionalmente como uma situação de conflito de interesses, onde dois indivíduos são presos e colocados em celas diferentes.

Então, foi proposto a cada preso pela polícia o seguinte:

I. Se um deles confessasse o crime e o outro não, o que tivesse confessado seria posto na jaula por três meses por sua cooperação e o outro indivíduo ficaria preso por dois anos;

II. Se ambos confessarem o crime, então a cooperação individual perde força e ambos ficam um ano presos.

III. Se não, caso nenhum deles confesse o crime, eles serão presos por apenas seis meses.

A Figura 1 mostra a tabela de pagamentos do dilema do prisioneiro, o mais clássico jogo de duas pessoas de soma não zero e não cooperativo na Teoria dos Jogos, que combina todos os possíveis pares de estratégias correlacionando todos os valores de pagamentos com cada um dos jogadores.

Figura 1

Observando a Figura 1, pode-se observar que cada um dos jogadores tem dois tipos de comportamentos: Cooperar(Coperate) e Trair(Defeated). Por trás disso, tem-se quatro variáveis que significam: (1) R é a recompensa (Reward) para cada jogador caso ambos venham a cooperar; (2) P é a punição (Punishment) para cada jogador caso ambos venham a trair; (3) T é a tentação (Temptation) de cada um dos jogadores, caso traiam sozinhos; (4) S é o pagamento do “otário” (Sucker) que coopera sozinho.

A caracterização do Dilema do Prisioneiro é feita de acordo com as seguintes relações:

� SPRT >>>

� 2

STR

+>

� PST

>+2

Essas especificações caracterizam o ambiente onde os indivíduos de uma população irão interagir buscando incrementar o seu Ganho.

5. AISO-GT

Como forma de possibilitar um aumento do controle da variabilidade da população de células, a seguir é proposto um novo algoritmo. Este algoritmo inclui uma nova etapa denominada “interação social”, que foi originalmente proposta por TEIXERA (2005), ao utilizar a Teoria dos Jogos como forma de caracterizar fenotipicamente os indivíduos de uma população, que no caso são as células.

Assim, é proposto o uso especificamente do Dilema do Prisioneiro que possibilita a definição de um ambiente de interação social através da formalização de situações de conflito de interesses, onde os indivíduos da população disputam entre si por recursos nele disponíveis.

A alteração da estrutura da célula se faz necessária tendo em vista a necessidade de armazenamento valor que caracterizará o seu comportamento. A nova estrutura é representada pela figura a seguir:

Figura 2

O campo de Valor e o de Fitness da célula são mantidos segundo a estrutura do algoritmo AISO. O comportamento representa a atitude da célula de cooperar ou trair durante o jogo, enquanto no campo Ganho, são armazenados os valores ganhos de acordo com a tabela de pagamentos do jogo.

A nova estrutura do algoritmo:

1. Iniciar a população de células randomicamente;

2. Enquanto o critério de parada não for atingido faça:

2.1 Determinar o Fitness de cada célula com a função de avaliação;

2.2 Gerar N clones para cada célula;

2.3 Cada clone sofre hipermutação somática com taxa proporcional ao Fitness das células pais;

2.4 Determinar o Fitness de todas as células da rede;

2.5 Para cada grupo de clones repetir até X disputas;

2.5.1 Selecionar duas células aleatoriamente

2.5.2 Obter o comportamento de cada uma das células;

2.5.3 Alterar o Fitness das células conforme o comportamento adotado por cada uma e a tabela de pagamentos do jogo;

2.6 Determinar as células que apresentem os melhores resultados no jogo e excluir as demais.

3. Determinar as células com maior fitness e gravá-las na memória;

4. Introduzir uma porcentagem X de células geradas randomicamente.

Com base na fundamentação teórica e na formalização do algoritmo obtém-se as seguintes considerações finais.

6. Testes

O algoritmo proposto (AISO-GT) foi implementado utilizando a linguagem de programação Java para a minimização da função de benchmarking Schaffer. A população inicial foi gerada aleatoriamente possuindo quarenta indivíduos e utilizada nas cinco execuções que se seguiram sem alteração alguma.

Comparação de desempenho para a função de Schaffer entre os algoritmos AISO e AISO-GT

0,00E+00

5,00E-05

1,00E-04

1,50E-04

2,00E-04

2,50E-04

3,00E-04

3,50E-04

4,00E-04

4,50E-04

7001

7080

7159

7238

7317

7396

7475

7554

7633

7712

7791

7870

7949

8028

8107

8186

8265

8344

8423

8502

8581

8660

8739

8818

8897

8976

9055

9134

9213

9292

9371

9450

9529

9608

9687

9766

9845

9924

Épocas

Fitn

ess AISO

AISO-GT

Gráfico 1

Observou-se com o teste que em determinadas épocas o algoritmo AISO é superior ao AISO-GT e vice versa. Contudo, quanto mais próximo do final da execução pode-se observar que o AISO-GT se destaca em muito, como se pode observar no gráfico 1 (referente as últimas três mil épocas do total de dez mil utilizadas para os testes), que representa o desempenho dos algoritmos durante as últimas três mil épocas.

7. Considerações Finais

Com base na literatura utilizada e os testes decorridos, pôde-se observar que o algoritmo proposto, AISO-GT, teve desempenho superior ao AISO.

Com a função de avaliação Schaffer as expectativas foram atendidas; que o AISO-GT obtivesse melhor desempenho durante a execução dos testes, uma vez que a interação social implementada caracteriza uma maior variabilidade populacional do algoritmo.

Como proposta futura pretende-se implementar funções de benchmarking de diferentes categorias e com isso promover um estudo comparativo no sentido de descobrir em quais categorias de problemas o algoritmo proposto sobressai-se em relação aos utilizados atualmente.

8. Bibliografia

[Borges 1996] Borges, P. S. S. A Model of Strategy Games Based on The Paradigm of the Iterated Prisoner’s Dilemma Employing Fuzzy Sets. 1996. Tese (Doutorado em Engenharia de Produção) – Universidade Federal de Santa Catarina, Florianópolis.

[Burnet 1978] Burnet, F. M., “Clonal Selection and After”, In Theoretical Immunology, (Eds.) G. I. Bell, A.S. Perelson & G. H. Pimbley Jr., Marcel Dekker Inc. 1978, pp. 63-85.

[Coello] COELLO, C. A. C.; CORTES N. C. Solving Multiobjective Optimization Problems Using an Artificial Immune System. CINVESTAV-IPN, Grupo de Computação Evolucionária, Depto. de Elétrica, Seção de Computação.

[De Castro 1999] De Castro, L. N; Zuben, J.V. Artificial Immune Systems: Part I – Basic Theory and Applications. Tecnical Report – DCA, 1999.

[De Castro 2000] De Castro, L. N; Zuben, J.V. Artificial Immune Systems: Part II – A Sruvey of Applications. Tecnical Report – DCA, 2000.

[De Castro 2002] De Castro, L. N; Timmis, J. An Artificial Immune Network for Multimodal Function Optimization. In Proceedings of IEEE Congress on Evolutionary Computation (CEC'02), 2002.

[De Castro] De Castro, L.N.; Campello, E. R. H.; Rosatelli, M. C. Computação Natural: Uma Breve Visão Geral. Programa de Mestrado em Informática Universidade Católica de Santos (UniSantos).

[Forrest] Forrest, S., A. Perelson, Allen, L. & Cherukuri, R. (1999), “Self-Nonself Discrimination in a Computer” , Proc. of the IEEE Symposium on Research in Security and Privacy, pp. 202-212.

[Rapoport 1980] RAPOPORT, A. Lutas, Jogos e Debates. Editora Universidade de Brasília, 1980.

[Teixeira 2005] Teixeira, O. N. Proposta de um novo algoritmo genético baseado na teoria dos jogos. Dissertação de Mestrado (Programa de Pós-graduação em Engenharia Elétrica – Computação Aplicada) - Universidade Federal do Pará, Belém, 2005.

AstroFácil: Sistema Computacional Embarcado para Automatização de Telescópios de Pequeno Porte

Marcos Roberto Silva, Maicon Carlos Pereira, Caroline Farias Salvador, Rafael Luiz Cancian, Roberto Miguel Torres, Cesar Albenes Zeferino

Centro de Ciências Tecnológicas da Terra e do Mar (CTTMar) Universidade do Vale do Itajaí (Univali)

Rua Uruguai, 458 – Caixa Postal 360 – 88302-202 – Itajaí – SC – Brasil silva.marcosr@gmail.com, maicon@univali.br, caroline@univali.br,

cancian@univali.br, torres@univali.br, zeferino@univali.br

Abstract. O uso de telescópios de pequeno porte na observação astronômica amadora é muitas vezes restringido pela dificuldade que astrônomos amadores enfrentam para localizar um astro desejado e acompanhá-lo no céu. Este artigo apresenta o desenvolvimento de um sistema embarcado a ser utilizado na automação de telescópios de pequeno porte visando facilitar a operação desses equipamentos por amadores. O sistema é baseado em um microcontrolador e possui uma interface para o usuário indicar o astro desejado e configurar a observação a ser realizada.

1. Introdução Considerada a mais antiga de todas as ciências, a astronomia já atraia os seres humanos mais primitivos que observavam o céu e tentavam compreender os fenômenos que ocorriam à sua volta, como as variações de luminosidade, de temperatura e de clima, o deslocamento do Sol, os eclipses, as fases da Lua, as passagens de cometas, etc. Com o passar do tempo, esse interesse deu origem a uma ciência natural chamada Astronomia, a qual visa à observação dos astros e a criação de teorias sobre seus movimentos, sua constituição, origem e evolução.

A observação dos astros, também chamada de observação astronômica, pode ser feita a olho nu, mas a visão humana é limitada e restringe muito a capacidade dessa observação. Então, faz-se necessário o uso de equipamentos, como, por exemplo, os telescópios ópticos, que permitem “aproximar” corpos celestes observados a longa distância.

Na última década houve um avanço da astronomia observacional por meio do desenvolvimento de telescópios de grande porte, como, por exemplo, os telescópios de oito metros de diâmetro [Gemini Observatory, 2006], além de telescópios virtuais e remotos acessíveis via Internet [CARA, 2002][Observatórios Virtuais, 2005] [Werneck, Nader e Campos, 2004]. Nessa direção, verificou-se também um aumento do interesse pela observação astronômica amadora, viabilizada por telescópios de pequeno porte e de menor custo, como o telescópio ilustrado na Figura 1, cuja estrutura de sustentação utiliza uma montagem equatorial alemã (o tipo de montagem alvo deste trabalho).

Figura 1. Telescópio com montagem equatorial alemã

Independentemente do porte do telescópio, a observação de um determinado astro implica em apontar o tubo do equipamento para as coordenadas do astro na esfera celeste que, dependendo de como são especificadas, variam conforme o local, a data e o horário. Isso ocorre porque o movimento de rotação da Terra causa um deslocamento aparente (de leste para o oeste) do astro na esfera celeste. Assim, também durante a observação, esse movimento tira o astro da posição inicial da observação e do foco do telescópio, tornando necessário que o observador redirecione o telescópio periodicamente a fim de acompanhar o aparente deslocamento do astro.

Para iniciantes na observação astronômica, a simples localização do astro através de suas coordenadas dificulta a observação e, muitas vezes, desestimula os usuários amadores, levando-os a “aposentar” precocemente o equipamento. No entanto, para facilitar essas tarefas, pode-se equipar um telescópio com um computador dedicado que automatize as operações de localização e acompanhamento de um astro. Esse tipo de computador dedicado, com a aparência de um coletor de dados, é mais conhecido pelo termo “manete” (ou hand controller).

Os manetes modernos são baseados em microcontroladores e oferecem uma série de funcionalidades e facilidades aos usuários. No entanto, como não existem manetes fabricados no Brasil com tais funcionalidades, o acesso a esse tipo de equipamento é restrito a astrônomos profissionais e aos amadores com maior poder aquisitivo, pois o custo dos manetes importados é razoavelmente alto.

Nesse contexto, este trabalho é resultado de um projeto de pesquisa que visa desenvolver e disponibilizar um conjunto de soluções tecnológicas de baixo custo para facilitar a observação astronômica a um maior número de usuários, estimulando a prática contínua dessa atividade por astrônomos amadores e, em especial, por estudantes. O projeto inclui o desenvolvimento do manete apresentado neste artigo, de um sistema Web para compartilhamento de telescópios via Internet [Zeferino et al., 2005], entre outras soluções que irão compor uma suíte tecnológica para auxílio à observação astronômica. Todos esses desenvolvimentos contam com uma infra-estrutura básica de telescópios de pequeno e médio porte adquirida com apoio da Petrobras.

O projeto do manete, foco deste artigo, teve início com um trabalho de conclusão de curso em Ciência Computação [Silva, 2003], e pode ser continuado em uma parceria universidade-empresa fomentada pelo CNPq (Edital RHAE 14/2004).

O manete é baseado em um sistema computacional embarcado e é capaz de comandar a operação de um telescópio, posicionando-o e guiando-o para acompanhar um astro selecionado, tudo de forma automática, facilitando o trabalho do observador. O sistema é baseado em microcontroladores e utiliza periféricos externos para interação com o usuário, armazenamento de informações sobre astros e movimentação do telescópio, conforme serão mostrados nas próximas seções.

O texto deste artigo é estruturado em sete seções, incluindo a Introdução. Na Seção 2 são resumidos alguns sistemas similares. A Seção 3 apresenta a funcionalidade do sistema desenvolvido, enquanto que a quarta seção descreve as arquiteturas de hardware e de software do sistema. A Seção 5 apresenta informações técnicas sobre a implementação e a validação física do sistema e a Seção 6 apresenta uma discussão a respeito do impacto deste trabalho. A Seção 7 conclui com as considerações finais.

2. Sistemas Similares Um manete moderno é um dispositivo baseado em computação embarcada e possui um teclado para a entrada de dados e um display para apresentação de informações ao usuário. Internamente, inclui um ou mais microcontroladores e unidades de memória não volátil para armazenamento de dados, entre outros componentes eletrônicos. O manete é conectado à estrutura que sustenta o telescópio (denominada montagem) através de um cabo de comunicação pelo qual são enviados sinais a um circuito de controle que aciona os motores que movimentam o tubo do telescópio. Alguns modelos mais recentes utilizam conexão sem fio entre o manete e a montagem. A Figura 2 apresenta imagens de dois exemplos de manetes, sendo o primeiro da Meade Instruments Corporation (2006) e segundo da Sky-Watcher (2006).

Figura 2. Exemplos de manetes: Autostar da Meade e SkyScan da Sky-Watcher Fonte: Meade Instruments Corporation (2006) e Sky-Watcher (2006)

Conforme pode ser observado nos modelos ilustrados na Figura 2, a interface do teclado de um manete possui quatro conjuntos básicos de teclas. O primeiro inclui uma tecla para confirmação dos dados de entrada e outras duas teclas cujas funcionalidades dependem do modelo. O segundo conjunto consiste de quatro teclas de sentido para movimentação do tubo óptico. Já o teclado numérico (ou alfa-numérico) é usado para diferentes funções: escolher a velocidade de movimentação do tubo, selecionar a velocidade do motor de focagem (se instalado), entrar com a identificação de um astro, etc... O quarto conjunto de teclas inclui duas teclas para navegação nos menus mostrados no display (orientado a caractere) e, no caso do modelo da Meade, uma tecla para acesso a informações sobre o astro selecionado: “ ”. No modelo da Sky-Watch, as teclas numéricas são multifuncionais, servindo de atalho para algumas funções.

Um dos manetes mais utilizados é o modelo #497 Autostar da Meade Instruments Corporation (2006). Ele disponibiliza várias funções ao observador, como: alinhamento automático do tubo, localização do astro na esfera celeste (capacidade GO TO), acompanhamento do seu deslocamento, entre outros. Contudo, o seu preço no Brasil é de cerca de R$ 690,00 [OMNIS LUX, 2006] e seu uso acaba se restringindo aos astrônomos profissionais e aos astrônomos amadores com maior poder aquisitivo.

Existem manetes com menor custo, porém com funcionalidade limitada (ex. sem as capacidades de localização ou de acompanhamento automáticos), ou com interface de entrada mais restrita. Por exemplo, alguns deles oferecem apenas comandos para guiar o telescópio manualmente, por meio do acionamento dos motores da montagem com diferentes velocidades e com a possibilidade de interromper a movimentação quando o objeto-alvo é apontado. Isso auxilia no deslocamento do tubo e oferece um apontamento mais preciso, se comparado com a operação totalmente manual, mas a localização correta e o acompanhamento do objeto-alvo são feitos pelo observador e não pelo manete.

3. Funcionalidades do Sistema Embarcado para Controle de Telescópios O manete desenvolvido é denominado AstroFácil e tem a finalidade de realizar algumas funções de um manete para controlar telescópios com montagem do tipo equatorial (Boczko, 1984). Essas funções compreendem:

• armazenar informações de corpos celestes; • posicionar o telescópio através da inserção do código de um astro, de suas

coordenadas ou de seu nome; • acompanhar o astro selecionado através de seu movimento aparente; • guiar o telescópio livremente; e • desativar o telescópio, posicionando-o no ponto inicial.

Essas funcionalidades são implementadas na forma de tarefas de software executadas por um microcontrolador embutido no manete (mestre) e um microcontrolador de um circuito de controle auxiliar, acoplado na montagem (escravo). Além do microcontrolador mestre o computador do manete inclui um conjunto de periféricos externos ao microcontrolador. Um teclado oferece uma interface de entrada similar àquela dos modelos de manete ilustrados na Figura 2. Um display de cristal

líquido (LCD – Liquid Cristal Display) serve de interface de saída. Um dispositivo de relógio de tempo real é usado para manter a data e o horário do sistema, necessários à localização dos astros. Chips de memória não-volátil mantêm a base de dados do sistema com informações sobre diversos astros, incluindo, para cada um deles, o código do astro, as suas coordenadas (ascensão reta e declinação) e o ano da obtenção dessas coordenadas, a fim de que elas possam ser precessionadas (ou seja, atualizadas para a data corrente da observação). A base de dados também armazena as coordenadas geográficas (latitude e longitude) de locais de observação. Uma interface serial permite a conexão do manete a um microcomputador de uso geral, permitindo a atualização automática das bases de dados.

Na operação normal do sistema, o microcontrolador mestre obtém a data e o horário do sistema (do relógio de tempo real) e as coordenadas geográficas da cidade onde está instalado o telescópio (mantidas na memória não-volátil). Após, a partir da identificação do astro, ele determina as coordenadas astronômicas atualizadas efetuando os cálculos definidos por Meeus (1998). Por fim, ele envia essas coordenadas para o microcontrolador escravo através de uma interface de comunicação serial para que ele acione os motores de posicionamento do telescópio.

Para a realização de algumas funções o usuário pode selecionar a cidade (de uma lista de cidades pré-armazenadas) ou informar a latitude e a longitude do local da observação. Além de posicionar o telescópio para observação de um astro (através de seu código ou das suas coordenadas), o sistema oferece ao usuário a opção de acompanhar o astro por um longo período de tempo, seguindo o movimento de rotação Terra.

4. Desenvolvimento O projeto do AstroFácil foi realizado utilizando a metodologia de desenvolvimento apresentada por Wayne Wolf (2001), a qual é composta por cinco etapas, sendo elas: análise dos requisitos, especificação, projeto arquitetural, projeto dos componentes e integração do sistema. Essas etapas foram realizadas em uma abordagem top-down, iniciando com a definição dos requisitos do sistema e terminando com detalhes concretos do mesmo.

4.1 Arquitetura do Hardware

A arquitetura de hardware do sistema é representada na estrutura em camadas ilustrada na Figura 3. No manete, o microcontrolador mestre conta com um conjunto de periféricos externos, como um teclado, um LCD (Liquid Cristal Display), um RTC (relógio de tempo real) e chips de memória não volátil do tipo EEPROM (Electrically Erasable Programmable Read-Only Memory). A quantidade de chips de memória é escalável, sendo que o sistema permite por a inclusão de até sete dispositivos, conforme a necessidade. Quanto maior o número de chips, maior é a capacidade da base de dados para registro de coordenadas e outras informações sobre astros.

A comunicação entre os dois microcontroladores é feita usando a interface serial, pela qual o mestre envia ao escravo comandos para o acionamento dos motores-de-passo que movimentam o tubo do telescópio. O microcontrolador escravo atua sobre os motores, utilizando sensores para o controle de posição em malha fechada.

Software

USART Microcontrolador Mestre

Teclado LCD EEPROM RTC

Software

USART

Microcontrolador Escravo

Motores de passo

Manete Circuito de Controle Auxiliar

Figura 3. Arquitetura de hardware do AstroFácil

O modelo de dispositivo escolhido para implementar microcontrolador mestre foi o PIC18F452 da Microchip (2002). A escolha por um microcontrolador PIC se justifica pela disponibilidade de ferramentas de desenvolvimento (montador, compilador, simulador e kits de prototipação) e também pela cultura já estabelecida no uso dessa arquitetura no laboratório de pesquisa deste projeto e no próprio mercado nacional. Já escolha do PIC18F452 para o primeiro protótipo é justificada pela capacidade da suas memórias integradas e pelas características do seu conjunto de instruções, além da freqüência de operação.

Para o microcontrolador escravo, utilizou-se o PIC16F628, também da Microchip (2003). Esse microcontrolador se justifica pelo seu baixo custo e pequena quantidade de pinos. Com relação aos periféricos externos utilizados, a Tabela 1 apresenta suas características e funcionalidades no projeto AstroFácil.

Tabela 1. Características e funcionalidades dos periféricos usados no AstroFácil

Periférico Modelo/Característica Funcionalidade Teclado 14 teclas Interface de entrada do usuário LCD 4 linhas × 16 colunas

padrão HD 44780 Interface de saída visual para o usuário

Motores-de-Passo 2 motores com 1.8º por passo Movimentar o telescópio Memória EEPROM 1 a 7 chips 24LC256 de 32 KBytes

com interface I2C (máx. 256 KBytes) Armazenar informações dos astros e coordenadas geográficas

Relógio de tempo-real PCF8563 Armazenar e atualizar a data/hora

O hardware do AstroFácil foi modelado no ambiente de simulação Proteus/Isis da Labcenter Electronics (2000a, 2000b). Esse modelo foi utilizado, na primeira fase do projeto, para suportar a validação do software durante o seu desenvolvimento. A Figura 4, a seguir, apresenta o diagrama esquemático do sistema, composto pelo manete (circuito em destaque) e pelo circuito de controle auxiliar para acionamento dos motores.

Figura 4. Diagrama esquemático do modelo do sistema embarcado

4.2 Arquitetura de Software O software do AstroFácil foi modelado usando DFDs (Diagramas de Fluxo de Dados). A Figura 5 apresenta o diagrama de contexto do manete, no qual são identificados entidades utilizadas na construção do sistema e os fluxos de dados entre o processo de nível 0 e essas entidades.

InfControle

InfAtualizacao

inf_DataHora

infEstrela

Mensagem

InfTecla0

Astrofacil (Manete)

+

RS 232 PC

RS 232 Circuito de Controle Auxiliar

Teclado

LCD

EEprom Externa

RTC

Figura 5. Diagrama de contexto do software do AstroFácil

A Figura 6 apresenta o DFD de nível 0 do sistema, obtido a partir da explosão do diagrama de contexto mostrado na Figura 5. São ilustrados os principais processos, fluxos de dados e depósitos de dados. A funcionalidade de cada processo é resumida na Tabela 2, logo a seguir.

Figura 6. Diagrama de Fluxo de Dados de nível 0

Tabela 2. Detalhamento dos processos do DFD de nível 0

Processo Descrição 1. Verificar

Comando Aguarda o comando informado pelo usuário e invoca o processo responsável pro executa-lo

2. Obter Dados Obtém do usuário as informações relativas ao local da obsrvação, data, hora, código do astro e/ou coordenadas do astro

3. Calcular Posição do Astro

Calcula a posição do astro para a observação

4. Manipular estrelas

Armazena e Busca informações dos astros na EEPROM

5. Calcular Precessão

Atualiza as coordenadas do astro na data atual

5. Implementação e Validação Física O software do sistema foi codificado em linguagem C, utilizando-se o compilador C para PIC da CCS (2003). O código do microcontrolador mestre consome cerca de 88% da memória de programa do PIC18F452. Já o código do microcontrolador escravo consome cerca de 95% da sua memória de programa.

Para a primeira validação física, o sistema foi montado em protoboard, conforme ilustra a Figura 7. A montagem inclui os circuitos do manete (à direita, em destaque) e do acionamento do telescópio (à esquerda). Essa prototipação permitiu confirmar a correção da integração do sistema e bem como da execução de cada uma de suas funcionalidades, ressaltando-se que o foco desse processo foi na validação do software e da montagem do circuito eletrônico.

Figura 7. Prototipação do sistema em bancada de testes

A validação da correção dos cálculos astronômicos executadas pelo microcontrolador foi realizada com o suporte do software Sky Map Pro 9, desenvolvido por Marriott (2002).

A Figura 8.a apresenta a imagem do primeiro protótipo do manete integrado em uma caixa do tipo “coletor de dados”. Como pode ser observado, o LCD de quatro linhas permite a visualização facilitada de informações, pois é menos restrito que os LCDs de duas linhas tipicamente adotados nos manetes importados. O teclado é do tipo matriz e algumas de suas teclas permitem a entrada de números e de caracteres do alfabeto (para a entrada do nome de um astro), da mesma forma que em um teclado de telefone. Quatro teclas servem também para indicação de direção. Uma característica importante do manete AstroFácil é que os menus são disponibilizados em português, o que torna a sua operação ainda mais facilitada a astrônomos amadores sem o domínio do inglês, idioma tipicamente adotado nos manetes importados.

MANETE

Figura 8. AstroFácil: (a) Protótipo do manete; (b) telescópio Orion EQ3 com

montagem equatorial a ser utilizado nos testes de campo

O protótipo do manete mostrado na Figura 8.a e o circuito de controle auxiliar já foram integrados ao telescópio para os primeiros testes de operação. Ainda não foram realizados os experimentos necessários à validação completa do sistema, o que será feito na próxima etapa do projeto.

6. Análise Comparativa O manete AstroFácil apresenta funcionalidades similares às dos modelos comerciais importados disponíveis no mercado, conforme o quadro comparativo da Tabela 3. Além disso, ele foi projetado para ser utilizado com telescópios de baixo custo para os quais esse tipo de manete não é usualmente disponibilizado. Por exemplo, o Meade #497 Autostar é direcionado a telescópios de nível intermediário com preço médio acima de R$ 4.000,00. Por exemplo, o preço do telescópio ETX-90PE da Meade, incluindo a montagem e o Autostar, é igual a R$ 4.600,00, sendo este o modelo automatizado de menor custo em um distribuidor nacional [Omnis Lux, 2006]. Uma vantagem evidente do AstroFácil em relação aos modelos importados está na flexibilidade e na possibilidade de expansão da sua funcionalidade e da sua capacidade. Com o conhecimento estabelecido a respeito da tecnologia e da área de aplicação, é possível desenvolver novas soluções que atendam a necessidades ainda não identificadas neste projeto.

Tabela 3. Comparativo de características: Autostar x AstroFácil

Características Meade #497 Autostar AstroFácil Preço R$ 690,00(1) R$ 350,00(2)

Idioma dos menus Inglês Português

Localização automática do objeto alvo SIM SIM

Acompanhamento automático SIM SIM

Display orientado a caracteres 2×16 4×16

Microcontroladores Atmel 89C451 PIC 16C57

PIC18F452 PIC16F628

(1) Preço no Brasil [Omnis Lux, 2006]. (2) Preço máximo estimado para comercialização, incluindo o manete, o circuito de controle auxiliar, motores,

cabos e manuais.

Com relação ao impacto regional deste projeto, devem ser destacados dois aspectos. Primeiramente, o trabalho está sendo desenvolvido em uma parceria entre uma universidade e uma empresa sediados na mesma cidade, o que fortalece o desenvolvimento da sua região. Em segundo lugar, a experiência na execução deste projeto, envolvendo alunos de graduação, tem propiciado a capacitação de recursos humanos qualificados na área de concepção de sistemas embarcados. Recursos este que poderão ingressar no mercado de trabalho regional com um diferencial em sua formação acadêmica.

7. Considerações Finais Este artigo apresentou o desenvolvimento de um sistema computacional embarcado, baseado em microcontrolador, para operação automática de telescópios de pequeno porte, visando, principalmente, facilitar a observação astronômica por astrônomos amadores. Foi apresentada a descrição da arquitetura de hardware e de software do sistema e informações sobre a implementação do seu protótipo.

Entre os trabalhos futuros, prevê-se a integração do manete com um sistema para acesso remoto ao telescópio via WWW, já desenvolvido em um trabalho de conclusão de graduação. Essa solução permitirá, por exemplo, que uma escola disponibilize um observatório de pequeno porte e de baixo custo a seus alunos para que eles possam realizar observações astronômica de suas próprias residências, ampliando, ainda mais, o acesso a esse tipo de infra-estrutura.

Agradecimentos Este trabalho foi apoiado pelo CNPq – Edital 14/2004 (Fomento Tecnológico) e conta com infra-estrutura prévia fomentada pela Petrobrás.

Referências Boczko, R. (1984) “Conceitos de Astronomia”, 2. ed. São Paulo, Edgard Blücher, 1984.

CARA (2002) “Center for Astrophysical Resourse in Antarctica”, Disponível em: <http://astro.uchicago.edu/cara/>. Acesso em: 02 de abril de 2006.

CCS (2003) “C Compiler Reference Manual”, July.

Gemini, Observatory (2006) “About The Gemini Observatory: exploring the universe from both hemispheres”. Disponível em: <http://www.gemini.edu/index.php? option=content&task=view&id=9&Itemid=2>. Acesso em: 02 de abril de 2006.

Labcenter Electronics (2000a) “Proteus VSM Virtual System Modelling - User Manual”, June.

Labcenter Electronics (2000b) “ISIS Intelligent Schematic Input System - User Manual”, June.

Marriot, C.(2002) “Sky Map Pro 9: tutorial”. Disponível em: <www.ttp.co.uk/smp9_tut.pdf>. Acesso em: 02 de abril de 2006.

Meade Instruments Corporation (2006) “Meade Autostars”. Disponível em: <http://www.meade.com/autostar/autostars.html>. Acesso em: 02 de abril de 2006.

Meeus, J. (1998) “Astronomical Algorithms”. 2. ed. Virginia: William-Bell.

Microchip (2002) “PIC 18F452: Data sheet”, Chandler, Microchip.

Microchip (2003) “PIC 16F628: Data sheet”, Chandler, Microchip.

Observatórios Virtuais (2005) “Observatórios Virtuais:”. Disponível em: <http://www.observatoriovirtual.pro.br>. Acesso em: 02 de abril de 2006.

Omnis Lux (2006) “Omnis Lux: astronomia e projetos culturais”. Disponível em: <http://www.omnislux.com.br>. Acesso em: 02 de abril de 2006.

Silva, M. R. (2003) “Instrumentalização Robótica de Telescópio” Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Universidade do Vale do Itajaí, Itajaí.

Sky-Watcher (2006) “SkyScan Kit (EQ6)”. Disponível em: <http://www.sherwoods-photo.com/sky_watcher/skywatcher_mounts_motors.htm >. Acesso em: 02 de abril de 2006.

Werneck, L. S., Nader, R. V. e Campos, J. A. S. (2004) “O Telescópio Remoto do Observatório do Valongo”, In: Boletim da Sociedade Astronômica Brasileira, Rio de Janeiro, UFRJ, 2004. p. 189-189.

Wolf, W. (2001) “Computer as Components: Principles of Embedded Computing System Design”, Morgan Kaufmann Publishers. 2001.

Zeferino, C. A. et al. (2005) “A Web-based system for management of the access to an astronomical observatory through Internet. In: 4th International Information and Telecomunication Technologies Symposium (I2TS 2005), Florianópolis. p. 130-133.

Aplicativo Controlador de Potência de Pseudo-Satélite e SuasAplicações

Luiz Eduardo Guarino deVasconcelos1, Durval Zandonadi Jr. 2, FernandoWalter2, Jorge Tadano1

1Tecnologia da Informação – Grupo Especial de Ensaios em Vôo (GEEV-CTA)São José dos Campos – SP - Brasil

2 Departamento de Telecomunicações – Instituto Tecnológico de Aeronáutica (ITA-CTA) – São José dos Campos – SP – Brasil

{du@2guarinos.com, durval@ita.br, fw@ita.br, jorge.dworks@uol.com.br}

Resumo. Este artigo mostra as informações técnicas de suporte à interface

dos ensaios realizados em um protótipo de Pseudo-Satélite (PS). O PS

desenvolvido, no ITA, foi concebido para aplicações aeronáuticas, mas seu

emprego em Agricultura de Precisão (AP) é imediato. Juntamente com o PS

foi desenvolvido um aplicativo, pela Seção de TI do GEEV, dedicado para

controle automático de potência do PS que adquire dados de receptores GPS

e provê feedback para um usuário através de uma interface RS-232.

Resultados dos testes aeronáuticos realizados e o desenvolvimento do

aplicativo controlador de potência do PS são apresentados.

1. IntroduçãoO Pseudo-Satélite (PS) é um transmissor de sinais GPS, localizado próximo ao solo, emposição previamente conhecida. Ele transmite seus sinais a usuários participantes de umsistema de acréscimo baseado em solo conhecido como GBAS (Ground Based

Augmentation System).

A utilização de PS constitui-se numa fonte adicional dos sinais de navegaçãopara os usuários. As informações enviadas pelos PS juntam-se às enviadas pelossatélites visíveis ao receptor GPS do usuário. Esta fonte aumenta a confiabilidade, aintegridade e a exatidão da solução de navegação [Kayton, M.; Fried, W. R.1997 eParkinson, B. W.; Spilker Jr., J. J. 1996] , podendo ser utilizado nas seguintes situações:

• Tratores-robôs• Labirintos em plantações de milho• Pousos e decolagens automáticos

A melhora de exatidão das medidas de posição, de velocidade e de tempo (PVT)obtidas com o emprego de PS em sistemas aeronáuticos, permitirão o desenvolvimentode sistemas de pouso e decolagem automáticos (ATC) na categoria III, especialmente naIII-C [FAA 1984]. Concebido para aplicações aeronáuticas, seu emprego emAgricultura de Precisão (AP) é imediato.

Graças ao GPS, mais especificamente, ao CDGPS (Carrier Differential-PhaseGPS, técnica de obtenção de posicionamento de melhor acurácia possível com o GPS),acrescido de PSs que propiciam rápida inicialização de algoritmos CDGPS, permitiu-seautomatizar a guiagem de um trator e arar um campo sob condições adversas e em

quaisquer padrões. Conseguem-se acurácias de centímetros empregando-se PS +CDGPS.

Outra técnica também utilizada é o emprego de uma estação de referência GPS,capaz de computar e enviar correções diferenciais ao(s) receptor(es) instalado(s) notrator. A acurácia neste caso é um pouco menor (decímetros). Um PS pode tambémtransmitir as correções diferenciais da estação de referência.

2. Conceitos

2.1. Aplicações em AP

A potencialidade e exatidão que se consegue mediante GPS só pode ser aproveitadapelo agricultor se o trator se tornar robotizado, ou seja, se houver um sistemacomputadorizado integrado capaz de comandar os movimentos da máquina, orientadospor GPS. É o que se pode chamar de “tratores-robôs”. Um fabricante líder de tratoresnos Estados Unidos da América, na década de 90, fez contrato com a Universidade deStanford para pesquisar e desenvolver um sistema de controle e guiagem baseados emtecnologia CDGPS [Cobb, H. S. 1997]. Para se inicializar parâmetros de ambigüidadesrelativos à fase da portadora (carrier phase), o trator precisa transitar próximo a umpseudo-satélite montado nas proximidades. Na maioria dos casos se requer apenas umPS, uma vez que devem ser computadas apenas duas dimensões da posição. A Figura 1mostra foto do trator-robô. Antenas GPS encontram-se sobre a cabine.

Figura 1. Trator-robô sendo comandado por computadores e atuadoresinterligados, orientados por CDGPS.

Até pouco tempo era extremamente difícil arar uma grande superfície segundoum padrão (desenho) de maior interesse do agricultor, com precisão adequada e quepudesse ser retraçada com facilidade. Dificuldades de visualização e guiagem devidas afatores como nuvem de poeira, escuridão e mau tempo, também puderam ser superadasgraças aos tratores-robôs. As Figuras 2 e 3 mostram como se pode arar um solo.Primeiramente, devem-se determinar as coordenadas extremas da superfície a sertrabalhada, realizando-se um geo-referenciamento.

Figura 2. Foto da tela decomputador do trator-robô.

Numa primeira fase umperfil a ser traçado é

programado no sistema.

Figura 3.�Foto aérea doterreno arado segundo o

exemplo didático de perfilprogramado (letra “S”).

Figura 4.�Exemplo de perfilde aração circular

contínuo onde seráempregado um pivô de

irrigação. Observe que otraçado é contínuo.

Quaisquer traçados que se queiram executar no solo podem, potencialmente, serprogramados. Um perfil muito útil é o que mostra a Figura 4. Trata-se de uma área deplantio onde será empregado um pivô de irrigação ao centro com a plataforma sedeslocando circularmente por entre a plantação. Com o emprego de trator-robô épossível arar os sulcos com precisão, bem como lançar adubos, sementes, defensivosagrícolas em diferentes épocas sem agredir a plantação. Até mesmo as extremidades dasalças concêntricas podem receber concordâncias precisas e de forma contínua.

A aplicação seguinte encontra-se descrita na referência [Boynton, F. 2002].Trata-se do uso do GPS diferencial (DGPS) na criação de labirintos em plantações demilho (corn mazes). Embora labirintos em milharais não sejam novidade, suasimplementações até então eram feitas à moda antiga, mediante desenhos em escala e deforma, por assim dizer, artesanal. As áreas dos labirintos eram relativamente pequenas eos desenhos, em sua maioria, feitos segundo formas retilíneas. Com o auxílio do GPS ede programas que auxiliam no desenho, formas complexas e de grandes dimensõespodem ser realizadas com facilidade e precisão. A Figura 5 mostra um exemplo delabirinto criado num milharal na cidade de Lawrenceburg no Tennessee – EUA, safra2001.

Figura 5.�Exemplo de labirinto realizado em plantação de milho – safra de 2001,Tennessee, EUA. Notar, para noção de escala, um caminhão na parte superior

direita.

2.2. Caracterização do problema “NEAR/FAR”

O nível de potência transmitida por um PS é um quesito crítico, sendo um dos maisimportantes, senão o mais importante a ser considerado no projeto [4]. Há um impasseclássico conhecido como problema “near/far”. Quando o receptor se encontra longe doPS, a potência transmitida deverá ser suficiente para assegurar a recepção regular dosinal. Por outro lado, quando o receptor estiver próximo ao PS, nenhuma saturação ouofuscamento dos sinais dos satélites GPS deverá ocorrer, caso estes quesitos não secumpram, caracteriza-se o problema “near/far”.

Algumas estratégias de mitigação são conhecidas desde de 1994 [Klein, D.;Parkinson, B. W.1984] e várias têm sido as técnicas propostas e empregadas desdeentão para contornar esse problema. Quaisquer que sejam essas estratégias há sempreaspectos positivos e negativos quanto a sua utilização, envolvendo, por exemplo, anecessidade de se implementar grandes alterações nos receptores GPS.

2.3. Técnica “Realimentação do Usuário”

Uma nova estratégia para se contornar o problema near/far, denominada de“Realimentação do Usuário” (RU - User Feedback), foi proposta juntamente com odesenvolvimento do projeto do PS do ITA (Figura 6).

Entende-se por faixa dinâmica de um receptor a relação entre os níveis depotência de sinal recebido mais forte e mais fraco que permitam a demodulação semdistorção e ruídos excessivos. O problema near/far decorre precisamente da limitaçãodesta faixa nos receptores GPS. Este problema é inerente à rádio-difusão em geral. ARU consiste em dosar dinamicamente a potência transmitida pelo PS de modo que osinal recebido se encontre sempre dentro da faixa dinâmica do receptor. A informaçãodo nível de potência do sinal recebido deverá ser realimentada ao PS para que sejacontrolada a potência transmitida, a qual depende da distância em que o usuário seencontra.

Figura 6. Foto do protótipodo Pseudo-Satélite GPS em

desenvolvimento no ITA

Figura 7. Malha básica de controle envolvendo pseudo-satélite e controlador de potência transmitida.

O desenvolvimento do aplicativo de controle da potência transmitida pelo PS foifeito de forma a assegurar que a potência recebida num receptor GPS tenda à potênciade referência (PREF) imposta pelo operador do PS. Este patamar poderá ser modificadodinamicamente pelo operador.

O controlador de potência precisa conhecer qual a intensidade da potênciarecebida pelo receptor do usuário (PREC), expressa em termos da relação C/N0 emdB⋅Hz, referente aos sinais dos satélites e sobretudo ao PS. Estão implícitos nestarelação efeitos de ganhos e descasamento de polarização das antenas, obstruções desinal e perturbações no receptor. Em outras palavras, o parâmetro C/N0 reporta efeitos eperturbações tanto do canal de transmissão como da própria recepção. A correta atuaçãodo controlador deve ocorrer mesmo existindo perturbações no canal de transmissão e narecepção, mesmo que este canal seja variante no tempo.

Para se atender aos requisitos, foi elaborado um controlador implementado naforma de aplicativo dedicado, especialmente desenvolvido para esta finalidade, a serexecutado num microcomputador PC. O PS dispõe de uma porta de comunicação serialpor onde o microcomputador PC envia comandos de potência oriundos do programacontrolador de potência. A Figura 7 ilustra a malha de controle proposta.

3. Desenvolvimento do software

3.1. O Controlador de potência

O aplicativo denominado UF (“User Feedback”) foi desenvolvido pela Seção deTecnologia da Informação (TI) do Grupo Especial de Ensaios em Vôo (GEEV) doComando-Geral de Tecnologia Aeroespacial (CTA), para auxiliar na solução doproblema near/far. Este aplicativo tem, basicamente, o objetivo de adquirir os dados doreceptor GPS, aplicar as estratégias de controle de potência e realimentar o PS,possibilitando o controle automático da potência. Este controle é realizado através deinterfaces RS-232 que realizam a comunicação com o receptor GPS e com o PS.

3.2. Funcionamento do UF

O aplicativo deve iniciar variáveis relativas à potência de referência (PREF) e àpotência inicialmente transmitida (PT). Esta última é mapeada indiretamente em termosda palavra digital de controle de potência denominada de Word_Power (WP) relativa aoconversor D/A. O controlador recebe informações realimentadas do receptor GPS,dentre as quais está a potência recebida do PS (PREC). Ele realiza comparação entre osvalores PREC e PREF e em função do resultado obtido (menor, igual ou maior) calculao novo valor ideal de potência transmitida (PT) e o traduz em novo valor de WP a serprogramado no conversor D/A. Este valor é transmitido através da interface RS-232 aoPS, reajustando-se assim o conversor D/A. Por fim, um arquivo que contém asinformações relativas ao processo é gerado (LOG), atualizado e armazenado.

3.3. Estratégias de recuperação de potência

Estratégias foram implementadas com a finalidade de auxiliar a recaptura do sinalperdido pelo receptor GPS, ocasião esta em que não há realimentação de nível depotência recebida pelo receptor. Assim sendo, o controlador fica inoperante, e nestecaso, a principal estratégia empregada, consiste na imposição de um nível de potênciatransmitida após a perda do sinal, cujo valor é baseado na potência média aplicadamomentos antes da perda de sinal, quando o controle estava operacionalmenteconfiável.

3.4. Limitação de satélites

Em razão da limitação da banda do rádio-modem, o número de satélites observados peloreceptor GPS é limitado em função da taxa de aquisição dos dados.

3.5. LOG

O arquivo de armazenamento de dados, denominado “LOG”, tem por finalidaderegistrar as informações mais importantes durante os ensaios com o PS. Sua análise pós-ensaio permite a avaliação do desempenho do PS, do rádio-modem, do controlador edos satélites recebidos. O arquivo “LOG” contém os resultados dos ensaios, permitindoassim a avaliação quantitativa do desempenho deste sistema.

3.6. Aplicação de CheckSum

Para se verificar a consistência da transmissão de dados, foi utilizado o algoritmo deChecksum. Neste caso o transmissor adiciona, normalmente ao final do pacote a sertransmitido, um ou mais bits que fazem parte do checksum. As mensagens NMEA,retornadas pelo receptor, incorporam dois bytes de checksum, que transportaminformações à cerca dos dados precedentes. A conferência destes bytes com o restantedo pacote devidamente processado pode dar uma indicação, com alto grau de confiança,de que não houve erros na recepção dos bits. Por outro lado, a detecção de erro nopacote pode permitir seu descarte, realizando um controle mais confiável. Aplicamoseste algoritmo de verificação para garantir a qualidade e confiabilidade das informaçõestransmitidas pelo receptor GPS.

3.7. Inserção de ruído manual

Durante a fase de desenvolvimento do aplicativo, para simular o comportamento de umreceptor móvel que seja representativo de um cenário aeronáutico, foi feita a adição deum ruído aleatório no nível de sinal recebido. Para isso foi escolhida a função dedensidade de probabilidade adaptada de uma função “Cauchy”, a qual pode serfacilmente implementada e conformada, possibilitando a ocorrência de diversos níveis.Esta estratégia permitiu estimular e excitar o programa controlador, simulando umcenário realístico.

4. Equipamentos Utilizados

4.1. Microcomputador

O programa controlador do PS foi instalado em um microcomputador PC Athlon 2800+com 1 GB de memória RAM, 120 GB de HD SATA, monitor de 17” tela plana, placa-mãe Soyo Dragon Plus com chipset KT-600, placa de vídeo Nvidia 5200 com 128 MBde RAM. O sistema operacional utilizado foi o Windows XP Professional. Neste PCforam instaladas 2 portas seriais adicionais, uma para o controle do PS e outra para ocontrole do receptor GPS. As configurações das portas seriais estão na Tabela 1.

4.2. Microcomputador Portátil

Os ensaios com o computador a bordo da aeronave empregaram o programa controladorde potência instalado em um Laptop Dell Inspiron 7500, de configuração bem maismodesta que o de mesa descrito anteriormente. Trata-se de um processador IntelPentium III de 600 MHz, com 256 MB de RAM. Foi necessário utilizar um conversorde USB para serial, disponibilizando assim duas interfaces RS-232 requeridas pelosistema de controle, conforme configuração descrita na Tabela 1.

Tabela 1. Configuração da porta serial do Receptor GPS e do PS

Equipamento Porta Taxa(bps)

Bit de paridade Bits de dados Stop-bit

Receptor GPS COM1 38400 Nenhum 8 1PS COM2 9600 Nenhum 8 1

4.3. Receptores GPS

Em geral, qualquer modelo de receptor GPS poderia ser utilizado. Os requisitosmínimos são: possuir uma interface serial RS-232 para comunicação de dados e permitiro envio de mensagens do protocolo NMEA, informando, sobretudo o nível de sinalrecebido. Nesta aplicação, em função da disponibilidade para testes e desenvolvimentodo aplicativo, foram utilizados os receptores Ashtech Z-12 (Figura 8) e Z-FX (Figura 9)que são de propriedade da AEV. Estes receptores possuem 12 canais. Considerando quenuma aplicação típica são rastreados até 11 satélites GPS [Parkinson, B. W.; Spilker Jr.,J. J. 1996], estes receptores são perfeitamente adequados para a utilização com um PS.Dentre os dois receptores, o Ashtech Z-FX é o melhor por apresentar melhorescaracterísticas gerais, maior taxa de aquisição de dados (até 10/s) e maior faixadinâmica.

Figura 8. Receptor Ashtech Z-12 Figura 9. Receptor Ashtech Z-FX

4.4. Rádio - Modem

O emprego do rádio-modem é fazer chegar dados seriais do receptor até o PS e,adicionalmente, fazer chegar comandos do PS até o receptor GPS. A escolha do rádio-modem XSTREAM-PKG X09-009PKC-R foi por conveniência e disponibilidade, umavez que a Divisão de Sistemas Bélicos (ASB) possui um par. Em função da falta dedocumentação técnica, pouco se sabe sobre os algoritmos internos dos rádios-modem.Desta forma, as características técnicas deste equipamento foram obtidasexperimentalme����� ��� ���� �� ��� �� ���� ������ ����� ��� ��� �� ��� ���� �� ������começa a ser enviado pelo canal; o tempo ���������������� ����������� ��������quando o pacote termina de ser recebido; e o número de blocos corresponde ao númerode partições que o equipamento impõe para permitir o tráfego duplex pelo mesmo canalde RF. Desta forma, pode-se perceber que nenhum byte chega do outro lado antes de 47ms e acima de 70 bytes o pacote é dividido em blocos de 64 bytes.

5. Protocolo de Comunicação

5.1. Algumas instruções utilizadas

As principais mensagens NMEA recebidas pelo controlador dos receptores GPS foram:GSN e POS. A mensagem GSN devolve as informações referentes à intensidade desinal recebido de cada satélite. A mensagem POS fornece diversas informaçõesreferentes à posição da antena do receptor.

5.2. Detalhes do Protocolo de Comunicação

A comunicação entre o Microcomputador PC e o PS foi feita por meio de interfaceserial assíncrona, saindo informações do PC via RS-232 padrão. Para isso bastam trêslinhas para que se estabeleça esta comunicação, quais sejam: TX, RX e GND. Estando oPS fisicamente localizado sobre a torre adjacente ao prédio X-30 (hangar), ocomprimento do cabo de comunicação serial excedeu o máximo suportado pelo padrãonão balanceado RS-232. Sendo assim, o PS dispõe de duas interfaces de comunicaçãoserial, sendo uma RS-232 e uma RS-422. Um adaptador especial foi colocado logo nasaída RS-232 do PC, convertendo este padrão no padrão balanceado RS-422. O númerode bytes por pacote é igual a três. Uma seqüência como esta é enviada ao PS de 1/s a10/s, qual seja a taxa de saída de dados do receptor GPS à estação de telemetria. AFigura 10 mostra um exemplo da referida seqüência. Os oito bits de dados estãorepresentados por traços ao centro do trem de pulsos, estando 4 deles ao final dosegundo byte e os outros 4 no começo do terceiro byte. Note que o MSB está nosegundo byte. Esta formatação se deve ao emprego de um Conversor Digital/Analógicoserial no PS que exige uma seqüência derivada da mostrada.

MSB LSBFigura 10. Seqüência de bits a ser enviada pelo PC ao PS mediante interface decomunicação serial RS�232. A palavra de potência (os oito bits reservados emvermelho) são os únicos que sofrem mudança dentro da seqüência mostrada.

A duração dos trinta bits consecutivos a 9600 bps é de 3,125 ms.

O primeiro byte corresponde à seqüência binária 11101011 (D7H ou ASCII x ouÎ conforme a tabela ASCII, LSB primeiro). Esta é uma palavra de comando programadaque informa ao PS que a presente comunicação corresponde de fato a uma ordem deatualização da potência transmitida, devendo, portanto, ser obedecida pelo PS. Outrasseqüências com outros preâmbulos são ignoradas.

6. Interface com o operadorO programa controlador apresenta diferentes telas por onde o operador pode interagir. Aprimeira tela permite a configuração das portas de comunicação seriais do receptor GPSe do PS. Os valores de configuração padrão são apresentados na Tabela 1. Além disto,pode-se também configurar o código PRN empregado pelo PS (e.g., PRN #32) e ascoordenadas da antena transmissora no formato latitude, longitude e altitude.

Pode-se optar pelo emprego do receptor Ashtech Z-FX ou Z12, nos modos“Solo” ou “Embarcado”. A modalidade embarcada foi empregada durante as fases dedesenvolvimento, onde o programa foi instalado em um computador tipo Laptop queficaria dentro da aeronave, junto ao receptor. Nesta configuração o rádio-modem enviaao PS os comandos de atualização de potência, uma vez que toda a informação doreceptor é passada diretamente ao controlador através da porta serial RS-232.

Alguns dos recursos e informações disponíveis ao operador são: armazenamentodas informações em arquivo (LOG); iniciar e parar a aquisição de dados; definição dataxa de aquisição do receptor; re-início do receptor GPS; armazenamento dasconfigurações atuais ao receptor GPS; visualização e controle do nível de potência doPS a ser comandado; visualização e controle da WP e das estratégias de controleimplementadas no aplicativo; seleção de satélites para os canais do receptor;visualização da distância e altura do equipamento embarcado; visualização gráfica emtempo-real dos satélites selecionados, do PS, da potência recebida ou da distânciapercorrida e trajetória.

6.1. Telas gráficas para monitoração do controlador

O programa controlador dispõe de 4 telas gráficas atualizadas sob a mesma taxa deaquisição do receptor GPS. A primeira tela, intitulada “Satélites”, possui no eixo dasabscissas o número dos PRN’s associados aos satélites (i.e., 1 a 32) e no eixo dasordenadas o valor do índice C/N0 em dB⋅Hz dos satélites capturados. A presença desatélites em vista é mostrada através dos respectivos pontos verdes, (figura 11). O pontovermelho corresponde ao PS (i.e., PRN#32). A cor de fundo do gráfico indica de formarápida e visual o estado do controlador.

A segunda tela (figura 12), intitulada “Pseudo-Satélite”, apresenta as 20 últimasamostras do C/N0 (dB⋅Hz) do PS. Além disto é possível visualizar simultaneamente aWP neste gráfico, desde que o limite superior da escala do eixo y seja adequadamenteaumentado. Desta forma torna-se tangível a visualização da atuação do controle. Poroutro lado, a presença de congelamentos ou perda de captura do sinal do PS ficafacilmente caracterizada nesta tela, na qual o traço superior, em verde, corresponde àWP e o inferior, em vermelho, ao índice C/N0.

terceira tela, intitulada “Pot. Recebida”, corresponde à variação da potênciarecebida em relação à potência de referência (PREF), em dB⋅Hz. Esta tela permiteacompanhar quão fora está a potência recebida do valor ideal almejado (figura 13).

Figura 11. Telaindicativa dos

satélites em vista comrespectivos índices

C/N0.

Figura 12. Tela indicativade captura do pseudo-satélite versus últimas

20 amostras.

Figura 13. Telaindicativa de variaçãoda potência recebida

em dB�Hz em relação aPREF versus últimas 20

amostras, relativa aosinal do PS.

Figura 14. Tela comrepresentação

bidimensional decoordenadas ENU.

A quarta tela, intitulada “Distância” (figura 14), corresponde à representaçãobidimensional da posição do receptor no sistema de coordenada Leste-Norte-Acima(ENU) [Chatfield, Averil B. 1997]. A origem corresponde ao centro de fase da antenatransmissora. O traço no sentido noroeste-sudeste corresponde à pista do aeroporto deSão José dos Campos (SBSJ), cujas extremidades correspondem às cabeceiras “15” e“33” respectivamente. As distâncias estão em km. Quando em operação, a posição dousuário é mostrada no gráfico em forma de um pequeno ponto que se movimenta,podendo deixar, caso habilitado, o rastro que indica a trajetória recente da aeronave. Ascomponentes da distância em relação à origem são mostradas em campos específicos,bem como a distância radial, em metros.

7. EnsaiosOs ensaios ocorreram juntamente às instalações da AEV, utilizando o helicóptero CH-55 e adjacências da pista do aeroporto de São José dos Campos. A primeira fase dosensaios utilizou o enlace mostrado na Figura 7 com o receptor GPS e um rádio-modem,embarcados num carro, percorrendo parte da cidade de São José dos Campos e do CTA,a fim de aferir e desenvolver o aplicativo controlador. Na segunda fase dos ensaiosforam previstos 5 vôos de ensaios em dois dias, mas apenas 4 foram executados. Noquinto vôo a aeronave deveria se aproximar da base de testes, porém, por motivosoperacionais e de segurança, este vôo não pode ser realizado. Nos demais ensaios(vôos), foram utilizados os receptores Ashtech Z-12 e Z-FX, e cada vôo teve, em média,a duração de 40 minutos, que foram fundamentais para a definição da relação near/far.

Na realização dos vôos, ocorreram dois tipos de falhas que se destacaram,prejudicando os resultados gerais dos ensaios. A primeira delas (mais grave) diz

respeito ao mau funcionamento do rádio-modem instalado no helicóptero e a segunda éem relação às falhas operacionais, sobretudo pelo fator humano. As falhas operacionaisforam mais pronunciadas nos vôos #3 e #4, onde o sincronismo entre as equipes de soloe de ar era mais necessário. As conclusões foram tomadas diante das informaçõesarmazenadas no arquivo LOG.

Figura 15. Projeção bidimensional do trajetoa ser seguido do vôo #4.

Figura 16. Projeção bidimensional do trajetopercorrido do vôo #4, com informações

capturadas pelo aplicativo.

8. ConclusõesConsiderando a complexidade dos ensaios realizados, nossa avaliação, como esperada,foi muito positiva. Conseguiu-se receber um sinal GPS transmitido por um PS, desdemenos de 20 metros até cerca de 40 km, perfazendo uma relação near/far superior a1:2000. Obviamente há que se considerar o problema de interferências com não-participantes. A recepção do PS por uma antena apontada para cima também foi muitoimportante no resultado. Trata-se de um cenário bastante desfavorável, onde a variaçãode ganho com a elevação sofre muita modificação. Graças à técnica RU e às estratégiasde recuperação e controle implantadas no aplicativo UF, isto foi especialmente possívelem tão ampla gama de distâncias e de dinâmicas de aeronaves.

Como todo aplicativo, este programa pode e deve ser aperfeiçoado, mediantesintonias finas em seus algoritmos e coeficientes, otimizações diversas em sua estruturae aspectos de apresentação. Entende-se, entretanto, que da forma em que está, permite aoperação em parceria com o PS desenvolvido e com os receptores GPS empregados,atendendo aos objetivos de coadjuvante a que foi proposto.

O PS desenvolvido no ITA, inicialmente concebido para aplicaçõesaeronáuticas, pode facilmente se adequar a aplicações em AP. Descreveu-se, em linhasgerais, o programa controlador de potência elaborado com a finalidade de atender àproposta de RU.

ReferênciasBoynton, F. (2002); GPS Corn Maze, A New Satellite Navigation Application in

Proceedings of the ION Global Positioning System GPS-2002, September 24-27,2002, Portland, Oregon, USA.

Chatfield, Averil B. (1997), Fundamentals of High Accuracy Inertial Navigation, Vol.174, American Institute of Aeronautics and Astronautics.

Cobb, H. S. (1997): GPS Pseudolites: Theory, Design, and Applications, Ph.D.dissertation, Dept. of Aeronautics and Astronautics, Stanford University, California,USA.

FAA (1984), Criteria for Approval of Category III Landing Weather Minima (AC-120-

28C). U.S. Government Printing Office, Washington, DC.

Kayton, M.; Fried, W. R.(1997): Avionics Navigation Systems, 2nd Ed., New York:John Wiley & Sons.

Klein, D.; Parkinson, B. W.(1984): The Use of Pseudo-Satellites for Improving GPS

Performance, in the Global Positioning System, Vol. 3, Institute of Navigation,Washington, DC, USA.

Parkinson, B. W.; Spilker Jr., J. J.(1996): Global Positioning System: Theory and

Applications Progress in Aeronautics and Astronautics Vol. 163, AIAA.

Desempenho de Multicast em redes altamente

interconectadas

Fernando Teubl Ferreira1, Sergio Takeo Kofuji1

1PAD-LSI, Escola Politécnica da USP – Universidade de São Paulo

São Paulo – SP – Brasil

{ftf, kofuji}@lsi.usp.br

Resumo. A utilização de redes Multicast proporciona uma significativa

diminuição de banda em aplicações que exigem que a mesma informação seja

distribuída para múltiplos usuários. Destarte, a utilização de redes multicast

vem sendo estendida para muitos outros cenários, como por exemplo, redes

ad-hoc. Ambientes que permitem diversas interconexões entre agentes, no

entanto, podem tornar o Multicast menos eficiente, e em certos casos o

desempenho do Multicast pode ser até inferior ao do Unicast. Este artigo

contrasta esta diferença, demonstrando por simulações a relação entre

topologias altamente interconectadas com o desempenho Multicast e Unicast

1. Introdução

O aumento de aplicações multimídia, tais como áudio, vídeo conferência e webTV, levou

a um significativo aumento da transmissão de dados sobre a Internet. Aplicativos

multimídia têm como característica a necessidade de uma grande banda, e geralmente

estes dados são simplesmente replicados para diversos usuários de interesse, causando

uma redundância no uso da rede.

O protocolo Multicast diferencia-se do Unicast por possibilitar o envio de

informações idênticas para um grupo de usuários, sem haver a necessidade de replicar

individualmente as informações endereçadas para cada um. Isto reduz a banda necessária

no servidor, e supõe-se habitualmente que o uso de Multicast é consideravelmente mais

eficiente do que Unicast.

Em topologias tradicionais (árvore, anel e estrela), o desempenho da utilização de

redes Multicast se mostra, em geral, superior ao equivalente grupo de conexões

individuais Unicast, uma vez que se espera, no caso ideal, que a rede Unicast tenha o

crescimento de banda em relação ao número de usuários comportando-se como O(n),

enquanto o Multicast teria O(1). Considerando aplicações como, por exemplo, WebTV,

no qual pode atingir milhares de usuários, as vantagens do Multicast muitas vezes não só

melhora drasticamente o desempenho mas também pode viabiliza a sua utilização.

Em alguns cenários, as topologias empregadas podem variar drasticamente dos

modelos tradicionais. Um exemplo é o uso de redes sem fio (Wireless) do tipo ad-hoc,

ou uma rede de sensores (sensor network). Este tipo de redes possibilita o

estabelecimento de conexões entre os agentes dinamicamente, e a quantidade de

conexões entre agentes pode ser variável e configurável conforme demanda,

necessidades e capacidades.

Este artigo explora redes altamente interconectadas e estáticas, apresentando

uma relação entre a quantidade de nós, número de usuários e número de conexões – ou

distância média entre nós –, com o desempenho do aplicativo.

2. Revisão bibliográfica

A busca de melhor desempenho em transmissão de vídeo em tempo real utilizando redes

Multicast ou Unicast em redes sem fio ad hoc tem sido o foco de diversas pesquisas

[Wei e Zakhor 2004b]. O desafio de reduzir a quantidade de informação necessária para

a transmissão de dados e controle para um determinado grupo de usuários tem

promovido o uso de redes Unicast, uso de redes Multicast, e até mesmo soluções

híbridas [Majumdar et al. 2002].

Redes ad hoc, devido à alta mobilidade dos agentes durante a transmissão de

dados, geralmente são propícias a ter conexões instáveis, ocasionando súbitas

interrupções ou corrompimento de dados em determinado segmento da rede no qual um

agente qualquer se desloca ou desconecta. Este fato pode proporcionar quebras de

conexões, forçando um restabelecimento de rotas alternativas, caso possível, para

garantir a continuidade da entrega dos pacotes para todos os usuários pertencentes a um

determinado grupo Multicast.

Algumas propostas têm sido levantadas para contornar a falta de confiabilidade

destes cenários supra-expostos. Uma das técnicas é a realização de múltiplos caminhos

Multicast entre o servidor e os seus clientes, utilizando múltiplas conectividades e

múltiplas rotas [Wei e Zakhor 2004a; Rajendran et al. 2004; Viswanath, e Obraczka

2005; Viswanath, Obraczka e Tsudik 2004].

Estudos comparativos entre redes Multicast e Unicast [Legout, Nonnenmacher,

e Biersack 2001] apontam diferenças de desempenho sobre estes tipos de redes. As

análises são muito dependentes dos algoritmos dos protocolos Multicast utilizados.

Análises e comparações entre protocolos Multicast também vêm sendo muito estudados

[Lee et al. 2000].

Este artigo, porém, busca cenários e aspectos específicos em favor de múltiplas

conexões Unicast, visando delinear um perfil extremo de redes onde a utilização de

protocolos Multicast deve ser cuidadosamente analisada.

3. Fatores de diminuição de desempenho em Multicast

O uso de Multicast contribui para a diminuição de pacotes trafegados em quase todos os

cenários onde se exige que múltiplos usuários recebam ou troquem as mesmas

informações entrem si. Porém, em alguns casos particulares, o Multicast pode oferecer

um desempenho inferior ao Unicast.

Para compreender o conceito de tais características, iremos apresentar dois casos

extremos.

3.1. Número de usuários

Em um cenário onde existam poucos usuários (ou apenas um único usuário) no grupo de

receptores, o desempenho do Unicast será, ao menos, igual ao Multicast. Na prática,

com os overheads gerados pelos protocolos de roteamento e controle, o Multicast torna

inferior ao Unicast em termos de desempenho de rede.

3.2. Distância média entre servidor e clientes

Se conseguirmos estabelecer conexões entre o servidor e todos os demais usuários, sem

a necessidade de roteamento em nós intermediários, novamente observaremos que a

quantidade de informações necessárias para o Multicast será similar à quantidade de

informações do Unicast, já que não há aproveitamento de canal. De mesma forma, o

overhead proporcionado pelo Multicast, no qual adicionalmente haverá um maior

controle por oferecer uma topologia mais complexa do que no caso anterior (apenas um

usuário), por ter que verificar inúmeras rotas possíveis entre cada servidor e usuário,

torna o Multicast pouco eficiente.

Este artigo foca o desempenho Multicast em cenários com excesso de conexões,

onde o número médio de nós entre o servidor e seus clientes é baixo ou nulo.

4. Metodologia e escopo do experimento

O presente artigo tem como foco avaliar o desempenho de redes Multicast altamente

conectadas. A primeira característica importante é que as redes analisadas neste artigo

são estáticas, ou seja, nenhum link é interrompido ou criado em tempo de simulação, e

nenhum nó se move sobre a rede. Tal característica foi fixada para evitar uma grande

variação do comportamento das simulações para cada ambiente específico, mantendo o

foco especificamente em redes com grande número de conexões.

Uma segunda característica do cenário em estudo é o protocolo usado. Dentre

diversos protocolos existentes, tais como MOBICAST [Hung, Lu, e Roman 2003],

AMRoute [Xie, Talpade, e Liu 2002], ODMRP [Lee., Su, e Gerla 200], AMRIS,

CAMP, entre outros, para redes dinâmicas, e os protocolos DVMRP [RFC 1988], PIM-

DM [RFC 2005], PIM-SM [Deering, Estrin, Farinacci, Jacobson, Liu e Wei 1996],

MOSPF [RFC 1994], CBT [RFC 1997], entre outros, para redes estáticas, foram

selecionado os protocolos PIM-DM e DVMRP. A escolha se justifica por serem estes os

protocolos mais difundidos e aplicados em redes estáticas.

5. Modelo de simulação

Todas as simulações foram realizadas através do simulador NS2 [Ns-2], com um tempo

total de simulação de 10 segundos.

Nas simulações, não é considerado a perda de pacotes, atribuindo em todas as

conexões uma capacidade irrestrita de troca de informação. Esta característica é

desejável uma vez que, o foco deste artigo é para avaliar o desempenho global do

sistema, de forma genérica, sem envolver cenários específicos com suas limitações. O

delay entre cada conexão é de 10 µs.

Com apenas uma fonte de dados, o servidor envia com taxa constante (CBR –

Constant Bit Rate) pacotes de 500 kb, em intervalos regulares de 0,03 s, gerando um

throughput de 16 Mbps. O modelo CBR, ao contrário da distribuição exponencial,

proporciona uma melhor estabilidade na rede, permitindo uma análise mais precisa do

comportamento da simulação.

5.1. Topologia

Os cenários de análise são gerados da seguinte forma: Partindo de uma rede tipo token

ring (anel), onde todos os clientes e o servidor encontram-se distribuídos aleatoriamente,

adiciona-se N novas conexões em pares aleatórios de nós, porém igualmente distribuídos

entre os nós. Partir de uma rede token ring garante que não há sub-redes isoladas, e a

adição de conexões extras leva a uma rede mesh. Levando em conta que o objetivo deste

artigo é a simulação de redes altamente interconectadas, há pouca influência da topologia

inicial. A figura abaixo (figura 1) ilustra o algoritmo de geração da rede.

Figura 1. Algoritmo de geração da rede altamente interconectada. A partir de uma rede token

ring, adiciona-se conexões entre nós aleatórios

5.2. Entrada e saídas de usuários

Há dois modelos de join (entrada) e leave (saída) de usuários: aleatório e constante. No

modelo aleatório, os usuários entram e saem dos grupos Multicast com distribuição

linear, sendo que a simulação sempre é iniciada e finalizada sem nenhum membro.

No modelo constante, um número pré-estabelecido de usuários permanece no

grupo desde a inicialização até a finalização da simulação, sem variação. Este último

modelo provê uma simulação mais direcionada ao escopo deste artigo, discriminando o

processo de join e leave dos usuários, assim como não oferece variação do número de

usuários em qualquer instante da simulação, o que permite analisar a rede em regime

permanente.

5.3. Métricas

As principais medidas utilizadas neste artigo são: taxa de envio total (dados +

overhead de controle) e contabilidade total de todos os dados enviados para todos os

nós. Espera-se com estas métricas uma contabilização total dos recursos utilizados da

rede, servindo como base de comparação e análise durante toda a descrição deste artigo.

6. Simulações e Análises

6.1. Simulação 1: Grande quantidade de nós com usuários aleatórios

Considerou-se três protocolos: Unicast, Multicast DVMRP e Multicast PIM-DM.

Partindo de uma rede tipo token ring onde todos os clientes e o servidor encontra-se

distribuídos aleatoriamente, adiciona-se N conexões entre dois nós aleatórios, e o

número de conexões adicionais usado é {10, 200, 500, 1000, 2000 e 4000}. O número

de usuários é de 60, em um total de 600 nós e um servidor. Os usuários entram e saem

do grupo de forma aleatória.

Os gráficos representam a quantidade acumulativa total de dados enviado por

todos os nós (dado + controle).

01E

+07

2E+0

73E

+07

4E+0

75E

+07

6E+0

77E

+07

00,

61,

21,

82,

4 33,

64,

24,

85,

4 66,

67,

27,

88,

4 99,

6

Tempo

Acu

mu

lo d

e d

ad

os

tra

feg

ad

os

(k

b)

Unicast

DVMRP

Pim-DM

Figura 2. N = 10

Para poucas interconexões (figura 2), o desempenho Multicast mostra-se

superior à múltiplas conexões Unicast. A diferença entre o Multicast DVMRP e

Multicast PIM-DM é decorrente das características de seus protocolos, que são

severamente afetadas pela topologia.

0

5E+0

6

1E+0

7

2E+0

7

2E+0

7

3E+0

7

00,

61,

21,

82,

4 33,

64,

24,

85,

4 66,

67,

27,

88,

4 99,

6

Tempo

Acu

mu

lo d

e d

ad

os t

rafe

gad

os (

kb

) Unicast

DVMRP

Pim-DM

Figura 3. N = 200

Conforme a quantidade de conexões adicionas sobe, como observado (figura 3),

o desempenho de múltiplas conexões Unicast tem uma rápida reação.

02E+0

64E

+06

6E+0

68E

+06

1E+0

71E

+07

1E+0

72E

+07

2E+0

7

00,

61,

21,

82,

4 33,

64,

24,

85,4 6

6,6

7,2

7,8

8,4 9

9,6

Tempo

Acu

mu

lo d

e d

ad

os

tra

feg

ad

os

(k

b) Unicast

DVMRP

Pim-DM

Figura 4. N = 500

Para N=500 (figura 4), temos o número médio de nós entre dois pontos um

pouco abaixo de 5, com a média de 3,6 conexões por nós. A queda do desempenho

Multicast em relação a múltiplas conexões Unicast torna-se evidente.

02E+0

64E

+06

6E+0

68E

+06

1E+0

71E

+07

1E+0

72E

+07

2E+0

7

00,

61,

21,

82,

4 33,

64,

24,

85,

4 66,

67,

27,

88,

4 99,

6

Tempo

Ac

um

ulo

de

da

do

s t

rafe

ga

do

s (

kb

) Unicast

DVMRP

Pim-DM

Figura 5. N = 1000

Uma característica própria do protocolo PIM-DM, é a carga inicial da rede.

Como observado (figura 5), o valor inicial do protocolo PIM-DM cresce na medida em

que se aumenta o número de conexões. Sem entrar em detalhes, fora do escopo deste

artigo, este protocolo tem como característica assumir que todos os nós pertencem ao

grupo de Multicast até receber uma requisição explícita de exclusão. Desta forma, com

múltiplas conexões e inúmeros caminhos possíveis entre os nós, o protocolo PIM-DM

tem uma sobrecarga no início da simulação.

02E

+06

4E+0

66E

+06

8E+0

61E

+07

1E+0

71E

+07

2E+0

7

00,

61,

21,

82,

4 33,

64,

24,

85,

4 66,

67,

27,

88,

4 99,

6

Tempo

Ac

um

ulo

de

da

do

s t

rafe

ga

do

s (

kb

) Unicast

DVMRP

Pim-DM

Figura 6. N = 2000

Com N = 2000 (figura 6), o desempenho Multicast encontra-se inferior à

múltiplas conexões Unicast. Novamente, o número médio de usuários simultâneos é de

20, e tais características de desempenho estão restritas à topologia e conexões

estabelecidas.

0

5E+06

1E+07

2E+07

2E+07

3E+07

00,

61,

21,8 2,

4 33,6 4,

24,

85,4 6

6,6

7,2 7,8

8,4 9

9,6

Tempo

Ac

um

ulo

de

da

do

s t

rafe

ga

do

s (

kb

) Unicast

DVMRP

Pim-DM

Figura 7. N = 4000

Quando o número de conexões média atinge um pouco mais de 15 conexões por

usuário, com a distância média entre nós de 2,3 hops, o desempenho Multicast supera o

desempenho Multicast nos protocolos PIM-DM e DVMRP nas condições estabelecidas

(figura 7).

Como resumo das simulações, o gráfico abaixo (figura 8) apresenta a quantidade

total de dados transmitidos em relação à quantidade de conexões:

0

1000

0000

2000

0000

3000

0000

4000

0000

5000

0000

6000

0000

7000

0000

0 500 1000 1500 2000 2500 3000 3500 4000 4500

Número de conexões adicionais

Qu

an

tid

ad

e t

ota

l d

e in

form

aç

õe

s t

ran

sfe

rid

as (

kb

)

UNICAST

PIM_DM

DVMRP

Figura 8. relação entre conexões e total de informações transferidas

Novamente, os dados analisados acima referem-se ao uso total da rede do

sistema. Nota-se que o desempenho de múltiplas conexões Unicast tem uma rápida

melhora em relação aos recursos totais da rede. Este fato é independente do comparativo

com o Multicast.

Como complemento das simulações anteriores, o gráfico abaixo (figura 9)

apresenta a taxa de envio dos servidores das simulações N = {10, 200, 500, 1000, 2000,

4000} respectivamente.

0

10000

20000

30000

40000

50000

60000

70000

80000

00,8

1,6

2,4

3,2 4

4,8

5,6

6,4

7,2 8

8,8

9,6

Tempo (s)

Dados e

nvia

dos (K

b)

Unicast

DVMRP

Pim-DM

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

00,8

1,6

2,4

3,2 4

4,8

5,6

6,4

7,2 8

8,8

9,6

Tempo (s)D

ados e

nvia

dos (K

b)

Unicast

DVMRP

Pim-DM

Figura 9(a) Figura 9(b)

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

00,8

1,6

2,4

3,2 4

4,8

5,6

6,4

7,2 8

8,8

9,6

Tempo (s)

Dados e

nvia

dos (K

b)

Unicast

DVMRP

Pim-DM

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

00,8

1,6

2,4

3,2 4

4,8

5,6

6,4

7,2 8

8,8

9,6

Tempo (s)

Dados e

nvia

dos (K

b)

Unicast

DVMRP

Pim-DM

Figura 9(c) Figura 9(d)

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

00,8

1,6

2,4

3,2 4

4,8

5,6

6,4

7,2 8

8,8

9,6

Tempo (s)

Dados e

nvia

dos (K

b)

Unicast

DVMRP

Pim-DM

0

10000

20000

30000

40000

50000

60000

70000

80000

00,8

1,6

2,4

3,2 4

4,8

5,6

6,4

7,2 8

8,8

9,6

Tempo (s)

Dados e

nvia

dos (K

b)

Unicast

DVMRP

Pim-DM

Figura 9(e) Figura 9(f)

Figura 9. Dados enviados pelo servidor em relação ao tempo

6.2. Simulação 2: Relação número de usuário e quantidade de conexões

Completando as simulações anteriores, foram realizadas diversas simulações variando a

quantidade média de nós intermediários e números de usuários. Todas as simulações a

seguir têm características similares as simulações anteriores (delay de 10 µs entre nós;

servidor com taxa constante de 16 mbps com pacotes de 500 kb e tempo total de

simulação de 10 segundos). Porém, o número de usuários é constante, entrando no

tempo 0 s da simulação e permanecendo até o tempo 10 s. Foram utilizados 60 nós.

Os protocolos utilizados nesta simulação foram o Multicast DVMRP e Unicast,

este último como base de comparação. O protocolo PIM-DM, assim como demais

protocolos Muticast convenientes a este cenário, não será utilizado nesta próxima

simulação, devido estes apresentarem comportamentos similares ao protocolo DVMRP,

principalmente para um cenário com o número pequeno de nós (no caso, 60), deixando

desta forma a análise mais clara e simples para a avaliação e compreensão.

A tabela abaixo (Tabela 1) apresenta o total de dados, em kb, veiculados por

todos os nós.

Tabela 1. Total utilização dos recursos em relação às conexões e número de usuários

12 usuários 10 usuários 8 usuários 6 usuários

Conexões HOP Unicast DVMRP Unicast DVMRP Unicast DVMRP Unicast DVMRP

60 15,5 36.919.000 9.248.100 34.758.500 9.248.100 26.038.000 6.639.240 17.481.500 6.362.600

120 8 6.325.000 4.508.040 5.160.000 4.060.660 3.995.000 3.462.820 2.830.000 3.005.000

360 3 3.829.500 2.904.040 3.330.000 2.748.560 2.830.500 2.593.080 2.164.500 2.143.260

660 1,86 3.330.000 2.688.240 2.664.000 2.377.280 2.164.500 2.073.860 1.665.000 1.771.600

960 1,43 2.997.000 2.680.700 2.497.500 2.223.540 1.998.000 1.912.580 1.332.000 1.601.620

1260 1,21 2.497.500 2.515.940 1.998.000 2.204.980 1.665.000 1.894.020 1.332.000 1.592.340

1660 1,04 2.164.500 2.515.940 1.831.500 2.204.980 1.498.500 1.894.020 999.000 1.583.060

Pela tabela acima (tabela 1), gera-se o ganho proporcional (figura 10) do

Multicast sobre o Unicast pelo tráfego total da rede em relação ao número de usuários e

quantidade média de nós intermediários:

-100%

-50%

0%

50%

100%

150%

200%

250%

300%

350%

15,5 8 3 1,86364 1,4375 1,21429 1,04217

Distância média entre nós

Ganho

12 usuários

10 usuários

8 usuários

6 usuários

Figura 10. Relação de ganho entre número de usuários e conexões (Total)

Complementando a simulação anterior, a tabela abaixo (tabela 2) apresenta o

total de dados enviados pelo servidor.

Tabela 2. Utilização do servidor em relação às conexões e número de usuários

12 usuários 10 usuários 8 usuários 6 usuários

Conexões HOP Unicast DVMRP Unicast DVMRP Unicast DVMRP Unicast DVMRP

60 15,5 1.998.000 333.000 1.665.000 333.000 1.332.000 333.000 999.000 333.000

120 8 1.998.000 525.000 1.665.000 525.000 1.332.000 525.000 999.000 525.000

360 3 1.998.000 653.000 1.665.000 653.000 1.332.000 653.000 999.000 512.000

660 1,863636 1.998.000 1.030.000 1.665.000 1.030.000 1.332.000 881.500 999.000 733.000

960 1,4375 1.998.000 1.383.000 1.665.000 1.077.500 1.332.000 920.500 999.000 920.500

1260 1,214286 1.998.000 1.802.500 1.665.000 1.645.500 1.332.000 1.331.500 999.000 1.026.000

1660 1,042169 1.998.000 2.249.500 1.665.000 1.935.500 1.332.000 1.621.500 999.000 1.464.500

Pela tabela acima (tabela 2), novamente é demonstrado o ganho do Multicast em

relação ao Unicast (figura 11):

-100%

0%

100%

200%

300%

400%

500%

600%

15,5 8 3 1,86364 1,4375 1,21429 1,04217

Distância média entre nós

Ga

nh

o

12 usuários

10 usuários

8 usuários

6 usuários

Figura 11. Relação de ganho entre número de usuários e conexões (Servidor)

Como novamente observado (figura 11), conforme o aumento da complexidade

(quantidade de conexões) da rede, o protocolo Multicast DVMPR tem o seu

desempenho reduzido, tanto no aspecto geral da rede, quanto na taxa de envio do

servidor (dados + controle), devido ao esforço (overhead) adicional de gerenciamento.

7. Conclusões

Neste artigo foram apresentadas algumas características de comportamento de

protocolos Multicast em redes altamente interconectadas. Demonstrou-se com

simulações que nestas redes a banda total de rede usada pelo Multicast pode ser maior

do que usada, nas mesmas condições, por múltiplas conexões Unicast. Isto se deve ao

aumento da informação necessária para o roteamento de mensagens pelo Multicast.

A busca por alcançar algoritmos e protocolos ótimos para o Multicast, tanto em

redes dinâmicas (Wireless) quanto em redes estáticas (Wired), tem sido foco de grandes

esforços por pesquisadores e desenvolvedores. Este artigo não trás uma comparação

entre múltiplas conexões Unicast e protocolos Multicast, mas sim um levantamento das

dificuldades nos quais os protocolos Multicast apresentam em casos específicos e

extremos.

Trabalhos futuros estenderão também as análises de piores casos em Multicast

para redes dinâmicas, utilizando protocolos Multicast para redes ad-hoc, no qual

levantar-se-á novas características de desempenhos em casos extremos.

8. Referências

Deering, S., Estrin, D., Farinacci, D., Jacobson, D., Liu, C. e Wei, L., “The PIM

architecture for wide-area multicast routing”, IEEE/ACM Transactions on

Networking, Abril, 1996.

Hung, Q. Lu, C. e Roman, G., “Conference On Embedded Networked Sensor Systems

archive”, In Proceedings of the 1st international conference on Embedded networked

sensor systems table of contents, Los Angeles, California, USA, pp. 205-217, 2003.

Lee, A., Su, W., Hsu, J., Gerla, M. e Bagrodia, R., “A Performance Comparison Study

of Ad Hoc Wireless Multicast Protocols”, In Proceedings of IEEE INFOCOM 2000,

Tel Aviv, Israel, pp. 565-574, Março, 2000.

Lee., S., Su, W. e Gerla, M., “On-demand multicast routing protocol in multihop

wireless mobile networks”, In Mobile Networks and Applications, v. 7, Issue 6, pp.

441-453, Dezembro, 2002.

Legout, A., Nonnenmacher, J. e Biersack, E., “Bandwidth Allocation Policies for

Unicast and Multicast Flows”, In IEEE/ACM Transactions on Networking, 9(4),

Agosto, 2001.

Majumdar, A., Sachs, D., Kozintsev, I., Ramchandran, K. e Yeung, M., “Multicast and

Unicast Real-Time Video Streaming Over Wireless LANs”, In IEEE Transactions on

Circuits and Systems for Video Technology, vol.12, no.6, Junho, 2002.

Ns-2: network simulator. http://www.isi.edu/nsnam/ns/

Rajendran, V., Obraczka, K., Yi, Y., Lee, S., Tang, K e Gerla, M., “Combining Source-

and Localized Recovery to Achieve Reliable Multicast in Multi-Hop Ad Hoc

Networks”, In Proceedings of the Networking' 04, Março, 2004.

RFC: RFC 1075: Distance Vector Multicast Routing Protocol. Novembro de 1998.

RFC: RFC 1585: MOSPF: Analysis and Experience. Março de 1994.

RFC: RFC 2189: Core Based Trees Multicast Routing, version 2. Setembro de 1997

RFC: RFC 3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol

Specification (Revised). Janeiro, 2005.

Viswanath, K., Obraczka, K., Tsudik, G., “Exploring Mesh- and Tree Based Multicast

Routing Protocols for MANETs”, Transaction of Mobile Computing (TMC 2004),

2004.

Viswanath, V., e Obraczka, K., “Interoperability of Multicast Routing Protocols in

Wireless Ad hoc networks”, In Journal of Wireless Communications and Mobile

Computing, Special Issue AdHoc 7 (WCMC 2005), 2005.

Wei, W. e Zakhor, A., “Connectivity for Multiple Multicast Trees in Ad Hoc Networks”

In International Workshop on Wireless Ad-hoc Networks, Oulu, Finland, June 2004a.

Wei, W. e Zakhor, A., “Multipath Unicast and Multicast Video Communication over

Wireless Ad Hoc Networks” In International Conference on Broadband Networks

(Broadnets) 2004, San Jose, CA, pp. 496-505, Outubro, 2004b.

Xie, J. Talpade, R. e Liu, A., “AMRoute: ad hoc multicast routing protocol”, In Mobile

Networks e Applications, v. 7, Issue 6, pp. 429-439, Dezembro, 2002.

Estrategias de Escalonamento em um Ambiente deJob-shop

Gilberto Iraj a Muller 1, Arthur T orgo Gomez1

1Universidade do Vale do Rio dos Sinos – UNISINOSPIPCA - Programa Interdisciplinar de Pos-Graduacao em Computacao AplicadaAv. Unisinos, 950 – Bairro Cristo Rei – CEP 93022-000 – Sao Leopoldo – RS

irajamuller@terra.com.br, breno@unisinos.br

Resumo.Neste trabalho sao apresentadas estrategias de escalonamento atraves de um modeloaplicado ao Job-shop Scheduling Problem que considera o tempo total de producao (makespan),o tempo total de atraso e o tempo total de paradas. O modeloe composto por: (i) uma funcaoobjetivo que reflete as estrategias de otimizacao, e de (ii) uma arquitetura que esta divididaem cinco fases. O modelo utilizou o algoritmo Busca Tabu que, atraves de duas estrategiasde geracao de vizinhancas, busca a otimizacao da funcao objetivo. A arquitetura do modelobaseia-se na Tecnologia de Grupo, nas Regras de Despacho e no Algoritmo Busca Tabu paratratar os Problemas de Selecao de Partes e do Escalonamento. Os resultados e analises saoapresentados ao final deste trabalho.

1. IntroducaoO Job-shop Scheduling Problem(JSP) pode ser descrito por:n jobs, onde cadajob e composto porjoperacoes que devem ser processadas emm maquinas. Cada operacao j utiliza uma dasm maquinas comum tempo de processamento fixo. Cada maquina processa uma operacao por vez sendo que nao ocorreinterrupcao. As operacoes devem ser processadas em ordem atraves de um roteiro pre-estabelecido. Oproblema consiste em encontrar um escalonamento que obedeca as precedencias de operacoes nas maquinastal que minimize omakespanCmax dado o processamento doultimo job.

SejaJ = {0, 1, ..., n, n + 1} o conjunto de operacoes a serem escalonadas eM = {1, ...,m}o conjunto de maquinas. As operacoes 0 en + 1 nao possuem duracao e representam o inıcio e fim daoperacao. Para as operacoes inter-relacionadas possuem dois tipos de restricoes: (i) a de precedencia emque cada operacaoj sera escalonada depois de todas as operacoes predecessorasPj forem finalizadas e (ii) aoperacao somente sera escalonada se a maquina estiver ociosa. Representaremos o tempo de processamentofixo por dj , o tempo final do processamento da operacao j por Fj . Para o escalonamento, utilizaremosum vetor para os tempos de finalizacao (F1, Fm, ..., Fm+1) e A(t) para o conjunto de operacoes a seremprocessadas no tempot; rj,m = 1 se a operacao j e processada na maquinamerj,m = 0, caso contrario. Omodelo doJSPpode ser definido por [Goncalves et al. 2005]:

Minimize Fn+1(Cmax) (1)

Fk ≤ Fj − dj , j = 1, ..., n + 1; k ∈ Pj , (2)∑j∈A(t)

rj,m ≤ 1, m ∈ M ; t ≥ 0, (3)

Fj ≥ 0, j = 1, ..., n + 1. (4)

A funcao objetivo (1) busca minimizar o tempo total de producao (makespan). A restricao (2)assegura a precedencia das relacoes entre operacoes e a restricao (3) assegura o processamento de umaoperacao por vez. Por fim, a restricao (4) garante a nao-negatividade. Dessa forma, o artigo possui a se-guinte organizacao: na Secao 2, sao apresentados os problemas abordados para o JSP e o metodo utilizado;na Secao 3, sao apresentadas as caracterısticas da meta-heurıstica Busca Tabu; na Secao 4,e conceituadoo modelo proposto e, por fim, na Secao 5 sao apresentados os resultados da validacao, as estrategias deescalonamento e as conclusoes finais.

2. Problemas AbordadosNesta secao sao apresentados dois problemas que sao abordados na geracao do modelo proposto aplicadoao JSP. O primeiro problema esta relacionado com a fase pre-operacional e o segundoe abordado na faseoperacional[Stecke 1986], sao eles:

• selecao de partes: existem diversos metodos para a geracao das Famılias de Partes (FP), sendodestacados a Inspecao Visual, Classificacao por Codificacao e Analise por Fluxo de Producao(formulacao matricial, programacao matematica e particionamento de grafos) [Jha 1991]. As FPssao formadas atraves do agrupamento das partes, baseada nas similaridades, tais como: formageometrica, processo, similaridade por um mesmo conjunto de ferramentas entre outros ee consi-derado um problema NP-Completo [Jha 1991]. O modelo proposto utilizou o metodo de Analisepor Fluxo de Producao proposto por Kusiak [Kusiak and Chow 1987] denominado deClusterIdentification;

• escalonamento de partes: o escalonamento das partes num JSPe um problema de difıcil solucao,ou seja,NP-Hard [Garey et al. 1976]. O objetivo esta em sequenciar osjobsem um conjunto demaquinas atraves de rotas pre-definidas em funcao do tempo [Blazewicz et al. 1996]. Inumerosmetodos de otimizacao foram propostos para a solucao do JSP [Zoghby et al. 2004], sendo desta-cado os metodos de otimizacao e os metodos aproximativos. Para os metodos de otimizacao saocitadas a Programacao Inteira, a Relaxacao Lagrangeana, as Tecnicas de Surrogate e oBranchand Bound[Balas et al. 1979]. Nos metodos aproximativos sao destacados os algoritmos iterati-vos Busca Tabu, as Redes Neurais, os Algoritmos Geneticos, a Tempera Simulada e o GRASP[Blazewicz et al. 1996], [Glover and Laguna 1997] e [Goncalves et al. 2005]. Para resolver o pro-blema do escalonamento de partes foi utilizado o algoritmo Busca Tabu em virtude da complexi-dade do problema e dos diversos trabalhos relacionados.

3. Busca TabuA meta-heurıstica Busca Tabu (BT) teve origem a partir de uma solucao para problemas de programacaointeira; posteriormente foi dada uma descricao do metodo para uso geral em problemas de otimizacaocombinatoria [Adams et al. 1988].

Basicamente, a BT, que foi projetada para encontrar boas aproximacoes para a solucao otimaglobal de qualquer problema de otimizacao, possui tres princıpios fundamentais: (i) uso de uma estruturade dados (lista) para guardar o historico da evolucao do processo de busca, (ii) uso de um mecanismo decontrole para fazer um balanceamento entre a aceitacao ou nao de uma nova configuracao, com base nasinformacoes registradas na lista tabu referentesas restricoes e aspiracoes desejadas e (iii) incorporacao deprocedimentos que alternam as estrategias de diversificacao e intensificacao [Glover and Laguna 1997].

Para a utilizacao da BT,e fundamental a definicao da funcao objetivof do problema em questao.Apos esta definicao, e gerada uma solucao inicial viavel independente (Regra de Despacho). Sendo que,para a geracao da solucao inicial, e obrigatorio que esta faca parte do conjunto de solucoes possıveis doespaco amostral.

4. ModeloO modelo proposto apresenta uma formulacao quee a funcao objetivo para a otimizacao do escalonamentodas partes e de uma arquitetura baseada no modelo de planejamento de producao para o Sistema de Manu-fatura Flexıvel (SMF) proposto por Stecke [Stecke 1986].

4.1. Formulacao

A formulacao utilizada para a otimizacao do escalonamento das partese mostrada a seguir, onde: m =numero de maquinas, n = numero de partes, i =ındice para a parte, k =ındice para a maquina, Dei = datade entrega da parte e Dspik = data da saıda de producao. Onde:

Minimizar f(e, p) = p1.makespan(e, p) + p2.atraso(e, p) + p3.parada(e, p) (5)

makespan(e, p) =

mX

k=1

nX

i=1

makespanik, tal que makespanik > 0 (6)

atraso(e, p) =

mX

k=1

nX

i=1

(Dspik −Dei), tal que(Dspik −Dei) > 0 (7)

parada(e, p) =

mX

k=1

nX

i=1

paradaik, tal que paradaik > 0 (8)

p1, p2, p3 ≥ 0. (9)

A funcao objetivo (5), que busca a minimizacao,e definida pela variavel “e” (escalonamento), querepresenta a dimensao temporal e a variavel “p” (Famılias de Partes), representa a dimensao fısica para omodelo proposto.E formada por tres variaveis de decisao que refletem estrategias de otimizacao. A variavelde decisao makespan(e,p) representa o tempo total de producao (6), ou seja,e o tempo inicial do primeirojob processado em producao ate o tempo final doultimo job processado. A variavel de decisao atraso(e, p)representa o tempo total de atraso (7). O tempo total de paradas de producao e representada pela variavelde decisao parada(e,p) e significa o tempo entre dois lotes de producao (8). Por fim, a restricao (9) asseguraa nao-negatividade das variaveis. Conforme apresentado na Secao 2, sobre o Problema do Escalonamento,e apresentado abaixo o algoritmo BT modificado que utiliza a funcao objetivo supracitada.

while (niter - melhiter< nbmax)dofor “m” m aquinado

f ′ ← fmelhor;niter ← melhiter + 1;p← p∗;Gerar V ∗

e de solucoes(e, p∗)i em Ne(e, p∗) ou f((e, p∗)i) < A(f(e, p∗));

Atualizar Lista Tabu L e A(z);if f(e′, p∗) < fmelhor then

fmelhor ← f(e′, p∗);endifGerar V p∗ de solucoes(e, p)i em Np(e, p) ou f((e, p)i) < A(f(e, p));Atualizar Lista Tabu L e A(z);if f(e′, p′) < fmelhor then

fmelhor ← f(e′, p′);endifp← p′;e← e′;

endforif fmelhor < f ′ then

melhiter ← niter;endif

endw

Algoritmo 1 : Algoritmo BT modificado

A cada iteracao umotimo local e escolhido e a partir delee gerada uma nova vizinhanca. Paraevitar ciclos e mınimos locaise implementada uma lista de movimentos reversos proibidos chamada de listatabu (L). Caso a iteracao obtenha uma melhora na funcao f , utiliza-se a funcao criterio de aspiracaoA,que admite o movimento ate entao proibido. Para as condicoes de parada do algoritmo, pode-se utilizar umnumero maximo de iteracoes (nbmax) sem que ocorra melhoria na funcaof ou executar ate que alcance ovalor mınimo.

4.2. ArquiteturaA arquitetura para a Selecao e Escalonamento de Partes esta dividida em cinco fases de aplicacao conformee apresentado na Figura 1.

Figura 1. Arquitetura do Modelo

A primeira fasee responsavel por obter a demanda de producao atraves das informacoes contidasno banco de dados, sendo recuperadas as informacoes tecnicas da parte e a data de entrega. Na segunda faseocorre a geracao da matriz parte versus maquina aplicando o algoritmo de identificacao de agrupamentos.Na terceira fase,e utilizado a Regra de Despacho aplicando oCluster Identification para a geracao doescalonamento inicial. A partir do escalonamento inicial,e possıvel realizar a quarta fase que consiste naaplicacao do algoritmo BT para a otimizacao do escalonamento. Apos a geracao do escalonamento finale gravado este num plano de producao, possibilitando assim observar seus historicos e compara-los com oescalonamento efetivo.

5. Resultados

A etapa de validacao do modelo propostoe realizada atraves da comparacao com trabalhos classicos quepropoem a solucao do JSP [Blazewicz et al. 1996][Jain and Meeran 1998][Zoghby et al. 2004]. Para testaro desempenho da arquitetura sao utilizadas diversas instancias do JSP de modo a realizar a validacao em di-versos ambientes (numero de partes x numero de maquinas). Para a validacao, foram utilizadas as instanciaspropostas por Muth [Muth and Thompson 1963] denominada de FT06, FT10 e FT20, e as instancias pro-postas por Lawrence [Lawrence 1984] denominadas de LA01, LA06, LA11, LA16, L21, LA29 e LA40.

5.1. Instancia generica

A instancia generica para o problema do JSP possui as seguintes definicoes: (i) a primeira linha define adimensao da matriz (n x m), onde o “n” representa o numero de partes para o problema em questao e o“m” representa o numero de maquinas, (ii) as demais linhas representam a rota para cada parte, onde: avariavel “M” ilustra a maquina e a variavel “T” ilustra o tempo de processamento, (iii) as colunasımparesrepresentam o numero da maquina que a parte devera ser processada e (iv) as colunas pares representam otempo de processamento da parte em cada maquina. A Figura 2 ilustra a instancia.

Figura 2. Estrutura Gen erica de uma Inst ancia do JSP

5.2. Trabalhos selecionados

Atraves dos trabalhos que propoem a resolucao do JSP [Jain and Meeran 1998][Zoghby et al. 2004], foramselecionados alguns autores em funcao do tipo de algoritmo utilizado e da sua importancia na evolucao doestado da arte. A Tabela 1 mostra os autores selecionados e o algoritmo utilizado.

Tabela 1. Autores selecionados para a validac ao do modelo

Autor Algoritmo AnoStorer [Storer et al. 1992] Busca no espaco 1992Aarts [Aarts et al. 1994] Algoritmos geneticos 1994

Dorndorf [Dorndorf and Pesch 1995] Algoritmos geneticos 1995Nowicki [Nowicki and Smutnicki 1996] Busca Tabu 1996

Wang [Wang and Zheng 2001] Genetico hıbrido e Tempera simulada 2001Aiex [Aiex et al. 2003] GRASP 2003

Goncalves [Goncalves et al. 2005] Algoritmos geneticos hıbridos 2005

5.3. Configuracao

Para a configuracao do algoritmo BT modificado foi atribuıdo o valor de 100 para o numero maximo deiteracoes sem obter melhora na funcao objetivo (nbmax) e, para o tamanho da lista tabu, foi atribuıdo 15.Em virtude dos autores selecionados utilizarem omakespanpara os seus experimentos, os pesos (p1, p2 ep3) para a funcao objetivo foram fixados em 100, 1 e 1, respectivamente, de modo a privilegiar a variavelde decisaomakespan. E importante ressaltar que o modelo proposto, alem de otimizar omakespan, possuiuma arquitetura que tem como objetivo o gerenciamento entre as datas de entrega (minimizacao do atraso)e a produtividade (minimizacao das paradas de producao).

As demais abordagens supracitadas otimizam somente omakespan, desconsiderando as datas deentrega e a produtividade do sistema. Como as instancias nao possuem as datas de entrega para a parte, e omodelo propostoas utiliza como estrategia de otimizacao, foram fixadas todas as partes com a mesma datade entrega.

O modelo foi implementado em Delphi 7 e seus experimentos executados em umhardware AthlonXP 2500+ 512 RAMcom sistema operacionalWindows XP Pro.

5.4. Validacao

Os resultados da validacao sao mostrados na Tabela 2. Nelae apresentada a instancia do problema, adimensao do problema (numero de partes x numero de maquinas), a solucao otima conhecida (SOC), asolucao obtida pelo modelo proposto (MP) e a solucao dos autores selecionados.

Tabela 2. Estrat egia que privilegia a produtividade

Instancia NxM SOC MP Goncalves Aiex Wang Nowicki Dorndorf Aarts StorerFT06 6x6 55 55 55 55 55 55FT10 10x10 930 930 930 930 930 930 960 935 952FT20 20x5 1165 1165 1165 1165 1165 1165 1249 1165LA01 10x5 666 666 666 666 666 666 666 666 666LA06 15x5 926 926 926 926 926 926 926 926LA11 20x5 1222 1222 1222 1222 1222 1222 1222 1222LA16 10x10 945 945 945 945 945 945 1008 977 981LA21 15x10 1046 1047 1046 1057 1058 1047 1139 1084LA29 20x10 1157 1160 1196 1203 1160 1336 1290LA40 15x15 1222 1229 1241 1244 1229 1321 1273 1258

Atraves da Tabela 2e possıvel fazer um comparativo entre o modelo proposto e a solucaootima co-nhecida. Nota-se que omakespancom a maior diferenca em relacaoa SOC diferencia-se em 7 unidades detempo (LA40), equivalendo a uma diferenca de 0,57%. De maneira a validar o modelo, os resultados espe-rados atingiram o objetivo, ou seja, em muitos casos alcancando a SOC e, em outros casos, aproximando-se.

As instancias que tiveram diferencas em relacaoa SOC, sofreram influencia da funcao objetivo domodelo proposto. Ao avaliar a funcao objetivo, considerou-se para este problema domakespan, um pesosignificativamente maior para a variavel de decisao makespando que as demais variaveis, direcionandoassim a BT para a otimizacao domakespan.

Observa-se tambem que, apos a validacao, alem de contemplar omakespan, o modelo proposto

realizou o gerenciamento entre as datas de entrega (atraso) e a produtividade (velocidade de producao) dosistema de producao, mesmo privilegiando a variavel de decisaomakespan.

A capacidade do modelo em gerenciar estrategias diferentes de escalonamento e, nao somente omakespan, ocorre em virtude das variaveis de decisao que compoem a funcao objetivo e que abordam es-trategias de escalonamento, tais como: (i)makespan, (ii) tempo total em atraso e (iii) tempo total paradoem producao. A seguir sao apresentadas algumas estrategias na utilizacao do modelo proposto e que naosao consideradas nas demais abordagens.

5.5. Estrategia que privilegia a otimizacao das paradas de producao

Dado o privilegio da variavel de decisao parada (peso p3=100), objetiva-se a produtividade e, consequente-mente, a velocidade de producao. A Tabela 3 apresenta o resultado dos experimentos.

Tabela 3. Estrat egia que privilegia a produtividade

Instancia SOC MP Diferenca % Partes em atrasoFT06 55 55 0,00 2FT10 930 930 0,00 3FT20 1165 1165 0,00 4LA01 666 666 0,00 2LA06 926 926 0,00 3LA11 1222 1222 0,00 3LA16 945 945 0,00 4LA21 1046 1047 0,09 5LA29 1157 1160 0,26 5LA40 1222 1229 0,57 4

Atraves dos experimentos que visam a otimizacao da produtividade, presencia-se um conflito emrelacaoas datas de entrega (atraso) e as paradas de producao, ou seja, quanto menore o tempo de paradasde producao (maior magnitude), menore a magnitude da variavel de decisao atraso no direcionamento daBT. Constatou-se que estas variaveis sao independentes e, ao privilegiar uma, causa influencia negativa naoutra. Este comportamento ocorre, pois a variavel de decisao atraso perde a influencia na funcao objetivo,privilegiando assim a escolha de movimento na vizinhanca (algoritmo BT) em funcao da variavel de de-cisao parada e o fato tambem destas variaveis serem independentes.

Outro aspecto importante neste experimento consiste na constatacao da dependencia de duasvariaveis de decisao, ou seja, ao reduzir o tempo parado, ocorreu influencia na reducao domakespan. A es-trategia que privilegia a reducao do tempo parado consistiu com os mesmos valores obtidos pelomakespancalculado na etapa de validacao do modelo.

5.6. Estrategia que privilegia a otimizacao das datas de entrega

Dado o privilegio da variavel de decisao atraso (peso p2=100), objetiva-se a entrega pontual das partes,desconsiderando assim as demais estrategias de otimizacao.

Tabela 4. Estrat egia que privilegia a entrega pontual

Instancia SOC MP Diferenca % Partes em atrasoFT06 55 60 9,09 0FT10 930 1003 7,84 0FT20 1165 1243 6,69 0LA01 666 722 8,40 0LA06 926 1037 11,98 0LA11 1222 1313 7,45 0LA16 945 1020 7,94 0LA21 1046 1145 9,46 0LA29 1157 1259 8,82 0LA40 1222 1356 10,96 0

A partir da Tabela 4, observa-se que o modelo obteve a entrega pontual de todas partes. Porem, omakespansofreu aumento significativo, consequencia do aumento das paradas de producao. Dessa forma,constatou-se o conflito existente entre respeitar as datas de entrega e manter a produtividade.

5.7. Estrategia nao-tendenciosa

A solucao nao-tendenciosae aquela em que o peso nao privilegie nenhuma das variaveis de decisao dafuncao objetivo.E obtida atraves da proporcao das variaveis de decisao dada a execucao de 100 experimen-tos variando os pesos (p1, p2, p3), seguindo uma distribuicao normal com intervalo (0, 100].

Com a estrategia nao-tendenciosa, ocorreu a reducao do conflito entre as variaveis de decisaomakespane parada, ou seja, a relacao entre a produtividade e as datas de entrega. A Tabela 5 ilustra osresultados obtidos.

Tabela 5. Estrat egia n ao-tendenciosa

Instancia SOC MP Diferenca % Partes em atrasoFT06 55 57 3,63 0FT10 930 961 3,33 2FT20 1165 1198 2,83 4LA01 666 684 2,70 1LA06 926 951 2,75 2LA11 1222 1267 3,68 3LA16 945 976 3,25 3LA21 1046 1086 3,28 4LA29 1157 1206 4,23 3LA40 1222 1272 4,09 2

Esta estrategia pode ser utilizada como polıtica de escalonamento, dado que obteve uma relacaoconsistente entre as variaveis de decisaomakespane atraso, sendo observado que omakespanaproximou-seda SOC e poucas partes foram entregues em atraso. Ao ser utilizada uma estrategia nao-tendenciosa, foipossıvel verificar a reducao domakespane nao houveram diferencas significativas em relacao ao numerode partes em atraso ao ser comparado com a estrategia que privilegia a entrega pontual.

5.8. Conclusoes

Este trabalho teve como objetivo apresentar estrategias de escalonamento atraves de um modelo aplicadoao Escalonamento doJob-shop. O modelo implementado esta baseado numa funcao objetivo que reflete,atraves das variaveis de decisao e seus pesos respectivos, estrategias de escalonamento. A arquitetura domodeloe responsavel por tratar os problemas de Selecao e de Escalonamento das Partes. Atraves dasestrategias de escalonamento, foi possıvel demonstrar a flexibilidade e versatilidade do modelo. Foramutilizadas na validacao, diversas instancias para o problema doJob-shope conclui-se que o modelo propostopode ser considerado mais uma abordagem para o escalonamento de producao, devido a sua flexibilidadeem trabalhar com algumas estrategias de escalonamento e em virtude das outras abordagens citadas na etapade validacao nao gerenciarem o conflito entre as datas de entrega (atraso) e a produtividade do sistema deproducao (velocidade de producao). Como extensao futura deste trabalho, sugere-se a validacao do modeloatraves de instancias de grande escala, o aprimoramento dos metodos de geracao e escolha de vizinhanca e,por fim, propor instancias para o JSP que considerem as datas de entrega e paradas de producao dado queas instancias utilizadas foram adaptadas para a validacao do modelo.

Referencias

Aarts, E. H. L., Laarhoven, P. J. M. V., Lenstra, J. K., and Ulder, N. L. J. (1994). A computational study oflocal search algorithms for job shop scheduling.ORSA Journal on Computing, 6:118–125.

Adams, J., Balas, E., and Zawack, D. (1988). The shifting bottleneck procedure for job shop scheduling.Management Science, 34:57–73.

Aiex, R., Binato, S., and Resende, M. G. C. (2003). Parallel GRASP with path-relinking for job shopscheduling.Parallel Computing, 29(4):393–430.

Balas, E., Johnson, E. L., and Korte, B. (1979). Disjunctive programming. In: Hammer, P.L.DiscreteOptimisation II, pages 49–55.

Blazewicz, J., Domschke, W., and Pesch, E. (1996). The job shop scheduling problem: Conventional andnew solution techniques.European Journal of Operational Research, 93:1–33.

Dorndorf, U. and Pesch, E. (1995). Evolution based learning in a job shop environment.Computers andOperations Research, 22:25–40.

Garey, M. R., Johnson, D. S., and Sethi, R. (1976). The complexity of flowshop and jobshop scheduling.Mathematics of Operations Research, 1:117–129.

Glover, F. and Laguna, M. (1997). Tabu Search.Kluwer Academic Publishers, page 382.

Goncalves, J. F., Mendes, M. J. J., and Resende, M. G. C. (2005). A hybrid genetic algorithm for the jobshop scheduling problem.European Journal of Operational Research, 167:77–95.

Jain, A. S. and Meeran, S. (1998). Deterministic job-shop scheduling: Past, present and future.EuropeanJournal of Operational Research, 113(2):390–434.

Jha, N. K. (1991). Handbook of Flexible Manufacturing Systems.Academic Press Limited, page 328.

Kusiak, A. and Chow, W. (1987). Efficient solving of the group technology problem.Journal of Manufac-turing Systems, 6(2):117–124.

Lawrence, S. (1984). Resource constrained project scheduling: an experimental investigation of heuris-tic scheduling techniques.Graduate school of industrial administration, Carnegie Mellon University:Pittsburgh.

Muth, J. F. and Thompson, G. L. (1963). Industrial Scheduling.Englewood Cliffs, Prentice Hall, pages225–251.

Nowicki, E. and Smutnicki, C. (1996). A Fast Taboo Search Algorithm for the Job Shop.ManagementScience, 42:797–813.

Stecke, K. E. (1986). A hierarchical approach to solving machine grouping and loading problems of flexiblemanufacturing systems.European Journal of Operational Research, 24:369–375.

Storer, R. H., Wu, S. D., and Parks, I. (1992). Genetic algorithms in problem space for sequencing problems.Proceedings of a Joint US-German Conference on Operations Research in Production Planning andControl, pages 584–597.

Viana, G. V. R. (1998). Meta-heurısticas e programacao paralela em otimizacao combinatoria. EUFC, page250.

Wang, L. and Zheng, D. (2001). An effective hybrid optimization strategy for job-shop scheduling pro-blems.Computers and Operations Research, 28:585–596.

Zoghby, J., Barnes, W. L., and Hasenbein, J. J. (2004). Modeling the Reentrant job shop problem withsetups for metaheuristic searches.European Journal of Operational Research, 167:336–348.

Sistema Web para Gerenciamento do Acesso a um

Observatório Astronômico

Maiara Heil Cancian, Cesar Albenes Zeferino, Rafael Luiz Cancian, Roberto Miguel Torres

Centro de Ciências Tecnológicas da Terra e do Mar (CTTMar) Universidade do Vale do Itajaí (UNIVALI)

Rua Uruguai, 458 - Caixa Postal 360 – 88302-202 – Itajaí – SC Brazil

{maiara.heil, zeferino, cancian, torres}@univali.br

Resumo. Sistemas de informação baseados na Internet estão cada vez mais

presentes nos mais diferentes domínios. Uma das áreas de grande aplicação

consiste no acesso remoto a infra-estruturas de alto custo que podem ser

compartilhadas através da rede. Neste contexto, este artigo apresenta o

desenvolvimento de um sistema Web que será aplicado no acesso remoto a um

observatório astronômico a fim de ampliar o acesso a essa infra-estrutura que

possui alto custo de instalação e manutenção. O sistema permite que os

usuários agendem a aquisição de imagens astronômicas através de uma

interface Web e recebam essas imagens via e-mail, as quais são capturadas

automaticamente pelo telescópio do observatório.

1. Introdução

Na última década têm sido desenvolvidos diversos projetos de telescópios virtuais e telescópios remotos que visam permitir o compartilhamento do acesso a imagens astronômicas. A diferença principal entre os dois tipos de projeto reside no fato de que, em telescópios virtuais, é fornecido apenas o acesso remoto a uma base de dados de imagens já obtidas por telescópios, enquanto que, em telescópios remotos, é oferecida a possibilidade de controlar remotamente um telescópio real e obter novas imagens.

O Laboratório de Astrofísica da Universidade do Vale do Itajaí (UNIVALI) está implantando um observatório astronômico que poderá ser operado remotamente. Com o apoio da Petrobrás, já foi adquirida parte dos equipamentos necessários.

O presente trabalho desenvolveu um sistema Web para submissão, gerenciamento e atendimento de requisições de utilização remota do observatório. Esse sistema, doravante denominado Astra, possui uma interface Web, um módulo de cadastro dos usuários e um núcleo responsável pelo escalonamento e atendimento das requisições de acesso ao observatório. Tal núcleo utiliza diferentes critérios de escalonamento a fim de otimizar o uso dos recursos compartilhados.

O resultado principal desse projeto foi a ampliação do acesso à observação astronômica, pois o sistema permite o acesso remoto gratuito não apenas por parte de pesquisadores da área de astronomia, mas, especialmente, de jovens em fase escolar, estimulando o interesse científico desses alunos e fortalecento a astronomia observacional amadora.

Este artigo está estruturado em seis seções e apresenta uma descrição do sistema Web. A Seção 2 oferece uma breve descrição de trabalhos relacionados, com ênfase na

caracterização de alguns projetos de observatórios remotos. A Seção 3 apresenta a arquitetura do sistema Astra, enquanto que a Seção 4 descreve a sua funcionalidade. A Seção 5 apresenta aspectos relacionados à implementação do sistema e, concluindo, a Seção 6 apresenta as considerações finais.

2. Trabalhos Relacionados

Atualmente, existem diversos observatórios remotos e virtuais disponíveis com acesso via Internet. O AST/RO é um telescópio de 1,7 metros de diâmetro em operação em Amundsen-Scott, no pólo sul, desde 1995, e é gerenciado pelo Center for Astrophysical

Resourse in Antarctica (CARA). Todo o sistema AST/RO é altamente automatizado para reduzir ao mínimo a necessidade da intervenção humana e possibilitar sua utilização durante o inverno, período no qual a estação deve ser abandonada. Entretanto, o sistema é disponível para acesso remoto apenas para seus pesquisadores [CARA, 2002].

O observatório New Mexico Skies, no estado do Novo México (EUA), situa-se em uma área privilegiada, em termos de astronomia. O observatório possui uma ampla estrutura e faz uso de vários telescópios. Em sua página na Internet [Mike & Lynn Rice, 2005], são disponibilizadas, em tempo real, informações necessárias para observação astronômica, como velocidade do vento, temperatura, massa de ar, condições do céu, etc. Os telescópios desse observatório são alugados para o público, com taxas que variam de U$ 165,00 por dia a U$ 100,00 por hora.

O Observatório do Valongo [Werneck, Nader e Campos, 2004] é um Instituto do Centro de Ciências Matemáticas e da Natureza (CCMN) da Universidade Federal do Rio de Janeiro (UFRJ), que, em 2004, adquiriu, juntamente com outras cinco instituições astronômicas, um conjunto de equipamentos necessários para montagem de um observatório remoto (telescópio, câmera CCD, conjunto de filtros, etc.). Com a chegada do equipamento, foi feito o projeto da cúpula controlada por computador e hoje esse observatório já pode ser utilizado. Porém, a completa operação remota ainda não foi implementada pela ausência de uma interface adequada, impossibilitando que o observatório seja controlado remotamente.

Dos trabalhos descritos acima, nenhum deles contempla simultaneamente as duas principais características definidas para o observatório da UNIVALI: acesso remoto gratuito pela Internet e sem restrição ao tipo de público-alvo.

3. Arquitetura do Sistema Astra

A Figura 1 apresenta a arquitetura básica do observatório remoto a ser implementado na UNIVALI (a fotografia é apenas ilustrativa). Através da Internet, os usuários tem acesso ao observatório por meio do sistema Astra, em execução em um microcomputador instalado no local do observatório. O observatório contará ainda com um sistema computacional embarcado e uma estação meteorológica básica. O primeiro comandará os mecanismos de automação do observatório, enquanto que o segundo incluirá uma série de sensores para obtenção do estado das variáveis meteorológicas.

Internet SistemaEmbarcado

Estação Meteorológica

‘

Figura 1. Arquitetura básica do observatório remoto

A Figura 2 mostra uma estrutura em camadas do observatório remoto, com destaque aos módulos que constituem o sistema Astra (em cinza), desenvolvido em um trabalho de conclusão de curso [Heil, 2005]. Os usuários acessam o sistema através de uma interface Web. O núcleo do sistema é constituído pelos módulos: Gerenciador, Escalonador, Executor, Astrônomo, Temporizador e Meteorologista (cujas funcionalidades são descritas logo a seguir).

Driver do Sistema Embarcado

Observatório

Sistema Embarcado Estação Meteorológica

Gerenciador

Escalonador

Executor Astrônomo Temporizador Meteorologista

Interface Web

Usuário

Interface da Estação

Meteorológica

Sistema Astra

Figura 2. Arquitetura do observatório remoto e do sistema Astra

A Figura 3 mostra um diagrama de colaboração que ilustra as inter-relações entre os módulos componentes do sistema Astra, as quais são descritas após a figura.

Gerenciador Meteorologista

Executor

Astrônomo

Temporizador Escalonador

2

3

4

5

6

7

8

Interface Web

1

Figura 3. Diagrama de colaboração do sistema Astra

• Ligação 1: a Interface Web envia os parâmetros da requisição ao Gerenciador;

• Ligação 2: o Gerenciador invoca o Escalonador para executar o escalonamento da requisição;

• Ligação 3: o Escalonador invoca o Astrônomo para que ele verifique a consistência astronômica da requisição a fim de confirmar se o astro estará visível na data desejada e horário desejados;

• Ligação 4: o Escalonador invoca o Temporizador que irá se programar para despertar o Escalonador na data e na hora de atendimento da próxima requisição;

• Ligação 5: o Temporizador invoca o Escalonador quando chegar a data e hora da requisição a ser atendida;

• Ligação 6: caso o Escalonador tenha sido despertado para atender uma requisição, ele invoca o Executor, módulo responsável pelo envio de comandos de acionamento do observatório ao driver do sistema embarcado;

• Ligação 7: o Executor, ao ser ativado, invoca o Meteorologista para verificar se as condições meteorológicas estão adequadas para a realização da observação;

• Ligação 8: o Gerenciador invoca o Meteorologista quando precisar de informações meteorológica para alimentar o banco de dados ou quando um usuário requisitar informações meteorológicas atualizadas; e

Uma vez atendida a requisição, o Gerenciador envia uma mensagem de resposta ao usuário, contendo a(s) imagem(ns) associada(s) à requisição. Outros tipos de mensagem também podem ser enviadas, como, por exemplo, para informar o não agendamento de uma requisição ou o re-agendamento de uma requisição previamente escalonada, entre outras.

4. Funcionalidade do Sistema Astra

4.1 Submissão e Agendamento de Requisições

O sistema possui uma interface Web com um formulário eletrônico com campos de informações que deverão ser preenchidos pela pessoa/instituição que desejar utilizar o observatório. O usuário solicitará a submissão das informações desse formulário, que serão armazenadas em um banco de dados e marcadas como “cadastro pendente”. No momento adequado, o administrador avaliará os cadastros pendentes e decidirá pela sua aprovação ou rejeição. No primeiro caso, ele irá marcar o cadastro como “ativo” e atribuirá uma prioridade ao usuário, enquanto que, no segundo, ele irá excluir as informações do banco de dados. Após, o administrador irá notificar o usuário, o qual poderá acessar o sistema se o seu cadastro tiver sido aprovado.

Figura 4. Tela de cadastro de usuário

Para a submissão de requisições, o usuário deve efetuar o login no sistema. Uma vez autenticado, ele deverá preencher um formulário eletrônico com informações da sua requisição (nome e coordenadas do astro, data e hora da observação, filtro, etc.).

Figura 5. Tela de cadastro de requisição astronômica

Após a submissão do formulário, o sistema faz a validação desses campos. Caso todos os campos satisfaçam as condições impostas, a requisição é escalonada e o usuário recebe uma mensagem com a data e o horário nos quais a requisição será atendida. Caso existam problemas de validação, o sistema rejeita a requisição e o usuário recebe uma mensagem com o motivo dessa rejeição. As validações feitas pelo sistema no momento da solicitação da requisição são especificadas a seguir:

• O astro deve estar visível no horário escolhido,

• O horário escolhido para observação deve ser no período noturno,

• No formulário da requisição o usuário poderá fornecer o nome do astro ou as suas coordenadas.

Se na data e hora especificadas em uma requisição não houver nenhum outro agendamento, a requisição é agendada. Porém, se já houver uma requisição mais prioritária, a requisição é negada. Caso, na data e hora especificadas, houver uma

requisição com prioridade mais baixa, a requisição atual é agendada, e a menos prioritária é re-agendada e sua prioridade incrementada. Porém, se houver uma requisição idêntica quanto à observação a ser realizada (coordenadas, data e hora), é efetuado o agrupamento dessas requisições, sendo que o resultado da observação é enviado a todos os requisitantes.

4.2 Atendimento de Requisições

As requisições agendadas são escalonadas e a execução delas é disparada pelo módulo Temporizador. Durante a execução do atendimento de uma requisição, as seguintes funções são realizadas:

• Verificação das condições meteorológicas: O módulo Meteorologista faz a verificação da umidade, da velocidade do vento e das temperaturas interna e externa do observatório através de sensores da estação meteorológica ou mesmo de páginas Web com informações meteorológicas. Se os valores medidos estiverem dentro de limites definidos, dá-se continuidade ao atendimento, caso contrário, a requisição é re-agendada e o usuário notificado;

• Envio do comando de abertura da cúpula: Se as condições meteorológicas estiverem adequadas, então a cúpula do observatório é aberta. Este comando é enviado pelo módulo Executor ao driver do sistema embarcado;

• Envio do comando de calibração: Se esta for a primeira requisição a ser atendida no dia, o telescópio é ligado e faz uma calibração para identificar as coordenadas em que ele se encontra. Caso não seja a primeira requisição, nenhuma ação é tomada;

• Envio do comando de localização das coordenadas: O módulo Executor encaminha as coordenadas correntes do astro da requisição que é atendida ao driver do sistema embarcado. Este então aciona os mecanismos de posicionamento do telescópio;

• Captura da imagem: O módulo Executor envia ao driver um comando para que a câmera CCD acoplada ao telescópio realize a captura da imagem; e

• Envio da imagem por e-mail: O sistema recebe a imagem gerada pela câmera CCD e o módulo Gerenciador gera uma mensagem eletrônica que é enviada ao(s) usuário(s) que submeteu(ram) a requisição atendida.

5. Implementação

O sistema foi implementado utilizando as seguintes tecnologias/linguagens: (i) Sistema Operacional Windows ; (ii) Interface Web implementada em linguagem PHP; (iii) Banco de dados Paradox 7; e (iv) Núcleo implementado em linguagem C++.

5.1 Desenvolvimento do Sistema

O sistema desenvolvido possui dois processos independentes. O primeiro consiste de um gerador de interface Web para interação com os usuários remotos. O segundo consiste do núcleo do sistema, que é responsável por realizar as tarefas relacionadas à

execução das requisições dos usuários. A comunicação entre os dois processos é feita através de sockets.

O acesso ao sistema dá-se através da internet, digitando uma URL (Universal Resource Locator) como, por exemplo, http://www.observatorio.univali.br/cgi-

bin/astraWeb.exe/index. Através de mecanismos de roteamento da internet, a primeira parte da URL (http://www.observatorio.univali.br) é avaliada e a solicitação HTTP (Get, Post, Put) chega à máquina destino, onde um servidor Web aguarda conexões no port 80 (padrão do protocolo HTTP). O servidor Web (Apache, por exemplo) recebe a solicitação e invoca o programa especificado na segunda parte da URL (/cgi-

bin/astraWeb.exe). Este programa, denominado aqui de AstraWeb, tem sua execução iniciada a cada nova solicitação HTTP e recebe a última parte da URL, denominada caminho ou path (/index). Com base nesse caminho, esse programa deve tomar as ações necessárias e gerar a resposta adequada à solicitação.

Como o programa invocado pelo servidor Web terá múltiplas instâncias em execução, e sendo isso indesejável ao núcleo do sistema Astra, o programa AstraWeb é apenas um interceptador de solicitações Web, e sempre que necessário comunica-se com outro processo independente, o AstraKernel, que compreende o núcleo do sistema Astra. Deste modo, pode haver inúmeras instâncias do AstraWeb em execução, mas uma única instância do AstraKernel. Outro motivo para ter-se dois programas independentes é que o núcleo “acorda” em instantes específicos para executar as requisições já cadastradas ou para armazenar as condições meteorológicas atuais, e não pode depender da existência de solicitações HTTP para executar.

Embora o sistema deva executar de maneira independente das solicitações HTTP, ele também deve ser capaz de atendê-las rapidamente, uma vez que há um timeout ou deadline associado às solicitações. Uma solução seria fazer uma varredura periódica. Entretanto, além de imprecisa, essa solução é ineficiente e teria um alto custo de desempenho. Assim, optou-se pela separação do atendimento às solicitações Web e geração das páginas HTML de resposta (responsabilidade do AstraWeb) do processamento e escalonamento das requisições de observação astronômica (responsabilidade do AstraKernel). A comunicação entre esses programas é assíncrona e é realizada através de sockets TCP.

O AstraWeb reside na pasta cgi-bin do servidor Web da máquina (normalmente c:\apache\cgi-bin) e é invocado a cada nova solicitação HTTP. Basicamente, ele transmite a solicitação via socket TCP para o núcleo do Astra que realiza o tratamento e envia informações de retorno de volta ao AstraWeb através da mesma conexão TCP. Deste modo, uma única instância do AstraKernel permanece sempre executando. Para evitar a verificação periódica de requisições TCP, o núcleo do Astra cria um socket

servidor (port 5000) que é ativado apenas quando há uma nova solicitação. Se houver muitos usuários conectados à internet gerando solicitações ao sistema, pode ser inaceitável haver um único núcleo atendendo tais requisições. Portanto, assim como em implementações normais de socket servidores, cada conexão aceita pelo núcleo do Astra cria uma nova thread específica para atendê-la.

5.2 Algoritmos Usados no Escalonamento de Requisições

No sistema Astra, o agendamento das requisições de observações astronômicas faz uso de características de diversos algoritmos de escalonamento tipicamente adotados em sistemas computacionais [Silberchatz, 2000] e [Cancian, 2000]. Basicamente, ele tem que ser capaz de lidar com múltiplas requisições e agendar corretamente a execução dessas requisições com base em critérios específicos. Em especial, destaca-se que cada usuário do sistema tem um nível de prioridade definido pelo administrador, o qual é considerado durante o escalonamento. No caso de mais de uma requisição de usuários com mesma prioridade, o sistema os atende por ordem de chegada (algoritmo FIFO - First-In, First-Out). No caso de existir uma requisição com tempo exato para atendimento (ex. eclipse solar), é usado o algoritmo EDF (Earliest Deadline First). Também são usados algoritmos específicos para minimizar os movimentos do telescópio. Como o telescópio movimenta-se de modo semelhante a um cabeçote de leitura/gravação de um acionador de disco rígido, em algum momento que o telescópio estiver fazendo um trajeto para obter uma imagem, ele poderá executar outra requisição que esteja em seu caminho. Esse gerenciamento utiliza características dos algoritmos SSTF (Smallest Seek Time First) e SCAN.

6. Testes e Validações

Os testes do núcleo do Astra foram realizados fazendo simulações com os drivers, gerando valores aleatórios de condições meteorológicas. A interação com a parte física do observatório também foi simulada, gerando mensagens para informar o administrador quando a cúpula estivesse aberta ou fechada. Desta forma, a requisição era submetida ao sistema, os drivers simulados e as consistências realizadas.

Na figura 6 é mostrada a tela do sistema em que foram realizados os testes dos drivers, da temporização, envio de e-mail ao usuário e simulação de visualização da imagem do telescópio.

Figura 6. Tela do sistema de teste dos drivers da estação e do observatório

Já os testes ao acesso ao sistema Astra envolveram duas etapas distintas: (i) Teste de execução do AstraWeb a partir de um browser e a geração de uma página HTML de resposta; e (ii) comunicação via socket TCP entre os programas AstraWeb e o AstraKernel.

Para a realização do primeiro teste, iniciou-se o servidor Apache na máquina que continha a aplicação AstraWeb. Com o servidor executando, invocou-se a aplicação através de navegadores Internet Explorer, tanto da própria máquina quanto de outras máquinas conectadas à internet. Em todos os casos obtinha-se, na janela do navegador utilizado, as páginas HTML geradas pelo AstraWeb. A Figura 7 apresenta uma parte da tela do sistema onde pode-se ver o resultado de uma solicitação no navegador, com destaque à URL digitada.

Figura 7. Acesso ao sistema Astra

Em relação ao segundo teste, foram criadas duas aplicação (cliente e servidor) que se comunicam via socket, No exemplo abaixo, o cliente envia uma mensagem ao servidor, que identifica o cliente e recebe a mensagem, conforme Figura8.

Figura 8. Aplicação cliente e servidor

Após todos os testes comprovando o funcionando isolado de seus módulos, foi realizada a integração do sistema, que mostrou-se totalmente funcional. Assim, o Astra já pode ser utilizado para gerenciar requisições remotas a um observatório e comandar os dispositivos de automação desse observatório para que seu telescópio capture as imagens requisitadas. Para sua disponibilização final, aguarda-se apenas a aquisição dos demais componentes físicos (cúpula, câmera CCD, sensores, motores, etc) para a construção do observatório.

7. Considerações Finais

Este artigo apresentou o sistema Astra, que é um sistema Web para gerenciamento de acesso remoto a um observatório astronômico. Foram abordados os principais aspectos dos requisitos de seu funcionamento e testes para sua validação.

O desenvolvimento do sistema Astra está concluído e encontra-se totalmente funcional, embora melhoramentos e a inclusão de novas funcionalidades, como a utilização remota em tempo real do observatório, tenham sido detectados e devem ser implementados no futuro.

O sistema Astra faz parte de um projeto maior, que visa a construção de um observatório que possa operar autonomamente. Assim, apesar de concluído, o Astra depende que outros projetos paralelos, como os que implementam o sistema embarcado para controle da estação meteorológica e da cúpula do observatório sejam também concluídos e que o observatório seja efetivamente construído, para que o sistema seja disponibilizado.

Referências

Boczko, R. (1984) “Conceitos de Astronomia”. São Paulo, E. Blücher.

Silberchatz, A.; Galvin, P.B. (2000) “Sistemas Operacionais Conceitos”. São Paulo, Prentice Hall.

Cancian, R. L. (2000) “Avaliação de Desempenho de Algoritmos de Escalonamento e Tempo Real para o Ambiente de Multicomputador CRUX”. 2001. 174 p. Dissertação de Mestrado em Ciência da Computação – Universidade Federal de Santa Catarina, Florianópolis.

CARA (2002) “Center for Astrophysical Resourse in Antarctica”, Disponível em: <http://astro.uchicago.edu>. Acesso em: 28 de julho de 2005.

EOS (2002) “Robotics Observatory Control System: the complete autonomous robotic control system”, Queanbeyan, Electro Optic Systems Pty Limited.

Heil, Maiara (2005) “Sistema Web para Gerenciamento de Requisições de um Observatório Remoto”.

Mike & Lynn Rice (2005) “New México Skies”. Disponível em: <http://www.nmskies.com/weather.html>. Acesso em: 28 de julho de 2005.

Observatórios Virtuais (2005) “Observatórios Virtuais: Projeto Educacional na área de Ciências envolvendo instituições de pesquisa em Astronomia e escolas de ensino médio e fundamental”. Disponível em: <http://www.observatoriovirtual.pro.br/index.htm>. Acesso em: 28 de julho de 2005.

Társia, R. D. (1993) “Astronomia Fundamental”, Belo Horizonte, UFMG. 248 p.

Werneck, L. S., Nader, R. V. e Campos, J. A. S. (2004) “O Telescópio Remoto do Observatório do Valongo”, In: Boletim da Sociedade Astronômica Brasileira, Editado por Vera A. Fernandes Martin, Rio de Janeiro, UFRJ, 2004. p. 189-189.

Teorema Fundamental da Aritmetica e Numeros de GodelAplicados a Criptografia

Vilson Vieira da Silva, Jr.1, Claudio Cesar de Sa1, Rafael Stubs Parpinelli1,Charles Christian Miers1

1Universidade do Estado de Santa Catarina (Udesc) – Centro de Ciencias TecnologicasCampus Universitario Prof. Avelino Marcante s/n – Bairro Bom Retiro

CEP 89223-100 – Joinville – SC – Brasil

vilson@void.cc, {claudio, parpinelli, charles}@joinville.udesc.br

Resumo. Atraves da uniao do Teorema Fundamental da Aritmetica e do con-ceito formal de numero de Godel, proposto pelo mesmo matematico que lhe danome, busca-se o desenvolvimento de um algorıtmo criptografico e sua poste-rior analise. Para isso e criada uma aplicacao real, que demonstra os princıpiosteoricos nos quais solucoes praticas e populares sao desenvolvidas, como o al-gorıtmo de criptografia para geracao de chaves publicas RSA1.

1. Introducao

A criptografia moderna utiliza de diversos metodos para a criacao de algorıtmos cada vezmais confiaveis na codificacao de dados.

Em sua maioria, tais metodos estao baseados em propriedades de teoremas ma-tematicos. Desta forma, propoe-se analisar a aplicacao de um destes teoremas, o Teo-rema Fundamental da Aritmetica, que usado como axioma em um conceito formal, cri-ado pelo matematico Kurt Godel [Hintikka 1999], revela-se como base para algorıtmoscriptograficos.

Permite-se ainda analisar tal algorıtmo na forma de uma aplicacao pratica, com odesenvolvimento de um software de codificacao de dados.

O artigo esta organizado da seguinte forma: na sessao 2 e apresentado o TeoremaFundamental da Aritmetica, a sessao 3 apresenta os numeros de Godel, assim como suadefinicao matematica. A sessao 4 une os conceitos dos teoremas apresentados em umaaplicacao pratica ligada a criptografia e conclui o artigo atraves de sua analise.

2. O Teorema Fundamental da Aritmetica

O Teorema Fundamental da Aritmetica (TFA) [Mollin 1998], inicialmente provado porEuclides2 enuncia:

Para todo numero natural n maior que 1, ou este e um numero primo, ou podeser escrito como um produto de numeros primos, de maneira unıvoca.

1Iniciais do sobrenome de seus criadores: Ron Rivest, Adi Shamir e Len Adleman2A prova foi generalizada e tornada correta posteriormente pelo matematico Carl Friederich Gauss

Por exemplo:

2100 = 22 × 31 × 52 × 71 (1)

A ordem dos fatores, pela propriedade comutativa da multiplicacao, e irrelevante.

O que torna tal teorema interessante e a garantia de obtencao de uma representacaounica para todo e qualquer numero natural. Isso abre diversas possibilidades de aplicacao,como em criptografia, onde um texto pode ser codificado como uma sequencia de numerosprimos.

3. Os Numeros de Godel

Kurt Godel, em 1931, deu um grande passo para para a evolucao da matematica com seuTeorema da Incompletude [Godel 1931]. Para a prova de tal teorema, Goedel precisou deuma abstracao, uma formalizacao que o possibilitasse trazer ao seu campo de domınio –a teoria dos numeros [Andrews 1995] – toda e qualquer sistema formal. Desta maneira,poderia “operar” sobre tais sistemas com regras aritmeticas, botando-os em prova, ana-lisando suas caracterısticas, testando portanto sua completude, o objetivo primordial desua tese.

Este propos entao os Numeros de Godel [Hofstadter 1989], um conceito formala partir da teoria dos numeros.

3.1. Definicao

Os Numeros de Godel (NG) sao definidos por uma funcao que designa um numero naturala cada sımbolo ou formula de alguma linguagem formal e a potencia destes numerosprimos seguindo a posicionalidade na palavra ou texto. A estes numeros naturais da-se onome de Numeros de Godel.

Portanto, tendo um conjunto contavel S, pode-se definir a funcao de geracao deNumeros de Godel (funcao de numeracao de Godel) por:

f : S → N

Como para S pode-se ter qualquer conjunto de elementos contaveis, toda e qual-quer linguagem formal pode ser convertida para uma representacao no domınio dosnumeros naturais.

Para exemplificar, deseja-se criar um Numero de Godel para a palavra abba.Definindo-se o conjunto S por S = { a, b } pode-se ter a seguinte funcao de mapeamento

aos numeros naturais:

f(a) = 1 (2)f(b) = 2 (3)

Agora, como metodo de concatenacao de sımbolos, Godel utilizou a estrategiade usar os sımbolos (ja convertidos para numeros naturais) como expoentes de umasequencia de numeros primos, onde cada sımbolo ocupa o expoente de um unico numeroprimo. Portanto, para a palavra abba se tem a representacao numerica dada por:

NGabba = 21 × 32 × 52 × 71 = 3150

Define-se assim uma relacao entre o alfabeto de S com os numeros naturais, ondea palavra abba constitui o NG 3150, de forma unıvoca.

Os NG sao portanto unicos e representam numericamente uma palavra de um sis-tema formal qualquer. Haja visto que esta representacao se faz por produto de numerosprimos, que por si so sao de difıcil busca por metodos computacionais, tem tal dificuldadeaumentada pelo fato desta representacao ter grande complexidade espacial, fazendo cres-cer o tamanho do NG de maneira exponencial, devido ao produto dos numeros primosdesta sequencia.

4. TFA e NG Aplicados a Criptografia

4.1. Criptografia

Sempre foi desejo do homem manter em seguranca certas informacoes. A criptogra-fia [Schneier 1995] e uma das mais importantes disciplinas por tras desta seguranca. Esta,atraves da matematica e da ciencia da computacao, pode criar metodos muito eficientesde codificacao e decodificacao, com alto grau de confiabilidade.

Um destes metodos baseia-se no aproveitamento de certas caracterısticas encon-tradas em teoremas matematicos. Tal estrategia e usada como base, por exemplo, paraum dos sistemas criptograficos mais populares da atualidade: a criptografia por chavespublicas [Choudhury and Choudhury 2002].

Nesta tecnica, sao usados numeros primos e formulas matematicas para a geracaode uma chave publica e privada, unicas para cada indivıduo. Ao se comunicar, os in-divıduos trocam suas chaves publicas. A partir daı, uma mensagem codificada pelo donoda chave publica so podera ser aberta com a chave privada deste. Assim, se um indivıduodeseja enviar uma mensagem ao destinatario, devera usar a chave publica do destinatario

para codificar a mensagem, que so podera ser aberta pelo destinatario e ninguem mais,nem mesmo o proprio emissor.

Um exemplo de algorıtmo gerador de chaves publicas e privadas e o popularRSA [Rivest et al. 1978], criado em 1978 por Ronald Rivest, Adi Shamir e Len Adle-man, e utilizado na codificacao em protocolos seguros como SSL 3 [Rescorla 2000] e nacriacao de certificados de seguranca para servicos de risco como as redes virtuais privadas,VPN 4 [Holden 2003].

4.2. FormulacaoAs caracterısticas dos Numeros de Godel e do Teorema Fundamental da Aritmetica possi-bilita a criacao de um algorıtmo de criptografia baseado em chaves. Dos NG, tal algorıtmoherda a funcao numeradora, que unida com a propriedade da univocacidade garantida peloTFA, proporciona a geracao de numeros naturais unicos para cada sımbolo ou combinacaodestes. Alem disso, garante-se tambem a operacao inversa, onde tais numeros gerados po-dem ser convertidos novamente aos seus sımbolos originais, haja visto que a fatoracao edada pela sequencia 2i × 3j × 5k × 7l × ....

Assim a proposta e fazer uma codificacao usando os NG e uma decodificacaoatraves da fatoracao destes. Portanto, define-se o algorıtmo que implementa estasoperacoes:

Codificacao

1. Tendo-se como entrada 〈w, C 〉 sendo w ∈ L( S ) e C = { ( x , y ) |x ∈ S, y ∈N, f( x ) = y } (a chave codificadora), onde L( S ) = {x+ |x ∈ S } e S ={ a, b } (alfabeto da palavra a codificar);

2. Para cada elemento i da palavra w, toma-se seu par ( i , yi ) da relacao definida nachave C;

3. Encontra-se o NG pela multiplicacao da sequencia de numeros primos dado porNG = 2y1 × 3y2 × 5y3 × ... × pyn

n , onde p e o consecutivo numero primo nvalido e n o tamanho da palavra w.

Decodificacao

1. Tendo-se como entrada 〈 g, C 〉 sendo g ∈ N (um numero de Godel) e C a chavecriptografica usada na codificacao;

2. Fatora-se g (aqui aplicando o metodo recursivo):(a) Se g e um primo, retorna-o. Senao, g′ = g

pisendo pi um numero primo i

consecutivo;(b) Se a divisao nao gerar resto, adiciona pi a lista Lg e fatora g′. Caso

contrario, g′ = gpi+1

e assim sucessivamente, ate obter uma divisao semresto.

3Secure Sockets Layer4Virtual Private Network

3. A lista Lg contem g fatorado. Conta-se, para cada elemento j de Lg, a quantidadede elementos iguais a j. O valor desta contagem valora kj;

4. Para cada kj encontrado, toma-se seu par ( j, kj ) da relacao definida na chave C;5. Encontra-se a palavra w, formada pela concatenacao dos kj calculados.

4.3. Aplicacao

A partir dos algorıtmos de codificacao e decodificacao por TFA, pode-se desenvolverum software que implementa tal sistema criptografico. O aplicativo foi desenvolvidobuscando-se certa eficiencia, mesmo que somente para a demonstracao do metodo. Paratal, utilizou-se a linguagem de programacao C [Kernighan and Ritchie 1978]. Ainda, paraas operacoes de fatoracao e multiplicacao de numeros naturais, utilizou-se a bibliotecaPARI, componente do sistema de computacao algebrica PARI/GP 5.

Optou-se pelo uso desta biblioteca devida a necessidade da computacao de gran-des valores numericos.

Para a execucao do software necessita-se, para a codificacao, de duas entradas: oarquivo texto contendo a chave (chave.txt, neste exemplo) e uma palavra que sera codifi-cada (original.txt). Para a decodificacao, ainda e necessaria a chave e o numero naturalque sera fatorado (criptografado.txt).

O arquivo texto que abriga a chave possui o formato 〈sımbolo codigo〉, ondesımbolo e qualquer caractere ASCII e codigo um numero natural maior ou igual a zero.Como exemplo:

a 1b 2

As codificacoes sao realizadas pelo parametro -c e as decodificacoes por -d. Umexemplo de execucao seria:

./goedel -c chave.txt < original.txt > criptografado.txt

Ainda, o parametro -s leva a execucao do show mode, que apresenta todos ospassos realizados na codificacao e decodificacao de uma palavra dada. Por exemplo:

5PARI/GP: http://pari.math.u-bordeaux.fr

./goedel -s chave.txt < original.txt

*** CODIFICACAO

entrada = aaba

fatoracao = 2ˆ1 3ˆ1 5ˆ2 7ˆ1

codificado = 1050

*** DECODIFICACAO

saida = aaba

A aplicacao esta disponıvel no repositorio (http://mov.void.cc/archives/goedel-0.2.tar.bz2) sobre a licenca publica GPL 6. Maiores informacoes sobre sua instalacao euso encontram-se no arquivo README do pacote distribuıdo.

4.4. Analise

A criptografia moderna considera eficiente os algorıtmos de codificacao/decodificacaocujo tempo computacional requerido para sua execucao e impraticavel por computadorespessoais e ate mesmo por super-computadores [Mao 2003].

Pensando desta forma, o metodo utilizado fornece uma demonstracao do poderdado pelos numeros primos no desenvolvimento de algorıtmos de criptografia.

O software produzido nao suporta a codificacao de uma palavra de entrada muitogrande, haja visto que para cada elemento desta palavra, e necessario um numero primoque o “represente”, tendo-se portanto alta complexidade espacial. Alem disso, para umaquantidade grande de sımbolos, os expoentes de tais numeros primos serao compostospor valores de varios dıgitos, o que aumentara ainda mais o tempo de processamento, altacomplexidade temporal.

Se por um lado isto lembra erroneamente ineficiencia, por outro leva acomprovacao de que a quebra de uma chave criptografica gerada por estrategias seme-lhantes a empregada, e praticamente impossıvel, somente conseguida pelo uso de novastecnicas de processamento [Ord 2002], e ainda nao comprovadas.

6GNU General Public License:http://www.fsf.org/licensing/licenses/gpl.txt

5. ConclusoesO Teorema Fundamental da Aritmetica revelou fatos interessantes. Aplica-lo como axi-oma para os Numeros de Godel, fez propor um metodo criptografico, que apesar de poucoeficiente, demonstra a base na qual algorıtmos de criptografia massivamente usados atu-almente sao desenvolvidos.

Ainda, descobriu-se que a propriedade da incompletude dos sistemas formais,descoberta e provada por Kurt Godel dos Numeros de Godel, nao e somente uma ca-racterıstica de ineficiencia de algorıtmos. Nota-se que se vista de um novo angulo, oda criptografia moderna, revela-se como um identificador nao da ineficiencia, mas daeficiencia de seguranca de algorıtmos criptograficos. Quanto mais os computadores saoincapazes de quebrar as chaves criadas por estes algorıtmos, mais tempo estes perduraraocomo padroes de codificacao.

O software desenvolvido permitiu analisar de maneira pratica a teoria aqui desen-volvida. Comprovou-se a dificuldade da decodificacao de uma mensagem criptografada,pela fatoracao em termos de numeros primos de um numero natural de milhares de casasdecimais.

Enfim, de axioma para aplicacao em novos teoremas, a base para o desenvolvi-mento de solucoes praticas, o Teorema Fundamental da Aritmetica prova que as teoriaspodem ser usadas para uma gama de aplicacoes, e nao somente destinadas a hipoteses naoimplementadas.

ReferenciasAndrews, G. E. (1995). Number Theory. Dover Publications, 1st edition.

Choudhury, S. and Choudhury, S. (2002). Public Key Infrastructure and Implementationand Design. Wiley, 1st edition.

Godel, K. (1931). Uber formal unentscheidbare satze der principia mathematica undverwandter systeme, i. Mathematik und Physik, 38.

Hintikka, J. (1999). On Godel. Wadsworth Publishing, 1st edition.

Hofstadter, D. R. (1989). Godel, Escher, Bach: An Eternal Golden Braid. Vintage Books,1st edition.

Holden, G. (2003). Guide to Firewalls and Network Security: Intrusion Detection andVPNs. Course Technology, 1st edition.

Kernighan, B. and Ritchie, D. (1978). The C Programming Language. Prentice Hall, 1stedition.

Mao, W. (2003). Modern Cryptography: Theory and Practice. Prentice Hall, 1st edition.

Mollin, R. A. (1998). Fundamental Number Theory with Applications. CRC-Press, 1stedition.

Ord, T. (2002). Hypercomputation: computing more than the turing machine. HonoursThesis, University of Melbourne.

Rescorla, E. (2000). SSL and TLS: Designing and Building Secure Systems. Addison-Wesley Professional, 1st edition.

Rivest, R., Shamir, A., and Adleman, L. (1978). A method for obtaining digital signaturesand public-key cryptosystems. Communications of the ACM, Vol. 21 (2), pp.120-126.

Schneier, B. (1995). Applied Cryptography: Protocols, Algorithms, and Source Code inC. Wiley, 2nd edition.