Arquivo completo com todo o volume dos Anais - Departamento de ...

inf.furb.br

Arquivo completo com todo o volume dos Anais - Departamento de ...

Ficha Catalográfica Elaborada pela Biblioteca da FURBSeminário de Computação (15.: 2006 : Blumenau, SC)Anais do XV SEMINCO / promoção Universidade Regional de Blumenau, Departamentode Sistemas e Computação; Everaldo Artur Grahl, Jomi Fred Hübner (coordenadores).- Blumenau, O Departamento, 2006. 228 p. : il.1. Computação - Congressos. I. Grahl, Everaldo Artur. II. Hübner, Jomi Fred. III.Universidade Regional de Blumenau. Departamento de Sistemas e Computação. IV.Título.CDD 004Universidade Regional de BlumenauReitorProf. Eduardo DeschampsVice-ReitorProf. Romero FeniliDiretor do Centro de Ciências Exatas e NaturaisProf. Sérgio StringariChefe do Departamento de Sistemas e ComputaçãoProf. Mauro Marcelo MattosCoordenador do Colegiado do Curso de Ciências da ComputaçãoProf. Alexander Roberto ValdameriCoordenador do Colegiado do Curso de Sistemas de InformaçãoProf. Francisco Adell Péricas


Comissão de Avaliação InterinstitucionalAdelmo 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)Cláudio 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 Osório (UNISINOS - RS)Francisco Adell Péricas (FURB - SC)Gerson Cavalheiro (UNISINOS - RS)Giovane Roslindo Kuhn (UFRGS - RS)Gustavo G. Lugo (FACET - PR)Jomi Fred Hübner (FURB - SC)José 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 Inés Castiñeira (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)Tiarajú Diverio (UFRGS - RS)Valguima Victoria Vianna Aguiar Odakura (USP - SP)Vera R. N. Schuhmacher (UNISUL - SC)


Um RPG Educacional Computadorizado e Missões Contextualizadascom seus Ambientes85Michele A. Tobaldini e Jacques D. Brancher (URI)Sistema Integrado e Visualização de Conteúdos de 5 a à 8 a SériesUtilizando X3D97Luis Biondo, André Brandão, Michele Tobaldini e Jacques Brancher (URI)Uma Experiência de Ensino-Aprendizagem em uma disciplina deProgramação109Mauricio Capobianco Lopes (FURB)Inteligência ArtificialUma Abordagem Inspirada em Insetos Sociais para a Otimização daDensidade de Redes de Sensores Sem Fio119Carlos Drumm (FEEVALE) e Paulo Roberto Ferreira Jr. (UFRGS)Evolução do Caminhar de Robôs Móveis Simulados UtilizandoAlgoritmos Genéticos131Milton Roberto Heinen e Fernando Santos Osório (UNISINOS)AS-MCOE: Tutor inteligente modelado em AgentSpeak(L) 143Rodrigo R. V. Goulart e Alexandre O. Zamberlam (FEEVALE)AISO-GT: Um Novo Algoritmo Híbrido de Otimização Baseado nosSistemas Imunológicos Artificiais e na Teoria dos Jogos155André Ferry Barreira (CESUPA), Carlos Eduardo de Jesus Guimarães Oliveira(CESUPA), Otavio Noura Teixeira (CESUPA) e Roberto Célio Limão deOliveira (UFPA)Integração Hardware/SoftwareAstroFácil: Sistema Computacional Embarcado para Automatizaçãode Telescópios de Pequeno Porte165Marcos Roberto Silva, Maicon Carlos Pereira, Caroline Farias Salvador, RafaelLuiz Cancian, Roberto Miguel Torres e Cesar Albenes Zeferino (UNIVALI)


Aplicativo Controlador de Potência de Pseudo-Satélite e SuasAplicações177Luiz Eduardo Guarino de Vasconcelos, Durval Zandonadi Jr., FernandoWalter e Jorge Tadano (CTA)Rede de ComputadoresDesempenho de Multicast em Redes Altamente Interconectadas 189Fernando Teubl Ferreira e Sergio Takeo Kofuji (USP)Sistemas de InformaçãoEstratégias de Escalonamento em um Ambiente de Job-shop 201Gilberto Irajá Müller e Arthur Tórgo Gómez (UNISINOS)Sistema Web para Gerenciamento do Acesso a um ObservatórioAstronômico209Maiara Heil Cancian, Cesar Albenes Zeferino, Rafael Luiz Cancian e RobertoMiguel Torres (UNIVALI)Teoria da ComputaçãoTeorema Fundamental da Aritmética e Números dedel Aplicados àCriptografia221Vilson Vieira da Silva Jr., Claudio Cesar de Sá, Rafael Stubs Parpinelli eCharles Christian Miers (UDESC)


Utilizando o 3D Studio Max como Level Editor paraConstrução de Cenários para Ogre3DJorge. L. Salvi, Maikon. C. Santos, Jacques. D. BrancherDepartamento de Engenharias e Ciência da Computação – Universidade RegionalIntegrada do Alto Uruguai e das Missões (URI) – Erechim, RS – Brasiljlsalvi@hotmail.com, maikoncs@gmail.com, jacques@uri.com.brResumo. O objetivo deste artigo é apresentar a estratégia adotada paraconstrução de cenários dinâmicos e estáticos para o jogo “Taltun: A terra doconhecimento”. A proposta foi elaborar cenários através do uso do programade modelagem, o 3D Studio Max, e exporta-los diretamente para a engine dojogo sem a necessidade de se desenvolver ou fazer uso de um level editorespecial para elaborar as fases do jogo.1. IntroduçãoA utilização de editores de fases (level editor) é o meio mais comum para odesenvolvimento de fases em jogos de computador. Segundo Rouse III [2000] o leveleditor tem grande importância no desenvolvimento de um jogo porque permite aodesigner montar suas fases através da movimentação dos objetos em 2D enquanto elespodem ser visualizados em um mundo 3D, obtendo assim, uma perspectiva do final dafase do jogo.Com a utilização do level editor é possível inserir elementos gráficos (estáticosou 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 aoambiente a ser criado. Segundo Clua e Bittencourt [2005] as manipulações básicas sãoas seguintes: seleção, translação, rotação e escalonamento.Como geralmente um level editor é desenvolvido especialmente para uma únicaengine e seu desenvolvimento consome um tempo considerável, torna-se fundamental,em projetos de curto espaço de tempo, que os programadores tenham seu tempoenfocado na codificação da engine. No entanto, uma maneira de contornar esteproblema é adaptar as ferramentas de trabalho já existentes para a confecção doscenários, neste caso a ferramenta de modelagem 3DS Max.Nas próximas seções serão apresentados os trabalhos correlatos, as ferramentasutilizadas para a confecção deste trabalho e em seguida como foi projetado e comofunciona o level editor em questão.2. Trabalhos RelacionadosA maioria das engines de jogos populares possuem editores de fases para possibilitaraos usuários a modificação das características das mesmas assim como a criação denovas delas. Segundo El-nasr e Smith [2006] o processo de modificação e criação defases é conhecido como modding.


Dentre os editores de fases mais conhecidos podemos citar os dos jogosWarCraft III [2006] e Half Life 2 [2006] e da engine 3D Game Studio [2006]. Todoseles possuem características idênticas em seus editores, mas, além disso, eles podempossuir também outros artefatos que implementam suas funcionalidades, tais comoeditores de triggers e de sons.Já na engine Yake [2006], o uso do 3DS Max torna-se fundamental. Isto ocorredevido ao fato de ela conter plugins responsáveis por exportar as propriedades docenário modelado em um arquivo XML. A partir disso, o loader de gráfico (OGRE) ede física (ODE ou Novodex) buscam as propriedades exportadas a fim de construir acena 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 paraa engine de seu jogo. Para isso foram usadas as características existentes no 3D Max ecustomizadas através da criação de plugins e scripts, os quais tornam possível a criaçãode fases para jogos de computador.3. Ferramentas UtilizadasPara 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 decená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 criaranimaçõ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 daengine 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éricoque pode ser incorporado a outras bibliotecas...” Maior [2005] dando assim suporte aodesenvolvimento de jogos 3D.Ainda, para dar maior dinamismo e realismo ao jogo, é utilizada uma API defí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 decolisã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 baixonível utilizados em jogos e em outras aplicações. Atualmente na versão 0.4 suportasomente a biblioteca ODE (Open Dynamics Engine) e em atual desenvolvimento darásuporte a TrueAxis (True Axis Physics SDK).4. O 3DS Max como Level EditorPara Watsa [2001] uma das razões para se utilizar o 3DS Max como level editor é areutilização das suas janelas de visualização. Outro motivo de seu uso é oaproveitamento das propriedades dos objetos modelados e o uso dos eventos demanipulação.


Entretanto, para se produzir um cenário completo para o jogo são utilizados osrecursos citados acima. Também é necessário seguir uma seqüência de passosespecificados 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 dapresente cena que em seguida será exportada através dos plugins do 3DS Max. Comisso serão gerados os arquivos que contêm as informações dos objetos e da cena a fimde serem carregados pelo loader da engine.Com o final do processo de loader, obtém-se um ambiente com objetosdinâ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 pluginPara que os objetos modelados usados na construção de cenários contenham aspropriedades necessárias para atribuir física e gráficos foi preciso desenvolver umplugin para o 3DS Max. Este plugin foi desenvolvido para funcionar com o 3D StudioMax 6 e está dividido em duas partes: o modificador e o exportador, conformeapresentado na Figura 2. Cada um deles trabalha de forma distinta, sendo que oprimeiro é responsável por adicionar novos atributos ao objeto, já o último exporta osatributos 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 à sualista de modificadores o elemento “Opal Scene”, que se refere à primeira parte doplugin. Com este modificador são acrescentados novos atributos ao objeto, que servempara configurar as propriedades de física a ser aplicada ao objeto quando carregado aojogo.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ãofeitos através de caixas de colisão, que formam uma espécie de labirinto, no qual ojogador apenas poderá navegar entre elas, conforme apresentado na figura a seguir.Figura 3: Exemplo de utilização do plugin para criação dos limites paranavegação do personagem.Após a configuração de todos os objetos que irão compor a cena então é feito ouso da segunda parte do plugin: o exportador. Este tem como escopo gerar um arquivoXML que conterá as informações aplicadas com o modificador e também informaçõesrelacionadas coordenadas gráfica do objeto em questão. Um exemplo de XML geradopelo 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 dentroda cena. Este nodo contém atributos referentes à sua posição, rotação, escala, dimensãoe raio (quando vem ao caso). A partir destes atributos é que o objeto especificado na tagentidade 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 ouestático, o tipo de renderização (somente gráfico, somente física ou ambos) e outraspropriedades 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 loaderLogo após a exportação das especificações para a criação do ambiente virtual, contidosno arquivo XML gerados pelo plugin, começa a etapa final do processo, no qual carregaas informações contidas no arquivo e cria os objetos que irão compor a cena conforme oque foi modelado no 3DS Max.Um ambiente é formado por um ou vários nodos (objetos). O loader tem comoponto partida o caminho do arquivo XML, fazendo a leitura dos dados e armazenandoem memória as informações de cada nodo para que os mesmos possam ser criados nofuturo.A criação dos nodos pode ser feita de modo flexível e dinâmico, tendo apossibilidade de criar, tanto objetos em tempo de execução da aplicação (durante ojogo), quanto no carregamento da cena. Além disso, o loader fornece suporte paracriação de todos os nodos em um único comando ou ainda através do índice ou nome decada elemento.


O processo de criação de um nodo envolve dois elementos imprescindíveis: ouso da OGRE, para os objetos gráficos, e da OPAL, para criação de sólidos utilizadosna simulação da física. As informações contidas no XML é que determinarão comocada nodo vai ser criado.A primeira fase de criação de um nodo é a criação do sólido que simula a física doobjeto, 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 aonodo. Após gerado, a cena passa a conter mais um objeto, sendo ele estático oudinâmico. Se dinâmico há a possibilidade do objeto se mover através da aplicação deuma determinada força. Assim sendo, a entidade gráfica deve ter as mesmascoordenadas 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 dosobjetos dinâmicos de uma forma concisa.Uma outra característica que incorpora este loader é o gerenciamento dos objetos apóssua 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) ficacomo ilustrado a seguir. Aqui as caixas de colisão não são renderizadas, porém aspropriedades 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 opersonagem automaticamente fica bloqueado para andar naquela direção.Figura 5: Exemplo de cenário após o loader.5. Como exportar um cenárioO 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 omodificador “Opal Scene”. Com este é feita a configuração de como o objeto irá agirquando efetuado o loader na engine.


Posteriormente, é feita a seleção dos objetos a serem exportados e em seguidaexecutado o plugin de exportação das malhas (octopus export). Dando seqüência aoprocesso, falta ainda exportar o arquivo XML com a descrição básica dos objetosselecionados. Para isto usamos o plugin “Opal Scene Export”. Os dois processo deexportação não exigem nenhumCom estes passos acima já finalizados, agora passamos para a parte deprogramação C++. A primeira coisa a ser feita é indicar o caminho de onde estão osarquivos gerados na etapa anterior. Depois, é preciso criar o gerenciador de objetos daaplicação, dentro do construtor da classe correspondente a cena, e em seguida apontar oarquivo 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, quandoespecificado, 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, bastainserir a linha de código abaixo passando como parâmetro o delta time da aplicação. Porfim, 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 aojogo, pois a parte que realmente leva tempo para desenvolver fica focada na modelageme texturização dos objetos.6. Dificuldades EncontradasPara desenvolver este trabalho foram encontradas diversas dificuldades. Dente elaspodemos citar uma que surgiu durante a exportação das malhas, pois no 3D Max o eixoque corresponde a altura é o Z enquanto na OGRE é o Y. Ainda, verificou-se que osobjetos modelados deveriam ter seu pivô centralizado, pois senão, quando exportado, asmalha não ficariam nas posições especificadas. Estes itens exigiram que fossem feitosuma infinidade de testes para se chegar ao resultado esperado.Quanto à parte de programação, o que mais exigiu dedicação foi na construçãode um loader genérico para carregar os objetos com colisões do tipo caixa, esfera emalha. Além disso, no gerenciamento dos objetos das cenas também foram encontradasdificuldades, pois além do controle de memória era necessário também dispor todas asfunções de manipulação gráfica e da física para que se pudesse acessar e/ou controlar osobjetos.Contudo, todas as dificuldades estavam direcionadas no ajuste da parte gráficacom a parte de física dos objetos, pois se um objeto gráfico fosse exportado composições diferente as da física, então as colisões não seriam coerentes conforme ográfico. Este caso pode ser exemplificado quando um objeto é lançado de certa alturaem direção ao chão, no qual o objeto gráfico pode não chegar ao chão, devido à colisãoantecipada, ou, em caso contrário, atravessar o terreno.


7. ConclusãoO uso do 3DS Max como level editor juntamente com o loader desenvolvidoproporcionou diversos benefícios para o desenvolvimento do jogo. Dentre eles podemoscitar o melhor aproveitamento do tempo e de esforço de trabalho dos programadores, acriação de triggers de modo visual e o carregamento automático de objetos estáticos edinâmicos para o jogo.Apesar das vantagens apresentadas, o uso desta técnica dificulta ao usuário leigocriar e/ou alterar os cenários, devido a um maior grau de complexidade exigido paramanusear a ferramenta e seus plugins. Porém, os usuário com um embasamento básicosobre o 3D Max, é possível efetuar a criação de cenários e a sua exportação semmaiores problemas.Contudo, apenas o fato de efetuar a carga automática dos objetos estáticos edinâmicos já torna este recurso útil, pois elimina a necessidade de se configurarmanualmente as propriedades de cada objeto que irão compor o ambiente.Como trabalhos futuros, pretende-se adicionar ao plugin a possibilidade de secriar câmeras e luzes. Outro ponto almejado é desenvolver articulações (joints) para osobjetos que contenham física, fazendo com que haja relacionamento forçado entre doiscorpos, como é o exemplo de uma dobradiça.AgradecimentosAgradecemos ao apoio prestado pela FINEP e pela URI – Campus de Erechim quetornaram possível a realização deste trabalho. Parte integrante do projeto RPGEDU –FINEP 1925/2004-0.Referências3d Game Studio. (2006). Disponível em: http://www.3dgamestudio.com/ [Acessado em18 Ago. 2006].3d Studio Max. (2006). Disponível em:http://usa.autodesk.com/adsk/servlet/index?id=5659302&siteID=123112 [Acessadoem 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) Partof XXIV Congresso da Sociedade Brasileira de Computação, 22-29 jul. 2005 SãoLeopoldo. São Leopoldo: UNISINOS, 1313-1357.El-nasr, M. S. e Smith, B. K. (2006). Learning Through Game Modding. ACMComputers 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 IVWorkshop 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 [Acessadoem 18 Ago. 2006].Rouse III, R. (2000). Toiling with Tools. In: 27th International Conference onComputer Graphics and Interactive Techniques, 25-27 Jun. Lousiana - USA. NewYork: 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 18Ago. 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/ [Acessadoem 15 Ago. 2006].


Topolino: Software Livre para Automatização doExperimento do Campo AbertoBruno Brandoli Machado, Jonathan de Andrade Silva, Wesley Nunes Gonçalves,Hemerson Pistori, Albert Schiaveto de Souza1 Universidade Católica Dom Bosco – UCDB,Av. Tamandaré, 6000, Jardim Seminário,Campo Grande, MS, Brasil, 79117–900{bmachado,jsilva,wnunes}@acad.ucdb.br, {pistori,albert}@ucdb.brResumo. A análise do comportamento de camundongos é um procedimentobastante comum em estudos fisiológicos e farmacológicos. Nesse artigo, é apresentadoum software livre baseado em visão computacional e aprendizagem demáquina para a automatização dos experimentos realizados com camundongosno teste do campo aberto. Para a análise dos comportamentos de exploraçãofoi utilizado aprendizagem de máquina. Os algoritmos de subtração de fundo,subtração de fundo adaptativo e segmentador baseado em modelo gaussianoforam utilizados para a segmentação das imagens. Para o rastreamento doscamundongos foram implementados os algoritmos filtro de Kalman e filtro departículas. O software é capaz de executar os experimentos em tempo real esuporta o rastreamento de múltiplos camundongos.1. IntroduçãoO estudo do comportamento animal é extremamente importante para se obter o conhecimentosobre a diversidade de seus costumes [Morrow-Tesch et al. 1998]. Taisestudos fornecem dados importantes para o desenvolvimento de terapias e novosfármacos. O uso de animais de laboratório 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 etológicos e permitem que os novos fármacos sejam avaliados antes de seremtestados em seres humanos.Em diversas pesquisas, o estudo do comportamento animal é feito de forma manual.Os registros manuais e a observação visual em experimentos podem ser realizadoscom um investimento relativamente baixo em relação à observação automática. Porém,deve se considerar que o observador possui a necessidade de presenciar todo o experimentopara obter as informações 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 automatização dos sistemas no monitoramento animal é possível forneceruma estrutura mais confiável na aquisição de dados. A observação automática é particularmenteapropriada para registrar os comportamentos que ocorrem momentaneamenteapós períodos longos, em que o observador humano é incapaz de estimar com exatidão


as informações espaciais, como por exemplo distância percorrida e velocidade. Um outroponto significativo é possibilitar a gravação digital dos experimentos em vídeo. Assim,o pesquisador pode analisar os comportamentos realizados pelos animais reproduzindo agravação.A proposta deste trabalho é apresentar um sistema computacional para automatizara análise de determinados comportamentos de camundongos no teste do campo aberto.O sistema é capaz de processar as imagens capturadas através de um dispositivo de baixocusto, como uma webcam, podendo proporcionar a gravação digital dos experimentosem vídeo. Uma etapa de processamento das imagens realiza a extração automática dosparâmetros de interesse, utilizando técnicas de visão computacional e aprendizagem demáquina.Uma das principais contribuições deste trabalho é apresentar uma alternativa multiplataforma,e de códigos-fonte abertos, aos sistemas atualmente disponíveis no mercado,muitas vezes caros e pouco flexíveis. Além disso, o pesquisador pode utilizar diversosdispositivos de captura de imagens digitais de baixo custo. O sistema Topolino foi desenvolvidocom fontes na linguagem Java visando portabilidade. Foram utilizados algunspacotes livres, como o ImageJ 1 para o pré-processamento das imagens alimentadas pelaetapa de captura de imagens. Para capturar e manipular vídeos foi utilizado o JMF. OWeka 2 , outro pacote livre, foi utilizado para classificação baseada em aprendizagem demáquina. Para o gerenciamento de informações utilizou-se o banco de dados relacionalPostgreSQL e o JFreeChart para visualização dos gráficos. Para o controle de versões nodesenvolvimento de fontes do sistema utilizou-se o repositório Subversion, integrado como Trac, um sistema baseado em web para o gerenciamento de projetos.Este artigo está estruturado em cinco seções. A Seção 2 descreve algumas ferramentasexistentes que realizam a análise do comportamento animal. Na Seção 3, é descritoo teste do campo aberto e as características de interesse selecionadas para a execuçãodos experimentos com camundongos. Na próxima seção, são descritos os módulos desenvolvidose as características do sistema. Finalmente, na Seção 5 são discutidas aslimitações e os pontos positivos do sistema.2. Trabalhos CorrelatosO Ethovision [Noldus et al. 2001] é uma ferramenta proprietária para análise do comportamentoanimal. Este sistema foi desenvolvido pela Noldus, uma empresa que atua naárea de tecnologia de informação. O software foi implementado em Visual C++, podendoser executado somente em ambiente Microsoft Windows TM . A aquisição de imagens doEthovision é realizada por um hardware dedicado que conecta um dispositivo de capturade imagens ao computador para a execução do sistema. Pelo sistema ser limitado a estehardware, o usuário fica dependente de um dispositivo específico para a sua utilização.O rastreamento do Ethovision é iniciado após a etapa de aquisição das imagens. Omódulo de rastreamento utiliza três técnicas que possuem limitações quanto à eficiênciae aplicação. A primeira técnica é baseada em limiarização nos níveis de cinza. O limiarpode ser definido pelo usuário ou através do próprio sistema. A segunda técnica consistena subtração de imagens. O usuário define uma imagem de referência, geralmente1 http://rsb.info.nih.gov/ij/2 http://www.cs.waikato.ac.nz/ml/weka/


o fundo sem a presença do animal, para realizar a subtração das imagens seguintes quecontêm o animal. O resultado da subtração é uma outra imagem possuindo somente ocamundongo. A terceira técnica é baseada em cores, onde são utilizadas as componentesmatiz e saturação do modelo de espaço de cores HSI (hue, saturation, intensity). Estatécnica é empregada para rastrear múltiplos camundongos, entretanto, possui a necessidadede pintar parte dos camundongos com uma tinta recomendada pelo sistema.Ghozland e Granon [Ghozland et al. 2002, Granon et al. 2003] utilizaram o VideoTrack,um sistema desenvolvido pela ViewPoint que analisa o comportamento deexploração dos camundongos. A captura das imagens é feita por uma câmera analógica.Existem outras ferramentas que não são baseadas em visão computacional, como em[Galsworthya et al. 2005, Kritzler et al. 2006, Kramer and Kinter 2003, Metris 2005], eque empregam dispositivos de rádio-frequência, infravermelho e sistemas elétricos para aidentificação do animal. Estes métodos intrusivos podem alterar o equilíbrio emocionaldo animal, influenciando nos resultados dos experimentos.3. Campo AbertoO teste do campo aberto ou open field é amplamente utilizado para quantificar movimentoslocomotores e de exploração dos animais. Os movimentos locomotores são osdeslocamentos entre um ponto a outro da arena. Os movimentos de exploração ou nãolocomotores são aqueles que o animal pode realizar sem a necessidade de deslocamento,como por exemplo elevação vertical, cheirar o ambiente e autolimpeza. Em experimentoscom roedores, estes comportamentos são essenciais para compreender o efeito de diferentesdrogas psicoestimulantes e ansiolíticas [Prut and Belzung 2003, Eilam 2003].Os experimentos do campo aberto ocorrem em uma arena de formato variável,geralmente circulares ou retangulares. Neste trabalho foi utilizada uma arena circularcontendo uma circuferência interna com o mesmo centro. A circunferência interna possuiraio igual a 11,5cm e a circunferência da arena possui raio de 20cm, como mostra a Figura1(a). O piso da arena é revestido de fórmica de cor branca ou preta para que haja umcontraste entre o camundongo e o piso, facilitando a observação do pesquisador e osalgoritmos de segmentação. O piso da arena está dividido em 12 regiões regulares de104,7cm 2 cada. A arena é circundada por um material em acrílico transparente de formacilíndrica, com 30cm de altura, conforme mostra a Figura 1(b).Para realização dos experimentos é aplicada a droga a ser avaliada nos camundongos.Posteriormente, os camundongos são inseridos no centro da arena, a príncipio umambiente desconhecido. No decorrer do teste, o pesquisador pré-determina o tempo emque o animal permanecerá na arena. Em seguida é verificada e registrada a região em queo animal se encontra. As Figuras 2(a), 2(b) e 2(c) apresentam exemplos de camundongosrealizando atividade motora em uma região demarcada. Após o término do tempopré-definido, retira-se o animal. A execução do teste é feita sucessivamente com todosanimais do grupo do experimento.No teste do campo aberto são utilizados mais de 30 parâmetros que avaliam asatividades motoras e de exploração dos animais. Para a sua realização, foram selecionadasas características de interesse do experimento juntamente com os especialistas. Osparâmetros relativos aos comportamentos locomotores, neste caso, são: distância percorrida,velocidade de deslocamento e o tempo de permanência em cada região. Nas


(a)(b)Figura 1. (a) Formato e limites das regiões demarcadas. (b) Material do piso edas paredes da arena.(a) (b) (c)Figura 2. (a) (c) Movimento motor do animal sobre áreas demarcadas. (b)Múltiplos camundongos realizando explorações pela arena.atividades exploratórias foi analisada a exploração vertical [Gonçalves et al. 2006]. Aexploração vertical consiste na elevação das patas posteriores do camundongo, conformeapresentado nas Figuras 3(a), 3(b) e 3(c). Neste caso, é registrado o número de ocorrênciasdestes comportamentos ao longo do experimento. Um outro fator importante é conhecera trajetória que o camundongo percorreu ao longo do experimento.4. TopolinoO sistema Topolino 3 é um projeto que foi desenvolvido na UCDB entre a parceria doGrupo de Pesquisa em Engenharia e Computação (GPEC 4 ) e do Centro de CiênciasBiológicas e da Saúde (CCBS 5 ). Este sistema visa desenvolver soluções tecnológicasque beneficiam significativamente pesquisas na área da saúde, em particular as de comportamentoanimal. Este trabalho está dividido em cinco módulos: interface, banco dedados, captura de imagens digitais, rastreamento e aprendizagem supervisionada para3 http://www.gpec.ucdb.br/topolino4 http://www.gpec.ucdb.br5 http://www.ucdb.br/cursos/ccbs/


(a) (b) (c)Figura 3. (a) (b) (c) Comportamento de exploração vertical realizado pelo camundongo.classificação de comportamentos de exploração.O módulo da interface foi desenvolvido com base nos conceitos de HCI (HumanComputer Interaction) [Myers et al. 1996]. A aplicação destes estudos proporcionam aousuário a fácil interação na execução de tarefas. Desse modo, as funcionalidades do sistematornam-se intuitivas para a realização dos experimentos. O usuário ainda possui aopção de salvar e acessar os resultados quantificados através de dados tabulados e gráficos.Para isso, foi utilizado o módulo de banco de dados responsável para o armazenamentoe o gerenciamento das informações provenientes dos experimentos. Estas informaçõespodem fornecer aos usuários uma forma de comparar outros experimentos realizados anteriormente.A Figura 4 mostra a tela de configuração do sistema.A captura de imagens digitais alimenta o sistema de visão computacional da ferramenta.Para isso, é necessário um dispositivo de aquisição dedeo e um softwarede rastreamento para o processamento das imagens. O dispositivo possibilita ao usuáriogravar ou executar em tempo real os experimentos. O sistema manipula vídeos em formatosavi ou mov. O vídeo capturado é fragmentado em quadros a uma taxa de 30 porsegundo (fps). Em seguida, de cada quadro são processadas as imagens e extraídas ascaracterísticas dos comportamentos locomotores.Para os comportamentos de exploração é realizada a etapa de treinamento antesdos quadros serem processados. A etapa de treinamento permite realizar a classificaçãodos comportamentos de interesse utilizando o módulo de aprendizagem supervisionada.Este módulo é capaz de realizar a classificação automática a partir de experiências emcasos de sucesso. As regras de classificação inferidas pelo módulo de aprendizadosão analisadas pela complexidade das próprias regras e o erro de classificação sobrenovos conjuntos de imagens. Neste módulo, foram utilizados momentos estatísticos[Souza and Pistori 2005] para a extração de atributos aplicados ao treinamento. Para otreinamento é escolhido um conjunto de imagens do vídeo que melhor representam estescomportamentos, descritos na Seção 3. Realizada a seleção dos quadros, são extraídos osatributos do conjunto de imagens utilizados para a classificação.O software de rastreamento utiliza métodos de segmentação em imagens para extrairo objeto de interesse, neste caso o camundongo. Os métodos de segmentação utilizadosforam subtração de fundo, subtração de fundo adaptativo e segmentador baseado em


Figura 4. Configurações do sistema Topolino.modelo gaussiano. A subtração de fundo [Piccardi 2004] é uma das técnicas mais utilizadasdevido a sua simplicidade de implementação e seu baixo custo de processamento.O princípio básico é subtrair cada imagem do quadro fragmentado de uma imagem dereferência, obtida a partir de um fundo estático e sem o objeto de interesse. A grandedificuldade apresentada pela subtração de fundo é não se adaptar a modificações no fundoda cena, como mudança de iluminação ou objetos que entram em cena e em seguida ficamestáticos e sem relevância. Para contornar esse problema, existem técnicas de subtraçãode fundo mais sofisticadas, como a subtração de fundo adaptativo [Collins et al. 2000].Essa técnica possui a vantagem de se adaptar a pequenas modificações, sendo útil emlongos períodos de tempo, como experimentos com muitas horas de duração. O modelogaussiano utiliza a cor como principal característica [Terrillon et al. 2000]. O espaço decor utilizado neste trabalho é o HSV. As cores no padrão HSV são divididas em matiz (H)definindo a cor dominante, saturação (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 relação a mudança na intensidade de iluminação.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 dedinâmica e incerteza para propagar os estados do sistema, em seguida o estado preditoé corrigido através de um modelo de observação. Os filtros preditivos apresentammuitas vantagens como eficiência em aplicações em tempo real e habilidade de tratara sobreposição de objetos. O filtro de Kalman apresenta uma limitação por considerar


que as variáveis aleatórias são gaussianas e o modelo de dinâmica linear. Em algumasaplicações, essa restrição de linearidade não é aplicável e o filtro não pode estimar corretamenteo estado do objeto sobre o tempo. Uma aproximação possível para contornaressa limitação é empregar uma representação não-paramétrica baseada em amostras oupartículas, como o filtro de partículas.Os algoritmos dos filtros e os segmentadores implementados possuem parâmetrosque podem ser alterados pelo usuário e visualizados em tempo real de processamento.A Figura 5 mostra a execução do módulo de rastreamento. O sistema Topolino, alémde analisar um camundongo por vídeo, suporta o rastreamento de múltiplos camundongos,podendo ser observado o nível de socialização entre eles. Após esta etapa é possívelextrair as características das imagens. Com base no treinamento são classificados os comportamentosapresentados pelos camundongos durante o experimento. A integração como software Weka tornou disponível para os usuários do Topolino dezenas de algoritmosde aprendizagem supervisionada, entre eles o C4.5, as máquinas de vetores de suporte ea redes neurais artificiais.Figura 5. Módulo de rastreamento do sistema Topolino.5. Conclusão e Trabalhos FuturosO resultado deste trabalho é um sistema com fontes livres para auxiliar pesquisadores noregistro de parâmetros comportamentais relevantes durante experimentos com camundongos.Outro ponto a ser destacado, é que o pesquisador possui a flexibilidade de utilizardiversos dispositivos de captura de imagens digitais. Além disso, é possível executar osistema para rastrear até quatro camundongos através de gravações dedeo ou até mesmo


em tempo real. A ferramenta mostrou ser útil em estudos etológicos, facilitando ao pesquisadora avaliação do efeito de determinados fármacos.A ferramenta implementada automatizou o teste do campo aberto. Porém,é importante agora expandir os experimentos para outros tipos de testes quetambém medem a atividade locomotora de camundongos, como o teste do labirintoaquático de morris [Grossmann and Skinner 1996] e o labirinto em cruz[Boguszewski and Szmagalska 2002]. Neste caso, poderia ser expandido o número devariáveis a serem analisadas. Ainda vale ressaltar que uma maneira de ampliar a utilizaçãodo sistema seria realizar os experimentos com diferentes animais e em ambientes diversos.AgradecimentosEste trabalho recebeu apoio financeiro da Universidade Católica Dom Bosco, UCDB, daFundação de Apoio ao Desenvolvimento do Ensino, Ciência e Tecnologia do Estado deMato Grosso do Sul, FUNDECT. Alguns dos acadêmicos que participaram no desenvolvimentodo sistema citado nesse artigo receberam bolsas PIBIC/CNPQ.ReferênciasBoguszewski, 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 geneticamentemodificado como modelo de estudo para doenças cardiovasculares. In XSimpósio Brasileiro de Fisiologia Cardiovascular, volume 39, pages 110–116, RibeirãoPreto,Brasil.Collins, R., Lipton, A., Kanade, T., Fujiyoshi, H., Duggins, D., Tsin, Y., Tolliver, D., Enomoto,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. BehaviouralBrain Research, 142:53–62.Fagundes, D. J. and Taha, M. O. (2004). Modelo animal de doença: critérios de escolha eespécies de animais de uso corrente. Acta Cirúrgica 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.Gonçalves, W. N., de Andrade Silva, J., Machado, B. B., de Ruchkys, D. P., and Pistori, H.(2006). Software de auxílio no reconhecimento de padrões em animais de laboratório


utilizando cadeia de código. In Proceedings 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 Pérez, 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 rfidbasedtracking system for laboratory mice in a semi natural environment. In PTAWorkshop, 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 ultrasoundsusing 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. In SIBGRAPI ’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 humancomputerinteraction. 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. In Proc. 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). Implementação de um extrator de características baseadoem momentos da imagem. In Proceedings 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. In FG ’00: Proceedings of theFourth IEEE International Conference on Automatic Face and Gesture Recognition2000, page 54, Washington, DC, USA. IEEE Computer Society.


Inspeção Visual Industrial Automatizada por Análise deForma com Descritores de Fourier e Redes Neurais ArtificiaisMauricio Edgar Stivanello, Paulo César Rodacki Gomes1 Departamento de Sistemas e ComputaçãoUniversidade Regional de Blumenau (FURB) – Blumenau, SC – Brazilmaustiva@das.ufsc.br, rodacki@inf.furb.brResumo. Este trabalho apresenta um protótipo de inspeção industrial automatizadaindependente de produto, feita através de aquisição e reconhecimentode imagens. No desenvolvimento do protótipo são utilizados, dentre outrastécnicas de processamento de imagens, os descritores de Fourier para adescrição de formas a partir da borda da silhueta dos objetos inspecionados.Para a interpretação das representações dos produtos, foi implementada umarede neural artificial do tipo Perceptron Multicamadas. O trabalho é resultadode um projeto de conclusão de curso de graduação em Ciência da Computação.1. IntroduçãoO mercado consumidor de produtos industrializados está cada vez mais exigente no quediz respeito à qualidade. Este fato tem motivado as indústrias a investirem cada vez maisnos processos de inspeção de qualidade, já que a mesma se tornou um diferencial competitivo.Apesar do aumento dos investimentos na área, na maioria das indústrias brasileirasa inspeção e a seleção dos produtos nas fábricas ainda são realizadas por inspetores humanos,que permanecem em determinados pontos de uma linha de produção, onde devemavaliar determinadas características dos produtos produzidos. Caso alguma destas característicasencontre-se fora dos padrões de qualidade aceitáveis, a peça é retirada da linhade produção para ser descartada ou corrigida.Por se tratar de uma tarefa extremamente repetitiva e que exige um excessivoesforço físico por parte do funcionário que a realiza, a inspeção humana acarreta problemastais como a falta de inspeção em todos os produtos, a falta de precisão nas inspeções ea alta rotatividade de trabalhadores. Os sistemas de inspeção por computador surgem paraauxiliar o homem nestas tarefas. Estes sistemas têm como principal objetivo o auxílio ouaté mesmo a substituição da visão humana no ambiente industrial.O presente trabalho apresenta a implementação de um protótipo de software parainspeção industrial automatizada através da aquisição, processamento e interpretação deimagens dos produtos utilizando descritores de Fourier e redes neurais artificiais. Apróxima seção descreve em termos gerais a arquitetura típica de um sistema de inspeçãoindustrial. A seção 3 trata do processamento e cálculo de descritores de Fourier. Emseguida, é discutido o processo de interpretação das imagens. A seção 5 demonstra aoperacionalidade do protótipo e discute os resultados obtidos. Por fim, são apresentadasas conclusões.2. Arquitetura de um sistema de inspeçãoNormalmente, a arquitetura de um sistema de inspeção automatizada é composta porvários subsistemas e pode assumir diferentes configurações. Para aplicações de inspeção


industrial, porém, é comum que seja composta por um sistema de aquisição de imagens,um sistema de processamento e um sistema de descarte, conforme apresentado na figura 1.Neste exemplo, o processo de inspeção é realizado de forma integrada com a linhade produção, evitando assim trabalho desnecessário, já que uma peça identificada comodefeituosa não estará presente nas etapas seguintes da produção. O sistema de aquisiçãocaptura pelo menos uma imagem de cada peça que transita pela esteira. A imagem étransmitida ao sistema de processamento, onde é analisada a fim de se identificar algumdefeito na peça. Em caso afirmativo, o sistema de processamento deve enviar um comandopara o sistema de descarte, que por meio de algum mecanismo retira a peça defeituosa daesteira.Figura 1. Arquitetura de sistema de inspeçãoO presente trabalho trata do sistema de processamento. O software deve ser responsávelpelo controle do sistema como um todo, pelo processamento e análise das imagense pela interface com o usuário. Através deste tipo software, é realizada a análisesobre cada uma das imagens em busca de defeitos, irregularidades ou mesmo para realizarclassificação. Com base no resultado da análise, o software toma uma decisão acercade cada produto analisado, que pode resultar em diferentes ações.3. Processamento de imagensO processamento de imagens assume um importante papel nos sistemas de inspeção automatizadapara a extração de informações relevantes para posterior análise e tomada dedecisão. A inspeção sobre um produto pode ser realizada observando-se diferentes característicastais sua como forma, cor, textura, e outras. A análise implementada no presentetrabalho é baseada na forma dos produtos, ela possibilita a inspeção de diferentes tipos deprodutos, já que a presença de muitos defeitos de produção tem reflexo direto sobre suaforma externa. Esta seção descreve algumas das técnicas utilizadas no desenvolvimentodo protótipo.3.1. Segmentação das imagensA segmentação procura reproduzir o processo da visão humana onde são efetuados agrupamentossobre a imagem percebida, baseados em proximidade, similaridade e continuidade.Ela consiste em dividir a imagem em elementos significativos e tem como objetivoisolar os objetos de interesse.


No presente trabalhofoi utilizada a técnica desegmentação por detecção debordas [Facon 1993]. Esta éuma das técnicas em que asegmentação é realizada combase na descontinuidade devalores de níveis de cinza. Adetecção de bordas pode serFigura 2. Aplicação do operador Sobelobtida 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 aplicação deste filtro em uma imagem. Este filtro faz parte dostodos de domínio espacial que operam diretamente sobre os pixels de uma imagemconsiderando a vizinhança dos mesmos.A abordagem principal para definir a vizinhança em torno de um pixel consiste emaplicar máscaras a uma sub-imagem quadrada, centrada no pixel em questão. O centrodesta sub-imagem é movido então de pixel a pixel sobre toda a imagem, aplicando-se ooperador para cada posição da mesma.Figura 3. a) Posições de uma imagem 3x3; b) Máscara para x; c) Máscara para yA partir das máscaras do operador de Sobel exibidas na figura 3, tem-se que asderivadas baseadas nas mesmas podem ser obtidas porG x = (z 7 + 2z 8 + z 9 ) − (z 3 + 2z 2 + z 3 ), (1)G y = (z 3 + 2z 6 + z 9 ) − (z 1 + 2z 4 + z 7 ). (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 segmentadasão aproximados a 255, e os valores dos níveis de cinza dos pixels que não pertenceremà fronteira são aproximados a 0. Para evitar que os processamentos que virão a seguirconsiderem faixas de valores próximos a estes extremos, é realizada a binarização daimagem através da técnica de limiarização global. A binarização permite que somentesejam considerados valores de 0 ou 255.A partir da imagem segmentada pela detecção de bordas e pela limiarização global,se poderia varrer a imagem e identificar os pixels que compõem um contorno. Porém,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 um único objeto. Para resolver este problema o presente trabalho utiliza


a técnica de rotulação de componentes [Gonzales and Woods 1993]. Através dela os diferentesagrupamentos de pixels presentes na imagem são rotulados com diferentes valoresde níveis de cinza. Observa-se agora que, como a própria faixa de valores dos pixels entre0 e 255 é utilizada como identificador dos componentes, existe uma limitação ao uso deno máximo 253 diferentes agrupamentos. Uma abordagem diferente com utilização denova estrutura poderia resolver o problema, porém esta quantidade mostrou-se suficientepara a resolução do problema aqui exposto.As informações extraídas dos componentes são então utilizadas para decidir qualdos contornos deve ser considerado. Partindo do princípio que a área de atuação de umponto de inspeção em uma linha de produção deve ser controlada e também previamentepreparada, o presente trabalho assume que o contorno a ser inspecionado é o maior contornopresente no quadro. Para identificação do maior contorno, considera-se o componenteconexo de maior área dentre todos os componentes conexos gerados pela rotulaçãode componentes.3.2. Cálculo dos descritores de FourierNa etapa de segmentação, obtêm-se agrupamentos de pixels que representam o componenteda imagem a ser analisado. Porém, este componente deve ser descrito de maneiramais apropriada, já que uma análise direta sobre os pixels não é adequada para o problemaem questão.Identificado o componente conexo a ser considerado, pode-se compor uma linhapoligonal com as coordenadas dos pixels que compõe o contorno. Isto é feito através daimplementação de uma função de perseguição de contorno para percorrer a fronteira deum componente conexo, partindo de um ponto inicial informado. Com isso, é obtida umalista contendo as coordenadas de todos os pontos pertencentes à fronteira do componente.Com a lista de coordenadas dos pontos no plano xy que formam o contorno, jáhá informação suficiente para diferenciar produtos. Porém, a lista gerada geralmente émuito grande. Considerando-se que os quadros capturados por câmeras específicas paraaplicações de inspeção normalmente são compostos por 640 pixels de largura por 480pixels de altura, freqüentemente são obtidos contornos com mais de 1000 pixels. Estaquantidade de informação é inviável para a maioria das técnicas de interpretação.Para resolver este problema, o presente trabalho utiliza descritores de imagens,que são conjuntos de números, gerados para descrever uma forma. Os descritoresnão reconstituem completamente a forma descrita, mas devem ser suficientespara diferenciar uma forma de outra. O presente trabalho utiliza a descrição porFourier. Os descritores de Fourier são uma das formas de representação de imagensmais populares para aplicações de visão computacional e reconhecimento depadrões [da Fontoura Costa and Cesar, Roberto Marcondes 2001], eles não constituemum método simples, mas uma classe detodos já que existem diferentes maneiras dedefini-los [Gonzales and Woods 1993].A figura 4 exibe uma fronteira de N pontos no plano xy. Iniciando de um pontoqualquer (x 0 , y 0 ) no sentido anti-horário (por exemplo), pode-se encontrar os pares de coordenadas(x 0 , y 0 ), (x 1 , y 1 ), (x 2 , y 2 ), ...(x n−1 , y n−1 ) que representam a fronteira da forma.Cada par pode ser tratado como número complexo da forma s(k) = x(k) + jy(k), parak = 0, 1, 2, ..., N − 1, onde N é a quantidade de pontos que compõe a fronteira. Esta


epresentação possui a vantagem de reduzir um problema de duas dimensões a uma sódimensão.A transformada discreta de Fourier écalculada pora(u) = 1 NN−1 ∑k=0s(k) −j2πuk/N (3)onde N é a quantidade de pontos que compõe afronteira. Os coeficientes complexos a(u) sãochamados de descritores de Fourier. Podem serobtidos tantos descritores quanto o número depontos que compõem a fronteira no plano xy.Porém, não existiria vantagem em se descrevera forma pela mesma quantidade de pontos.Com este método de descrição existe a possibilidadede representar uma forma com uma pequena quantidade de descritores. IstoFigura 4. Código de cadeiaconstitui uma grande vantagem, pois com uma quantidade relativamente pequena deinformação, pode-se diferenciar formatos de fronteiras distintos. De maneira geral, poucoscoeficientes de baixa ordem são capazes de capturar as características mais gerais daforma analisada. Para a definição de características mais marcantes, como cantos e retas,umgrande número de coeficientes é necessário. A transformada inversa de Fourier dea(u) é calculada pors(k) =M−1 ∑u=0a(u) j2πuk/N (4)onde N é a quantidade de pontos que compõe a fronteira. Esta transformada é utilizadapara reconstruir os valores de s(k) a partir dos coeficientes a(u). A variável M(com M ≤ N − 1) representa o número de coeficientes utilizados na descrição da fronteira[Bowman et al. 2001]. Outra vantagem na utilização dos descritores de Fourier éa possibilidade de se obter invariância quanto à rotação, translação e escala através detransformações simples dos descritores. Uma descrição detalhada destas transformaçõespode ser encontrada em [Gonzales and Woods 1993].4. Interpretação das imagensA interpretação consiste em identificar padrões através da análise das descrições da imagemobtidas nas etapas anteriores. Esta análise leva em conta padrões ou regras previamentedefinidas. Dentre as várias técnicas utilizadas no reconhecimento de padrõesencontram-se as redes neurais artificiais, surgidas como uma tentativa de simular o funcionamentoe resolver problemas do mesmo modo como é feito pelo cérebro humano.4.1. Redes neurais artificiaisAs redes neurais artificiais são sistemas computacionais implementados em hardwareou software que imitam as habilidades computacionais do sistema nervoso, usandoum grande número de neurônios artificiais interconectados [Loesch and Sari 1996]. Oneurônio artificial é o elemento básico que forma uma rede neural artificial e simula ofuncionamento de um neurônio biológico. A figura 6 apresenta um modelo de neurônio


artificial, cujos principais elementos são entradas, pesos sinápticos, função de ativação oufunção Soma e a função de transferência ou ativador.O neurônio possui um ou mais sinais de entrada, por onde ele recebe os estímulosa serem processados. Assim como ocorre no neurônio natural, no neurônio artificial todasas entradas são consideradas de maneira simultânea no momento do processamento.Os pesos são os valores que representam o grau de importância de cada entradapara o neurônio. É através da variação destes valores que se constrói o conhecimento. Osvalores dos pesos são obtidos no momento do treinamento da rede neural.A função de ativação antecedea função de transferência e temcomo atribuição repassar o sinal obtidoatravés das entradas à função detransferência. Em modelos mais simplesde redes neurais esta função simplesmenterealiza a soma dos valoresdas entradas multiplicados pelos respectivospesos. A função de transferênciaanalisa o valor gerado pelaFigura 5. Modelo de Neurônio Artificialfunção de ativação e gera uma saída para o neurônio. A função muda conforme o modelode rede utilizado. Uma das funções mais empregadas é a de sinal, onde o valor obtidopela função de ativação é comparado com determinado limiar. Conforme o resultado dacomparação, a saída assume um entre dois valores predeterminados.Em uma rede neural artificial os neurônios são agrupados em camadas[Loesch and Sari 1996]. Os neurônios da camada de entrada não realizam processamento.Sua única função é armazenar a informação de entrada para ser repassada aos neurônios dapróxima camada. Uma rede neural artificial pode também possuir camadas intermediáriasou ocultas, que se situam entre a camada de entrada e a camada de saída. A estrutura destascamadas é igual à da camada de saída, porém não tem contato com o exterior. Estascamadas tem como objetivo melhorar o desempenho da rede, aumentando a possibilidadede divisão do espaço de entrada de maneira não linear. Por fim tem-se a camada desaída. Além de realizar processamento através de seus neurônios esta camada tambémé responsável por repassar o resultado do processamento da rede ao mundo exterior. Aquantidade de neurônios da camada de saída é igual ao número de saídas esperadas darede. As diferentes organizações de camadas possíveis distinguem os tipos de arquiteturade redes neurais artificiais existentes. Para a realização deste trabalho foi implementadauma rede neural do tipo Multicamadas feedforward, que será descrita em seção própria.4.2. Fases do projeto de uma rede neuralApesar das redes neurais artificiais serem utilizadas em diversas áreas, seu objetivoé quase sempre o mesmo, reconhecer e classificar padrões, além de generalizarinformações. Diante de um projeto de uma rede neural ao invés de se pensar em procedimentose fórmulas 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 momentosdistintos de processamento: o momento de aprendizado e o momento de utilização.Apesar destas duas fases bem distintas de processamento, um projeto de rede possui 3 fa-


ses principais: a definição, o treinamento e a utilização [Loesch and Sari 1996]. Na fasede definição da rede neural devem-se identificar as variáveis relacionadas ao problemaque contém as informações necessárias à resolução do mesmo. Uma vez identificadasestas variáveis é escolhido o modelo da rede neural a ser utilizado. Também devem serdefinidos os seguintes aspectos da rede:1. tamanho da rede: deve-se definir o tamanho da rede no que diz respeito a quantidadede camadas, quantidade de neurônios por camada, quantidade de entradas equantidade de saídas;2. tipo de problema a ser resolvido: o problema pode ser de classificação,padronização ou otimização;3. tipo de aprendizado: o algoritmo de aprendizado deve ser selecionado entre supervisionadoe não-supervisionado.Dentre as formas de treinamento possíveis para a rede neural artificial, o treinamentosupervisionado é 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 são então apresentados à rede e para cada entrada deve ser verificado se a saídaobtida corresponde à saída desejada. Caso a saída obtida seja diferente da saída desejadadeve ocorrer o ajuste dos pesos sinápticos dos neurônios da rede. Caso a saída obtida sejaigual à saída desejada, deve-se apresentar o par seguinte à rede. Este processo deve serepetir para todos os pares do conjunto de treinamento, até que se obtenha uma taxa deacerto satisfatória. O ajuste sináptico citado nada mais é do que o aprendizado do fatoapresentado. É através deste ajuste que o conjunto de neurônios representa a informaçãoque foi apresentada à rede. O ajuste sináptico é resultado de um cálculo que visa somarao peso atual um valor que corresponda ao grau de erro gerado pela rede diante a uma entrada,a fim de corrigir o valor do peso. Após ter sido realizado o treinamento satisfatórioda rede neural, ela está pronta para ser utilizada. A fase de utilização é propriamente aexecução da rede neural, que se inicia quando uma entrada é apresentada à rede e terminaquando a rede gera uma saída. É importante lembrar que, na fase de utilização, nenhumajuste de peso sináptico é realizado. O processo de utilização consiste na obtenção de umaresposta da rede a um estímulo de entrada. Caso ainda surja a necessidade de reconhecimentode novos conjuntos de dados ou caso sejam identificados erros significativos naexecução da rede, será necessária uma manutenção na rede neural. A manutenção podeser realizada pelo processo de treinamento ou mesmo por alterações na definição da rede,dependendo do caso.4.3. Redes neurais perceptron multicamadasDiferentes combinações quanto aos aspectos estruturais das redes neurais artificiais resultamna existência de diferentes modelos, cada um com sua arquitetura, aprendizagem e capacidadediferente dos demais. As aplicações práticas também variam para cada modelo.A rede perceptron multicamadas possui, além da capacidade de abstração, a capacidadede generalização. Com isso, é capaz de classificar um padrão mesmo quando este nãopertença ao conjunto de treinamento. Também é uma rede robusta, sendo assim imune apequenas falhas nos padrões apresentados [Loesch and Sari 1996]. Quanto à sua arquitetura,ela possui uma camada de entrada, uma ou mais camadas ocultas e uma camada desaída. Cada neurônio recebe diversos valores de entrada e produz apenas uma saída. Osneurônios de uma mesma camada atuam em paralelo. O fluxo de processamento inicia


na camada de entrada e os valores produzidos são propagados até a camada de saída. Asequações utilizadas neste tipo de processamento são chamadas equações feedforward. Aequação 5 faz este tipo de cálculo,onde x k−1is (k)j= w (k) ∑N k0j +i=1w (k)ij× x k−1i , (5)representa a saída da função de ativação do neurônio i da camada k; s (k)jrepresenta os pesos das conexõesé a soma ponderada dos pesos pelas entradas; w (k)ijsinápticas na entrada do neurônio j da camada k na i-ésima conexão; N k é o número deneurônios da camada k; e x (k)jrepresenta o valor do bias.= f(s (k)j) obtém a saída do neurônio j da camada k; w (k)0jO bias é uma entrada adicional que pode ser acrescentada ao neurônio artificial,não proveniente de nenhum outro neurônio, e de valor de entrada fixado em 1. Seu pesode conexão é ajustável pelo aprendizado como qualquer outro peso de conexão. O uso dobias no modelo provê meios de transladar o valor de limiar da função de transferência.Para o treinamento da rede, ao se apresentar um padrão de entrada, o fluxo éalimentado pra frente, camada por camada. O valor de saída obtido é comparado coma saída desejada, e em caso de erro ocorre um reajuste dos pesos da rede. Este ajuste érealizado de trás para frente, ou seja, da camada de saída à primeira camada oculta. Oalgoritmo de retropropagação é apresentado no abaixo:1. Inicialize os pesos w (k)ij da rede com valores aleatórios próximos a zero;2. Seja (x, d) o par de treinamento, aplique o vetor x na camada de entrada e propaguea rede até a camada de saída. Seja y a saída da rede, calcule o erro quadráticoε 2 = ∑ mj=1 (d j − y j ) 2 . Se for inferior ao valor de tolerância, pare com sucesso,senão prossiga;3. Faça k ← última camada;4. Para todo elemento j da camada k faça:• Calcule ε (k)j empregando ε (k)j = (d j − y j ) se k for a última camada ouε (k)j = ∑ N k+1i=1 (δ (k+1i × w (k+1)ji ) se k for uma camada oculta;• Calcule δ (k)j = ε (k)j × f ′ (s (k)j ).5. k ← k − 1. Se k > 0 vá para o passo 4, senão prossiga para o passo 6;6. Recalcule todos os pesos de conexão da rede: W (k)j (n + 1) = W (k)j (n) +2µδ (k)j (n) × x (k)j (n), onde µ é a taxa de aprendizagem da rede e n significa aiteração corrente . Tome outro par de treinamento e retorne ao passo 2.Para a implementação do algoritmo de retropropagação existe a necessidade docálculo da derivada da função de transferência no passo 4. Este cálculo pode ser realizadocom maior eficiência computacional quando a função de transferência for alguma funçãologística [Fausett 1994]. Deste modo, a derivada foi obtida por f ′ (x) = f(x)×(1−f(x)),e a função logística apresentada abaixo foi utilizada como função de transferênciaf(x) =1. (6)1 − e−x


5. Operacionalidade do protótipo e resultadosO protótipo foi implementado em C++, no ambiente de desenvolvimento Microsoft VisualStudio. Sua tela inicial é exibida na figura 6a. O primeiro passo necessário para asua utilização na inspeção de produtos é a definição e configuração das análises a seremconsideradas na inspeção.Figura 6. a)Tela principal; b) Tela de definição de subquadrosA tela exibida na figura 6b é utilizada para configuração da análise de forma.Devem ser informados os parâmetros utilizados na criação da rede neural, bem como olocal onde se encontram os padrões a serem utilizados no seu treinamento. Além disso,o usuário deve informar a quantidade de descritores a serem utilizados e os tipos de invariânciaa serem mantidos. Definidos estes parâmetros, deve ser realizado o treinamentoda rede neural para que a análise seja preparada para uso. Após a configuração da análise,o protótipo encontra-se pronto para inspecionar imagens de produtos. Para isso, bastacarregar as imagens e efetuar as análises. Os resultados são exibidos na lista de saída.Dois casos de teste foram utilizados para verificar o cumprimento dos requisitospara o protótipo proposto, cada um deles refere-se à inspeção de um tipo de produtopara a distinção 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 câmera dedeo, placa de aquisição, lentes, dispositivos deiluminação e um computador. O tamanho da imagem capturada pela placa de aquisição éde 640 por 480 pixels.No primeiro caso de teste, foi utilizado como objetode análise um frasco empregado como embalagemde produtos para limpeza. Esta embalagem foi escolhidapor ser composta por várias peças, cuja montagem deveser inspecionada para a identificação de possíveis problemas.Foram definidos os seguintes itens como sendopotenciais pontos de defeito, e, portanto, de análise necessáriana fase de inspeção deste produto: presença ecorreta posição do bico; presença e correta posição dogatilho; e alinhamento, presença e correta posição dosistema de borrifo. A figura 7 mostra a imagem de umproduto considerado aprovado.Figura 7. Amostra deproduto aprovado


A figura 8 exibe imagens de produtos reprovados, exemplificando os defeitos citadosanteriormente. Aqui não é considerada a situação em que o produto transita pelaesteira e passe pela câmera com sua base em um ângulo diferente do exibido nas amostrasdas figuras 7 e 8. Isto se dá pelo fato de que este controle pode ser conseguidofisicamente, pela utilização de duas guias, uma em cada lado do produto. Desta maneirapode-se reduzir em muito a quantidade de posições a serem consideradas pelo sistema deinspeção. Para a descrição do produto foram utilizados 15 descritores de Fourier. Quantoàs variações possíveis na estrutura da rede neural implementada, foi utilizada uma camadaoculta, contendo 15 neurônios. Este mesmo número de neurônios 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 neurônio.Figura 8. Amostras de produtos defeituososPara este primeiro caso de teste, foram utilizadas 480 amostras para a fase detreinamento, dentre produtos aprovados e reprovados. Para a formação deste conjuntode treinamento, foram capturadas 50 imagens de produtos. O restante das amostras foigerado a partir do processamento em lote de diferentes transformações geométricas, apartir das imagens originais. O objetivo da aplicação destas transformações foi o de gerarpequenas variações na forma do produto analisado. Para treinar a rede com a configuraçãocitada anteriormente, o processo de treinamento demorou aproximadamente 3 horas numcomputador IBM-PC com processador Pentium 4 de 2.5GHz e 256MB de memória RAM.Na fase de reconhecimento e análise, foramapresentadas à rede 200 novas amostras de produtos.Novamente foi utilizado o recurso de gerarvariações de imagens a partir de 50 originais, atravésde transformações geométricas. A rede classificoucorretamente 100% das amostras. Observe que asimagens exibidas à rede não haviam sido utilizadasno processo de treinamento. Este fato mostra a capacidadede generalização da rede. O tempo necessáriopara a análise de cada produto girou em torno de 0.1 Figura 9. Amostra desegundos. Deste tempo, verificou-se que a maior parcelaproduto aprovadoé utilizada pelos algoritmos de processamento de imagem, sendo o restante consu-mido pelo reconhecimento através da rede neural. É importante comentar que não foram


despendidos maiores esforços para a otimização do código. Portanto, acreditamos que otempo gasto pela análise pode ainda ser reduzido.Para o segundo caso de teste, foi selecionado como objeto de análise um tubo utilizadocomo embalagem para creme dental. Esta embalagem foi escolhida por possibilitara verificação da capacidade do protótipo de analisar produtos com variação na orientaçãoem relação à câmera. Foram definidos os seguintes itens como potenciais pontos de defeito:presença e correta posição da tampa; e integridade do tubo. A figura 9 mostra aimagem de um produto considerado aprovado.Na figura 10 , são exibidas imagens de produtos reprovados, exemplificando os defeitoscitados anteriormente. É importante observar que neste momento são consideradastodas as variações possíveis quanto à orientação do tubo.Figura 10. Amostras de produtos defeituososPara este caso de teste foi utilizada a mesma quantidade de descritores utilizadosno caso anterior para a representação 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 máximo de 0.1, paraeste caso foi necessário um erro máximo de 0.2. Isto foi necessário porque a diferença daborda entre os produtos aprovados e reprovados utilizados neste caso de teste é mais sutildo que as do primeiro caso. Neste caso de testes também foi obtido 100% de sucesso naclassificação das amostras. Adicionalmente, confirmou-se a eficiência no uso dos descritoresquanto à invariância a translação e rotação, já que o protótipo reconheceu produtosem diferentes ângulos, sendo que na fase de treinamento não foram apresentados padrõesabrangendo todas as combinações possíveis.6. ConclusõesEste trabalho apresentou um método para a análise de produtos e o desenvolvimento deum protótipo de software para inspeção industrial automatizada a partir de análise deimagens. Para realizar tal tarefa foram utilizadas diversas técnicas de processamento deimagens, além de uma rede neural para o reconhecimento e interpretação das amostras. Acombinação do método de descrição de fronteiras por Fourier e da técnica de interpretação


por redes neurais permitiu o desenvolvimento de um protótipo de inspeção automatizadaversátil quanto ao produto a ser inspecionado, com velocidade e resultado satisfatórios naexecução das análises. A utilização dos descritores de Fourier para a descrição de formaspara a interpretação das imagens foi baseada na capacidade do método em representaras formas a partir de uma quantidade pequena de descritores. Outra propriedade importanteconsiderada no momento da escolha do método foi a possibilidade de obtenção dedescritores invariantes à translação e rotação. Isso amplia as possibilidades de aplicaçãodo protótipo a uma série de produtos em que pode existir variação na orientação dasimagens. A utilização de redes neurais do tipo Perceptron Multicamadas baseou-se na capacidadede generalização da rede e também na sua facilidade de implementação. Como adescrição dos produtos pode ser obtida por um número pequeno de descritores, é possívelutilizar uma rede com quantidade reduzida de neurônios, tornando-a muito eficiente naclassificação dos produtos. Apesar disto, o treinamento mostrou-se relativamente lento,tendendo a aumentar quando a diferença do contorno dos produtos das classes aprovadoe reprovado é sutil. Finalmente, é importante comentar que, apesar do tipo de análisebaseado na forma ser aplicável a uma grande diversidade de produtos, para muitos desteso mesmo não será suficiente para a determinação de ausência de todos os defeitos deprodução possíveis. Muitos produtos demandam análises específicas, como, por exemplo,uma garrafa de bebida onde é necessária a análise do volume do líquido. Para estetipo de análise, o método apresentado não é recomendado, pois a variação no volumedo líquido não tem reflexo sobre a forma da garrafa. A complexidade e abrangência dossistemas de visão computacional possibilitam que o presente trabalho seja estendido comdiferentes objetivos. Durante o desenvolvimento do protótipo, este item foi levado emconsideração, tanto no projeto do sistema como na escolha das ferramentas utilizadas naimplementação.ReferênciasBowman, E. T., Soga, K., and Drummond, W. (2001). Particle shape characterisationusing fourier descriptor analysis. Géotechnique, 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 análise de imagens. Universidad Nacional de Córdoba,Argentina.Fausett, L. (1994). Fundamentals of Neural Networks, volume 1 of 1. 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).Editora da FURB, Blumenau.Redes neurais artificiais :fundamentos e modelos.


AOPDelphi – Protótipo de um weaver para programaçãoorientada a aspectos em DelphiEdmar Soares de Oliveira, Marcel HugoDepartamento de Sistemas e ComputaçãoUniversidade Regional de Blumenal (FURB) – Blumenau, SCedmar.mg@gmail.com, marcel@furb.brResumo. 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çãoAo 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 detodos 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 AspectJ 1 .2. Linguagem AOPDelphiA 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çãoPara especificação da linguagem foi utilizada a ferramenta GALS (GESSER, 2003). Asdefinições regulares de auxílio para definição de tokens, ostokens 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 seude aspectos.e sua linguagem


Quadro 1: BNF da linguagem AOPDelphi'HILQLo}HVUHJXODUHVXWLOL]DGDVQD%1)IDENTIFICADOR : ( | "_") ( | | "_")*CURINGA_IDENTIFICADOR: ("*" ( | | "_")+)| (( |"_") ( | | "_")* "*"( | | "_")* ( |"_" |))| (( |"_") ( | | "_")* "*")CODIGO : .%1) ::= End. ::= IDENTIFICADOR = Aspect ::= [a-zA-Z] ::= [0-9] ::= Var ::= : ;::= string | integer | real| double | extended | currency| boolean | variant | word| byte | char ::= IDENTIFICADOR ::= , IDENTIFICADOR ! " !


Quadro 2: Exemplo de programa AOPDelphiALog = AspectVarFId : Integer;Str1, Str2 : String;ImplementationlogInsert : Pointcut = (procedure Arquivo.Insert(*));Advice logInsert: Before;beginShowMessage(‘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 eumadvice, 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 PointcutOs 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. Ospointcuts podemser comparados com uma variável que armazena uma lista de assinaturas detodosque 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 detodoque 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 AdviceOs 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. AOPDelphiO 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 AOPDelphiConforme 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 érepresentadonafigura2.Figura 2: Diagrama de atividades do processo de weavingNeste 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 AOPDelphi3.1 OperacionalidadeAo ser executado o aplicativo AOPDelphi, é exibida uma tela como mostra a figura 4.


Figura 4: Apresentação da ferramenta AOPDelphiA 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 aspectadas 2 , 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çãoAAutenticacao = 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;ifFields[0].AsInteger = 0 thenRaise 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;...end;EndAdvice;Advice AutenticaDelete: Before;beginWith DMTaskMan.qryAutentica dobegin...ParamByName('OPERACAO').AsInteger := 3;...end;EndAdvice;//1=Insert, 2=Update, 3=Delete//1=Insert, 2=Update, 3=DeleteEnd.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, cadaunit 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.


7 8 : ; < = > < @ A B C < ; > D > C G I K L B M D O < Q R @ S T < >7/ 2 3DMTaskMan.qryAutentica + (- 1. / 0 *0 + 5 *7 8 : ; < = > < @ A B C < ; > D > C G I K L B M D O < Q V < X7Quadro 4: Método SQLDelete antes do processo de weaving& ( ) * + , & *TClientes.SQLDelete(vId: Integer);%* . / 0 -/ 2 3DMTaskMan.SqlQuery + (- 1. / 0 *Close;Sql.Clear;Sql.Add(’Delete from CLIENTE Where CL_CODIGO = :CL_CODIGO’);ParamByName(’CL_CODIGO’).AsInteger := vID;ExecSql;* 0 + 5* 0 + 5Quadro 5: Método SQLDelete após o processo de weaving& ( ) * + , & *TClientes.SQLDelete(vId: Integer);%* . / 0 -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;UFields[0].AsInteger = 0 2 3 * 0/Raise Exception.Create('Você não tem permissão para essaatividade. ' + Chr(13) +'Entre em contato com o seu superior.');/ 2 3DMTaskMan.SqlQuery + (- 1. / 0 *Close;Sql.Clear;Sql.Add('Delete from CLIENTE Where CL_CODIGO = :CL_CODIGO');ParamByName('CL_CODIGO').AsInteger := vID;ExecSql;* 0 + 5* 0 + 5Conforme 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õesConsiderando 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.


O objetivo deste artigo é apresentar a especificação e implementação de umambiente 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çãoMEDE-PROS, atualmente sendo utilizado no LQS.O artigo está organizado em seis seções. Na segunda seção é apresentado oprocesso de avaliação definido na norma 14598-5. Na terceira seção é apresentado ométodo de avaliação MEDE-PROS. Na quarta seção é abordado o desenvolvimento daferramenta. A quinta seção apresenta um estudo de caso. Finalmente, na sexta seção sãoapresentados 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 normaISO/IEC 14598 é descrito por um conjunto de documentos contendo as atividades aserem realizadas. As normas ISO/IEC 14598-2 e ISO/IEC 14598-6 são relacionadas aosuporte e gestão da avaliação, enquanto as ISO/IEC 14598-3, ISO/IEC 14598-4 eISO/IEC 14598-5 fornecem requisitos e orientações para avaliação. A ISO/IEC 14598-1fornece uma visão geral dos demais documentos (ASSOCIAÇÃO BRASILEIRA DENORMAS 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) eavaliação independente (NBR ISO/IEC 14598-5).O processo de avaliação definido pela norma ISO/IEC 14598-5 fornecerequisitos e recomendações para a implementação prática de avaliação de um produto desoftware, quando várias partes envolvidas necessitam entender, aceitar e confiar nosresultados da avaliação, de modo a garantir a repetitibilidade, reprodutibilidade,imparcialidade e objetividade nas avaliações (ASSOCIAÇÃO BRASILEIRA DENORMAS TÉCNICAS, 2001b, p. 5).Para isto, o processo de avaliação é composto por um conjunto de atividades quesão conduzidas pelos requisitantes e pelo avaliador cooperativamente, conformeilustrado 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 objetivosda avaliação, que podem variar de acordo com o uso pretendido do software e os riscosassociados 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, ouseja, quais funções e componentes do produto serão avaliados. Inclui-se nesta etapa umaanálise da descrição do produto e a definição das medições a serem realizadas durante oprocesso, identificando o nível de importância para todas as características de qualidadea serem avaliadas no software.Na fase de projeto da avaliação é produzido um plano de avaliação baseado naespecificação, que descreve os recursos necessários para a realização da avaliação, bemcomo a distribuição destes recursos nas diversas ações a serem realizadas. Podem serconsiderados 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 dosprodutos e de seus componentes de acordo com o plano. Em paralelo, deve ser feito ogerenciamento da execução da avaliação. Como resultado, obtém-se uma versãopreliminar 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 dorelató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 atendimentoda avaliação segundo as expectativas do solicitante.3. Método de avaliação MEDE-PROSO CenPRA é uma instituição associada ao Ministério da Ciência e Tecnologia, que tema finalidade de desenvolver e implementar pesquisas científicas e tecnológicas no setorde informática, sendo que o domínio e a disseminação do conhecimento tecnológico é oseu foco de atuação. Uma das suas áreas de atuação é a qualificação de produtos eprocessos da tecnologia da informação, sob a responsabilidade da Divisão deQualificação em Software (DQS) que tem como objetivo a geração, aquisição edisseminação de tecnologia para a avaliação de produtos de software. Atualmente, oCenPRA fornece aos avaliadores instrumentos para auxiliar na avaliação de software,por meio detodos 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 deavaliaçõ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 foidesenvolvido para apoiar a avaliação da qualidade de produtos de software sob o pontode vista de um usuário final. O resultado desta avaliação é um relatório da avaliaçãoapontando os aspectos do produto que atendem as normas de qualidade de software e osaspectos 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 emsete 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


4.1. Especificação do softwarePara a especificação do software foi utilizada a análise orientada a objetos com UnifiedModeling Language (UML) e suporte da ferramenta CASE Enterprise Architect. Aseguir são apresentados os diagramas de casos de uso, distribuídos de acordo com osatores do sistema (coordenador, avaliador e requisitante). Uma descrição dos casos deuso 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 osmétodos de avaliação (figura 3).Figura 3. Diagrama de casos de uso do coordenadorAos avaliadores são disponibilizadas funcionalidades referentes à fase deavaliação, como responder as questões do modelo de qualidade, registrar as atividadesde avaliação e ocorrências de erros do produto, além de visualizar o resultado daavaliação através dos relatórios da avaliação (figura 4).


Figura 4. Diagrama de casos de uso do avaliadorO requisitante da avaliação usa o ambiente para solicitar e acompanhar aavaliação, e ao final da avaliação, responder ao formulário de satisfação do clientequanto aos resultados da avaliação (figura 5).Figura 5. Diagrama de casos de uso do requisitante da avaliação4.2. Principais tecnologias utilizadasO 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 AsynchronousJavaScript and XML (AJAX) e a biblioteca JPGraph. Todos os relatórios do sistema sãodisponibilizados nos formatos HyperText Markup Language (HTML) e Rich TextFormat (RTF).A metodologia AJAX foi utilizada para a implementação da interface utilizadapelos avaliadores para preencher o questionário de avaliação (figura 7). Nesta interfacesão listados todos os níveis do modelo de qualidade. Desde as características, suassubcaracterí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 deconteúdo de um modelo de qualidade é bem extensa, não sendo viável carregar eapresentar toda a árvore de conteúdo de uma vez, pois o tempo de resposta para carregaresta página pode comprometer a eficiência da ferramenta. Por isto utilizou-se o conceitode desenvolvimento AJAX.AJAX não é uma nova tecnologia. É uma metodologia de desenvolvimento paraaplicativos web que utiliza um conjunto de tecnologias e padrões: web standards eCascading Style Sheet (CSS), Document Object Model (DOM), Extensible MarkupLanguage (XML), XMLHttpRequest e Javascript (GARRET, 2005). Com o uso destametodologia as aplicações web passam a realizar as requisições ao servidor web deforma assíncrona, não precisando recarregar toda a página a cada requisição. Destaforma, 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çõesdesktop), 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ões4.3.1 ou superiores. Possui dois tipos de licença de uso: uma licença free para utilizaçãoeducacional, e uma versão comercial. Com esta biblioteca é possível criar diversos tiposde gráficos (ADITUS CONSULTING, 2005). Esta biblioteca foi utilizada para ageração do gráfico no relatório estatístico, que informa o percentual de questõesatendidas, atendidas parcialmente, não atendidas, não aplicáveis e não respondidas, dascaracterísticas e subcaracterísticas de um modelo de qualidade.5. Estudo de casoAlém de ilustrar as principais funcionalidades disponibilizadas pela ferramenta, estaseção demonstra a operacionalidade da implementação por meio da utilização dosistema em uma avaliação.Com base nos requisitos levantados e tomando como referência a norma NBRISO/IEC 14598-5 e o método de avaliação MEDE-PROS, definiu-se o ciclo deatividades para o processo de avaliação composto por quatro etapas: levantamento derequisitos, especificação e plano da avaliação, execução e acompanhamento daavaliação e finalização da avaliação.O processo inicia na fase de levantamento de requisitos com a solicitação daavaliação feita pelo requisitante. Nesta etapa o requisitante fornece informações sobre aempresa, o produto a ser avaliado e os requisitos da avaliação (figura 6), o que forneceuma visão dos recursos necessários e dos objetivos que o requisitante deseja alcançarcom a avaliação.Na fase seguinte (especificação e plano da avaliação) o coordenador define omodelo de qualidade a ser utilizado na avaliação, aloca os avaliadores e equipamentos elibera a avaliação para os avaliadores.


Figure 6. Especificação de requisitos da avaliaçãoA próxima etapa é a execução da avaliação. Através de inspeção dadocumentação e testes no software, os avaliadores verificam as características dequalidade no produto, respondendo o questionário da avaliação. A figura 7 ilustra ainterface 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 ejustificar suas respostas.Figura 7. Respondendo questionário de avaliação


Durante a execução da avaliação, o coordenador pode acompanhar o andamentoda avaliação, conforme pode ser visto na figura 8. Na parte superior da interface sãolistados alguns detalhes sobre a execução da avaliação, para cada avaliador. Na partecentral e inferior são encontradas as opções de relatórios, como o tipo de relatório e oformato 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ívelsomente pelo coordenador do relatório, os demais relatórios implementados sãodisponibilizados 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ãocompostos por:a) resultados da avaliação: aspectos positivos e aspectos a serem revistos doproduto;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 dequestõ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 notase 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áficoapenas retrata os dados apresentados na tabela e que é gerada a partir das perguntasrespondidas pelos avaliadores.


CARACTERÍSTICASQUALIDADEINSTALAÇÃO DO SOFTWAREDOCUMENTAÇÃO DO USUÁRIOIMPRESSA E/OU ON-LINEINTERFACE DE USUÁRIOSOFTWAREDESCRIÇÃO DO PRODUTOEMBALAGEMDESINSTALAÇÃOTOTALDEAtende1335.1%11652.3%6871.6%2232.8%1527.3%1765.4%625%25748.9%AtendeParc.12.7%198.6%00%11.5%00%00%00%214%NãoAtende1129.7%2712.2%66.3%23%1018.2%623.1%312.5%6512.4%Não seAplica1232.4%6027%2122.1%4262.7%3054.5%311.5%1562.5%18334.8%NãoResp.00%00%00%00%00%00%00%00%Total37100%222100%95100%67100%55100%26100%24100%526100%Figura 9. Relatório estatístico da avaliaçãoDurante todo este processo, o requisitante pode acompanhar o andamento daavaliação através de uma senha fornecida pelo coordenador. Na fase de finalização daavaliação, o requisitante obtém o relatório final da avaliação e pode preencher oquestionário de satisfação, que serve como um feedback para os avaliadores, com aintenção de melhorar o processo de avaliação.6. ConclusõesO ambiente desenvolvido mostrou-se adequado para o processo de avaliação desoftware 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 assimcomo pelos avaliadores. O ambiente tem mantido um histórico de suas avaliações, o quepoderá ser objeto de análises futuras.Quanto ao processo de avaliação de software suportado pelo ambiente, esteatende as principais atividades recomendadas na norma NBR ISO/IEC 14598-5 e nomé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ãosuportadas pela ferramenta desenvolvida.Tabela 1. Análise de atividades da norma ISO/IEC 14598-5Atividade Subatividade SuportaRequisitosProposta dos requisitos da avaliaçãoSimAcordo formal sobre os requisitosNãoEspecificaçãoDefinição da Abrangência da avaliaçãoSimDefinição das mediçõesSimProjetoDocumentar métodos de avaliaçãoNãoPlanejar ações com base nos recursos disponíveisSimGerenciar componentes do produtoNãoExecução Gerenciar dados da avaliaçãoSimGerenciar ferramentas utilizadasNãoGerenciar entrega dos componentesNãoFinalização Revisão e entrega do relatório da avaliaçãoSimPesquisa de satisfação do clienteSimProcurou-se atender as atividades mais relevantes e que tomavam mais tempodos avaliadores no processo de avaliação. Por este motivo, algumas atividades descritasna norma NBR ISO/IEC 14598-5 não foram contempladas pelo ambiente e atualmentesão realizadas de forma manual, porém não ocasionando atraso significativo no processode avaliação.A tabela 2 apresenta uma análise das atividades do processo de avaliaçãodefinido no método MEDE-PROS com as atividades suportadas pela ferramentadesenvolvida. Percebe-se que basicamente as mesmas subatividades não são suportadaspelo ambiente.Tabela 2. Análise de atividades do MEDE-PROSAtividade Subatividade SuportaDiretrizes do Definir competências dos avaliadoresSimlaboratório Definir configuração dos equipamentos SimProposta de Levantamento de RequisitosSimprestação deserviçoEspecificação e formalização da propostaNãoPlano da Seleção de avaliadoresSimavaliação Seleção de equipamentos SimPreencher CheckList da AvaliaçãoSimElaborar Relatório preliminarParcialmenteExecução daGerenciar recebimento e distribuição dos componentes doavaliaçãoNãoproduto (coordenador)Acompanhamento da avaliação (coordenador)SimElaborar/revisar Relatório final da avaliaçãoParcialmenteFinalização daGerenciar entrega dos componentes do produtoNãoavaliaçãoPesquisa de satisfação do clienteSimCom relação às tecnologias utilizadas, o AJAX se mostrou adequado para aapresentação da árvore que compõe o modelo de qualidade utilizado nas avaliações. Emalguns casos este modelo de qualidade pode ser bastante extenso (como é o caso doMEDE-PROS com um total de 526 questões) o que poderia comprometer a eficiênciado ambiente.


Outro aspecto importante é destacar o uso do ambiente para fins didáticos noensino de engenharia de software na graduação e pós-graduação. Da mesma forma, ouso de modelos de qualidade e manutenção de um histórico de avaliações têm tornadoas aulas mais interessantes e o ensino de tópicos como avaliação de qualidade maisrealistas.Como sugestão para o desenvolvimento de trabalhos futuros e paraaprimoramento do mesmo, sugere-se a inserção de funcionalidades que dêem suporte àsatividades relacionadas com a gerência dos componentes dos produtos de softwareavaliados. 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émsugere-se um estudo mais aprofundado da norma ISO/IEC 14598, abordando o processode avaliação de software para desenvolvedores e adquirentes. Outra funcionalidade a serdesenvolvida é 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/IEC25000. Esta norma está sob estudos e deverá tomar o lugar nas normas ISO/IEC 14598 eISO/IEC 9126.AgradecimentosEste trabalho foi parcialmente apoiado pelo FINEP através do projeto PLATIC.ReferênciasADITUS CONSULTING. JPGraph. [S.l.], 2005. Disponível em:. 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 desoftware – parte 5: processo para avaliadores. Rio de Janeiro, 2001b.BORGES, Jonathan M. Ambiente Web de suporte ao processo de avaliação daqualidade 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: . Acessoem: 29 set. 2006.CENTRO DE PESQUISAS RENATO ARCHER. Manual do avaliador: MEDE-PROS2001. [Campinas], 2004a.COLOMBO, R.; GUERRA, A. The Evaluation Method for Software Product. ICSSEA2002 – International Conference Software & System Engineering and theirApplications, 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:. Acessoem: 23 abr. 2005.


Delphi2Java-II: ferramenta para conversão de formuláriosDelphi em código JavaMauro Marcelo Mattos, Joyce Martins, Israel Damásio Medeiros, Janira SilveiraDepartamento de Sistemas e ComputaçãoUniversidade Regional de Blumenal (FURB) – Blumenau, SC – BrasilCaixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brazil{mattos,joyce,messiah}@inf.furb.br, janira.silveira@gmail.comResumo. Este artigo apresenta uma solução desenvolvida em forma deferramenta, para realizar a conversão de formulários elaborados no ambientede programação Delphi para aplicações na linguagem Java. A ferramentaDelphi2Java-II é capaz de converter componentes de visualização, devisualização de dados e de acesso ao banco de dados. A aplicação convertidasegue o padrão Model-View-Controller.1. IntroduçãoO processo de desenvolvimento de aplicações via de regra está inserido em um cicloevolutivo e requer constantes modificações, seja para corrigir erros, melhorardesempenho ou adicionar novas funcionalidades. No entanto, segundo DMSNet (2004),para muitas empresas produtoras de software e sistemas corporativos, a grandelimitação de seus produtos não se encontra na evolução das regras de negócio domesmo, mas sim, na plataforma de desenvolvimento e no banco de dados para os quaiso produto foi originalmente projetado. Tal limitação afeta seu posicionamentoestratégico e mercadológico, pois inviabiliza a comercialização para clientes com outrasplataformas ou sistemas operacionais. Mas “existem tantos sistemas, que a completasubstituição ou a reestruturação radical é financeiramente impensável para a maioria dasorganizações” (SOMMERVILLE, 2003, p. 533). Para solucionar esse problema, foramdesenvolvidas várias ferramentas visando apoiar a migração de aplicações paraplataformas distintas (FONSECA, 2005; DMSNET, 2004).Atualmente o mercado está polarizado entre duas principais plataformas dedesenvolvimento: Java 2 Enterprise Edition (J2EE) e Microsoft .NET. Segundo Gartner(2003 apud CESAR, 2003), juntas, essas tecnologias terão 80% ou mais do mercado dedesenvolvimento 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 queJava cresceu de 72,2% em 2003 para 77,4% hoje. Ou seja, 77,4% das empresas desoftware usam Java. A pesquisa ainda mostra que 6,3% esperam usar Java até opróximo ano” (PAMPLONA, 2006).Considerando esta demanda pela adoção da tecnologia Java, muitas empresasestão reestruturando seu processo de desenvolvimento ou até mesmo migrando ossistemas desenvolvidos. Para realizar a migração de aplicações Delphi para Java, porexemplo, além da necessidade de conversão da interface gráfica, deve-se tambémconverter o código fonte para que seus componentes visuais mantenham afuncionalidade original, incluindo conexão com banco de dados.


Dentre as ferramentas que podem auxiliar no processo de migração deaplicaçõ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 omesmo objetivo, em 2005 iniciou-se o desenvolvimento da ferramenta Delphi2Java-II(FONSECA, 2005). A partir da análise de formulários Delphi contendo os componentesde interface, são geradas classes Java. Em 2006 a ferramenta foi estendida incluindo aconversão de componentes de visualização de dados, componentes de acesso e conexãoao banco de dados (SILVEIRA, 2006).Assim, neste artigo é apresentada a ferramenta Delphi2Java-II, estando o textoorganizado da seguinte forma: a seção 2 trata de migração de código e geradores decódigo, descrevendo aplicações e etapas de desenvolvimento; a seção 3 apresenta asprincipais funcionalidades da ferramenta, bem como as técnicas utilizadas naimplementação. Por fim, na última seção são apresentados os resultados obtidos e aslimitações da ferramenta proposta.2. Migração de códigoUma das dificuldades enfrentadas pelas empresas de tecnologia é a manutenção e amigração de sistemas para as novas plataformas de desenvolvimento. Para reduzircustos na evolução de sistemas, usa-se a reengenharia de software através da traduçãodos mesmos, quando um código fonte em uma linguagem de programação é traduzidopara 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 amaior parte da tradução (SOMMERVILLE, 2003). Assim, como recurso para amigraçã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 utilizadeterminadas ferramentas para gerar programas. Estas ferramentas podem variar descripts de ajuda muito pequenos a aplicações que transformam modelos abstratos delógica de negócio em sistemas completos, incluindo os geradores de interface com ousuário e os de acesso ao banco de dados. Não há nenhum estilo específico para asferramentas de geração de código (DALGARNO, 2006): podem trabalhar na linha decomando ou possuir uma Graphical User Interface (GUI); podem gerar código para umaou mais linguagens; podem gerar código uma vez ou múltiplas vezes; podem ter umnúmero ilimitado de entradas e saídas.Para a construção de um gerador de código, segundo Herrington (2003), podemser seguidas as seguintes etapas de desenvolvimento: (1º) determinar qual deve ser asaí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 dasinformações extraídas da entrada.3. A ferramenta Delphi2Java-IINeste contexto, Delphi2Java-II foi desenvolvida como um gerador de interface e decódigo para acesso ao banco de dados. Em termos de funcionalidades, a ferramentaimplementa:


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 devisualização de dados, implementada em Delphi através do componenteTDataSource;f) a geração de uma classe contendo a assinatura dostodos para os principaiseventos (onCreate, onDestroy, onClick, onChange, onEnter, onExit, onCloseUp,onKeyPress) habilitados na aplicação Delphi, permitindo que o código sejafuturamente 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 deuso da ferramenta e no Quadro 1 é apresentado o detalhamento deste caso de uso.Figura 1 – Diagrama de caso de uso UC01UC01 - Converter códigoPré-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 salvaros arquivos gerados.2. O usuário seleciona o(s) arquivo(s) que deseja carregar e o diretório onde deseja salvaros 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) epara 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 arquivoselecionado.3.1. Especificando a saídaQuadro 1 – Detalhamento do caso de uso.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, efazendo a conexão com o banco de dados através da API JDBC. Para padronizar edividir 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 PACOTEClasse com os componentes dexxxxxxFRM.javavisualização e visualização de dadosview(layout da interface), sendo xxxxxx onome do arquivo DFM convertido.Classe de eventos de interface, sendoxxxxxxEvent.java xxxxxx o nome do arquivo DFM controllerconvertido.Classe de conexão com o banco deConnectionManager.Java modeldados.Classe que representa os campos dastabelas acessadas, incluindo osBeanTByyyyyy.javamétodos de inclusão, alteração emodel/beanexclusão, sendo yyyyyy o nome databela. É gerada uma classe Bean paracada tabela acessada.Classe que contém as consultas aserem executadas, sendo yyyyyy o nomeCursorTByyyyyy.javado componente de acesso ao banco demodel/cursordados. É gerada uma classe desse tipopara cada componente de acesso aobanco de dados.Quadro 2. Estrutura das classes geradas pela ferramenta Delphi2Java-IITendo em vista que a versão atual do Delphi2Java-II foi desenvolvida paraacesso ao banco de dados Oracle8i, deverão ser adicionadas, nas propriedades doprojeto, as bibliotecas da API JDBC (classes12.jar, classes12dms.jar,nls_charset12.jar) para acesso ao banco de dados.3.2. Analisando formulários DelphiA entrada da ferramenta são formulários Delphi. Para cada formulário de uma aplicaçãodesenvolvida em Delphi tem-se um arquivo com extensão DFM, contendo todas asinformações dos componentes da interface.object Form1: TForm1Left = 192Top = 114Width = 213Height = 169...object Button1: TButtonLeft = 64Top = 48Width = 75Height = 25Caption = 'Abrir'TabOrder = 0endendnome do objetolista de propriedadesQuadro 3. Exemplo de um arquivo DFMobjeto componenteFigura 2. FormulárioCada componente tem uma identificação, uma lista de propriedades com valoresassociados e outros possíveis objetos componentes (SASSE, 2005). O Quadro 3 mostraum arquivo DFM e a Figura 2 mostra o formulário correspondente.Como um arquivo DFM é organizado de uma maneira hierárquica, sua estrutura


pode ser descrita usando a notação Extended Backus-Naur-Form (EBNF), conforme oQuadro 4, onde os símbolos entre chaves podem ocorrer zero ou mais vezes e ossímbolos entre colchetes são opcionais.Para analisar os arquivos DFM e extrair as informações necessárias para gerar asaída foram utilizados os analisadores léxico, sintático e semântico, móduloscomponentes 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 asunidades léxicas estão dispostas de acordo com estrutura gramatical definida no Quadro4. E o analisador semântico extrai e armazena as informações do arquivo DFMnecessárias para gerar a saída.::= ::= OBJECT identifier ":" identifier { } { } END::= identifier ["." identifier] "=" ::= ["+" | "-"] (integer | real)| string| FALSE| TRUE| identifier ["." identifier]| ""| "[" [ { "," } ] "]"| "(" { } ")"| "{" { } "}"::= identifier { } ENDFonte: adaptado de Souza (2005).Quadro 4. Gramática3.3. Gerando classes JavaDepois de extraídas as informações do formulário principal da aplicação, inicia oprocesso de conversão. Buscando simplicidade e flexibilidade na construção daferramenta, optou-se pelo uso de templates, de forma a manter a formatação do códigoseparada da lógica que determina o que deve ser construído. No Quadro 5 tem-se ocódigo gerado pela ferramenta para o objeto Button1 do Quadro 3, usando o templatedo 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 TButtonCom a Velocity Template Language (VTL), linguagem do motor de templatesVelocity (MOURA; CRUZ, 2002), foram definidos 10 templates que possuem, além doconteúdo estático, um código dinâmico composto por variáveis e comandosestruturados que são substituídos quando do seu processamento. Assim, para aimplementaçã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çõesextraídas do arquivo DFM e os elementos dos conteúdos dinâmicos definidos nos


templates; carregar os templates; substituir adequadamente as referências definidas nostemplates pelos valores dos objetos Java de acordo com o contexto; e, gerar o arquivode saída....#foreach ($TButton in $arrayButton) código dinâmico...${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())#end#end...${TButton.getName()}.setEnabled(${TButton.getEnabled()});Quadro 6. Template com definição do componente TButton3.4. usando o Delphi2Java-IIcódigo estáticoA Figura 3 apresenta uma seqüência de telas que permitem a visualização dofuncionamento da ferramenta .passo 01: selecionar arquivos para conversãopasso 02: selecionar diretório para salvar arquivos geradospasso 03: selecionar opção de conversãoFigura 3. Delphi2Java-II


O primeiro passo para realizar a conversão dos formulários é identificar a sualocalização num diretório qualquer. Todos os arquivos com extensão DFM são listadospara 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 Paraarquivo(s) selecionado(s) e gerar código Para todos os arquivos carregados (emArquivos .DFM). Os componentes que a ferramenta não reconhece e cuja conversãopara Java ainda não foi contemplada, são listados em Componentes não convertidos.Delphi2Java-II foi implementada na linguagem Java, utilizando o ambiente dedesenvolvimento Eclipse 3.0, a biblioteca gráfica Swing e o JDK na versão 1.4.2. Omotor de templates Velocity foi utilizado através da biblioteca velocity-dep-1.3.jar.3.5. Validando a ferramentaPara validar a ferramenta, foram desenvolvidos vários formulários utilizando oambiente Delphi 7.0. Nos testes foi utilizado o banco de dados Oracle8i. Como exemplode utilização de Delphi2Java-II, a Figura 4(a) mostra um arquivo DFM contendo várioscomponentes possíveis de serem convertidos e a Figura 4(b) mostra a interfacecorrespondente em Java.Figura 4. Formulários Delphi e Swing com componentes de banco de dados.4. Resultados e limitaçõesO presente trabalho descreveu as principais características da versão atual da ferramentaDelphi2Java-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 noque se refere à conversão dos componentes de visualização. No entanto, a 1a versão deDelphi2Java-II (FONSECA, 2005) e DelphiToWeb (SOUZA, 2005) não convertemformulários que contenham componentes de visualização de dados e componentes deacesso ao banco de dados.


Quanto aos eventos encontrados no arquivo DFM, as duas versões deDelphi2Java-II geram código para manipulá-los. A 1a versão de Delphi2Java-IIdisponibiliza uma classe de eventos contendo apenas as assinaturas dostodos queestão habilitados na aplicação original em Delphi. A versão atual, além de gerar asassinaturas desses métodos, inclui outros para carregar valores para os componentes devisualização de dados. Cabe ressaltar que, devido ao fato de apenas a versão deDelphi2Java-II descrita nesse trabalho efetuar a geração de mais de dois arquivos desaída, é a única que padroniza e divide o código gerado em camadas, utilizando opadrã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 deanalisadores léxico, sintático e semântico. Essa solução, descrita em Souza (2005), foireutilizada para implementar a ferramenta proposta nesse trabalho. Por fim, foramespecificados templates, modelos que servem como guia para a geração de código desaída. No Quadro 7 é apresentada uma comparação entre as ferramentas levando emconsideração suas principais características.CARACTERÍSTICASDelphi2Java-II(FONSECA,2005)DelphiToWeb(SOUZA,2005)Delphi2Java-II(SILVEIRA,2006)conversão de componentes devisualização27 22 22conversão de componentes devisualização de dados- - 7conversão de componentes deacesso ao banco de dados- - 4tratamento de eventos sim - simgeração de código de saída nopadrão MVC- - simuso de analisadores (léxico,sintático e semântico) para - sim simleitura do arquivo DFMuso de templates para geração decódigo- - simQuadro 7. Comparação entre ferramentasAtualmente, através de um projeto do PIBIC/CNPq, está sendo desenvolvidauma nova versão que envolve a conversão de código fonte object pascal dos tratadoresde evento de componentes de interface já convertidos. Posteriormente pretende-seexplorar o projeto para conversão do código fonte Pascal (incluindo código de acesso aobanco de dados).Como extensões da ferramenta estão sendo consideradas as seguintespossibilidades: 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 HTMLou JavaScript, bastando definir o template que servirá de modelo para o código a sergerado.AgradecimentosParte deste trabalho foi financiada com bolsas de iniciação científica do PIBIC/CNPq.


ReferênciasCESAR, R. Java X .NET: disputa acirrada no mercado nacional. ComputerWorld, São Paulo,n. 387, jun. 2003. Disponível em: . Acesso em: 26 mar. 2005.DALGARNO, M. Frequently asked questions about code generations. [S.l.], 2006.Disponível em: . Acesso em: 29 abr. 2006.DMSNET. Migração / conversão de sistemas para Java (J2EE). [S.l.], 2004. Disponível em:. 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 deCiê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: . 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: . Acesso em: 02 fev. 2006.ROBINSON, S. L. Delphi to Java conversions. [S.l.], [2004?]. Disponível em:. Acesso em: 31 maio 2006.SASSE, E. Convertendo arquivos DFM binários para texto. [S.l.], [2005?]. Disponível em:. Acesso em: 8 maio2005.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 debanco de dados. 2006. 81 f. Trabalho de Conclusão de Curso (Bacharelado em Sistemas deInformaçã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 deCiências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.


Informática na Educação: ensino presenciale educação a distânciaAna Isabel de Azevedo Spinola Dias 1 , Wanderley Moura Rezende 21 Departamento de Análise – Universidade Federal Fluminense (UFF)Niterói, RJ – Brasil2Departamento de Matemática Aplicada – Universidade Federal Fluminense (UFF)Niterói, RJ – Brasil e CEDERJ{belspinola,wanderley.rezende}@gmail.comRua Mário Santos Braga, Valonguinho, Centro, Niterói, RJ, Brasil, CEP 24.020-140Telefones: 2629-2058 e 2629-2070Resumo: Apresentamos uma reflexão sobre o impacto da educação adistância no ensino presencial, analisando a parceria entre as práticas eteorias da EAD e as do ensino presencial, parceria esta essencial para oaprimoramento da educação em seu sentido amplo, com novas posturasacadêmicas.1. IntroduçãoSão notórias as mudanças tecnológicas, econômicas e político-sociais queocorrem no mundo de hoje. A cada dia surgem novas tecnologias que interferemdiretamente (ou indiretamente) no nosso cotidiano. Computadores, celulares, cartõesmagnéticos são, por exemplo, algumas das tecnologias que já fazem parte do cotidianoda nova geração de adolescentes. Novas maneiras de pensar e de conviver estão sendoelaboradas no mundo das telecomunicações e da informática. Segundo Levy(1993), “asrelações entre os homens, o trabalho, a própria inteligência dependem, na verdade, dametamorfose incessante de dispositivos informacionais de todos os tipos. Escrita,leitura, visão, audição, criação, aprendizagem são capturados por uma informáticacada 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 defazer uma apologia à educação a distância, mas, sobretudo, de, no embate de forçasdesta 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 dofuturo, porque não dizer do presente. E nesse sentido, pode-se afirmar que as novastecnologias produzidas e inseridas no âmbito da educação a distância constituem umfecundo 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çãoNo 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: redesmundiais de universitários e pesquisadores, redes empresariais, correios eletrônicos,comunidades virtuais se desenvolvendo sobre uma base local, acesso direto a bases dedados 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%. Em1994, mais de 20 milhões de pessoas, essencialmente jovens, estavam “conectados”. Asprevisões giram em torno de 100 milhões de usuários para o ano de 2000. Graças às redesdigitais, 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 àsinformações públicas contidas nos computadores que participam da rede, dispõem da força decálculo de máquinas situadas a milhares de quilômetros, constroem juntos, mundos virtuaispuramente lúdicos – ou mais sérios – constituindo para os outros uma imensa enciclopédiaviva, desenvolvem projetos políticos, amizades, cooperações..., mas dedicam-se também ao ódioe a enganação”. (Levy, 1998, p.12)É evidente, nesse sentido, o papel central que as novas tecnologias deinformação e comunicação (NTIC's) vêm desempenhando neste processo detransformação. Assim, com o desenvolvimento das NTIC's e da própria Internet, novasmaneiras de pensar e de agir são freqüente e rapidamente re-elaboradas em nossasociedade informatizada. As relações entre homens, trabalho e a própria inteligênciadependem, na verdade, da metamorfose incessante de dispositivos informacionais detodos os tipos. Escrita, leitura, visão, audição, criação e aprendizagem sãopotencializadas por uma informática cada vez mais avançada. O cenário que seapresenta se constitui ao mesmo tempo como um desafio e uma oportunidade ao mundoda educação conforme nos revela Dowbor(2001):É um desafio, porque o universo de conhecimentos está sendo revolucionado tãoprofundamente, que ninguém vai sequer perguntar à educação se ela quer se atualizar. Amudança é hoje uma questão de sobrevivência, e a contestação não virá de “autoridades”, e simdo crescente e insustentável “saco cheio” dos alunos, que diariamente comparam os excelentesfilmes e reportagens científicos que surgem na televisão e nos jornais com as mofadas apostilase repetitivas lições da escola.Segundo Dowbor(2001), as transformações que vêm ocorrendo em todo oplaneta estão, no entanto, “muito além de uma simples mudança de tecnologias e decomunicação e informação”. Para o educador, estas transformações devem ser incluídasem nossa visão sobre educação. Não se trata apenas de mudar a técnica de ensinofazendo o uso de novas tecnologias, mas, sobretudo, de modificar a própria concepçãode ensino e de repensar os seus caminhos. Hoje em dia não se aprende apenas no prédiofísico da escola, mas em casa, no escritório ou em qualquer lugar que se possa teracesso à informação. Da mesma forma como a inteligência humana inventa novasferramentas tecnológicas, existe um efeito inverso: a tecnologia modifica a expressãocriativa 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 quegrande parte da população brasileira ainda tem dificuldades de acesso às vias públicas eregulares da escolaridade normal. Assim, fazendo uso de novas tecnologiascomputacionais e da informação, uma nova modalidade de educação vem se


apresentando como promissora (e muitas vezes como a única possibilidade) napaisagem educacional para grande parte dos nossos atores sociais: a educação ou ensinoa distância. Mas será que esta modalidade educacional, apresentada no cenárionacional como solução para certos problemas locais da educação brasileira, serve comoparadigma para a educação do futuro? É exatamente sobre isso que pretendemosdiscorrer nos parágrafos seguintes.3. Ensino a distância versus ensino presencialO que é Educação a Distância?Segundo Petters(2001), já existem pelo menos três gerações de ensino adistância. A primeira geração, que utiliza o material impresso como meio principal, foidenominada pelo autor como ensino a distância por correspondência. A segundageração foi caracterizada pelo autor tomando como exemplo a experiência da OpenUniversity inglesa, que realiza um ensino a distância que combina outros meios aserviço do ensino acadêmico: televisão, rádio e os centros de estudo. E como exemplode um ensino de terceira geração, Petters cita o Project Contact North que faz uso dosmeios digitais e “toma por base do processo de ensino e aprendizagem nada menos doque quatro formas de teleconferência”. Pelo que expõe o autor, as gerações de ensino adistância podem ser identificadas pelo nível de desenvolvimento dos meios e dastécnicas para se atingir as metas do ensino a distância. Mas, em que consistem essasmetas? O que caracteriza o Ensino ou Educação a Distância?Em verdade, existem diversas denominações e conceituações a respeito dessamodalidade. Preti(1996) observa, por exemplo, que muitos acadêmicos não fazemdistinçã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, masquando ela se estende à práxis educativa compromete ainda mais aquilo que se entendepor 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 osprocessos de libertação do homem em direção a uma sociedade mais justa, solidária eigualitária”. Cabe destacar, entretanto, que tal proposta deve ser estendida a qualquerprática educativa, seja ela “a distância” ou “presencial”, seja ela “especial” ou“convencional”, ou mesma de qualquer outra modalidade. A diretriz desenhada acimasempre foi, sem sombra de dúvida, a grande utopia (utopia usada aqui no sentido quePaulo Freire tão bem delineou em seus trabalhos: como “aquilo que é possível, quemobiliza e motiva a ação educativa, meta a ser atingida”, e não como algo “impossívelde ser realizado”) que tem motivado grandes educadores (o próprio Paulo Freire foi umdeles) em seus trabalhos de campo ou de pesquisa, antes mesmo da EAD ter-se tornado1Derivado do latim – educatio, do verbo educare (instruir, fazer crescer, criar), próximo deeducëre (conduzir, levar até determinado fim) –, a palavra educação sempre teve seu significadoassociado à ação de conduzir a finalidades socialmente prefiguradas, o que pressupõe a existência e apartilha 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 é arelação educativa entre o estudante e o professor que não é direta, mas “mediada emediata””. Para Garcia Aretio(1995, apud, Preti, 1996), a EAD distingue-se damodalidade de ensino presencial por ser “um sistema tecnológico de comunicaçãobidirecional que pode ser massivo e que substitui a interação pessoal na sala de aulaentre professor e aluno como meio preferencial de ensino pela ação sistemática econjunta de diversos recursos didáticos e o apoio de uma organização e tutoria quepropiciam 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 desenvolvimentoda autonomia dos estudantes nos processos de aprendizagem; “o estudantedeve aprender a construir seu caminho, seu conhecimento por ele mesmo”;− processo de ensino-aprendizagem mediatizado: a mediatização ocorreatravés do material didático 3 , meios tecnológicos, sistema de tutoria e deavaliação;− o uso de tecnologias: o rápido e crescente desenvolvimento de recursostécnicos de comunicação e de informática têm possibilitado cada vez maisromper com as barreiras das distâncias, das dificuldades de acesso àeducação e dos problemas de aprendizagem de quem “estudaindividualmente, 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; “oestudante não é mero receptor de informações”.Portanto, ao nos depararmos com os elementos constitutivos listados pelopesquisador, podemos perceber que algumas características e metas da EAD fazem (oudeveriam fazer) parte de um processo educacional em sentido amplo. De fato, acomunicação bidirecional, o formato dialógico do material didático, o uso detecnologias deveriam ser também características e metas de qualquer modalidade deeducação. Por isso, não poderíamos tomar esses elementos constitutivos comoelementos diferencias entre a EAD e a educação presencial, a menos, é claro, doprimeiro elemento que circunstancia e justifica a ação da primeira modalidade deeducação.Isto posto, pode-se afirmar então que o que distingue a EAD da modalidadepresencial é efetivamente a sua circunstância: a distância física entre o aluno e o seuprofessor. No entanto, cabe ressaltar que na modalidade presencial, se não existe adistância física, existem também outros tipos de distâncias na relação professor-aluno: a2Importante que se diga que Oresti também não pretendia que este fosse o elemento diferencialentre a EAD e a educação convencional.3Cabe ressaltar aqui o formato dialógico presente na linguagem escrita do material didático: alémde tornar a leitura mais agradável, faz com que o aluno desenvolva o processo de construção doconhecimento de forma mais crítica e consciente.


distância da linguagem, a distância de metas e objetivos, etc. Por outro lado, é notável ogrande esforço que alguns educadores têm feito na tentativa de minimizar essasdistâncias no ensino presencial. Assim, ao que parece, poder-se-ia concluir que um dosprincipais objetivos do ato educativo em qualquer modalidade, seja na modalidadepresencial ou na modalidade a distância, é minimizar as distâncias. E nesta nobre açãode minimizar as distâncias, a parceria entre as teorias e as práticas da EAD e as domodelo presencial é de fundamental importância para o aprimoramento da práticaeducativa em seu sentido amplo. Neste sentido, cabe destacar que o uso de novastecnologias, prática tão comum na EAD, tem-se mostrado um instrumento em potencialpara a redenção e renovação da didática.4. Novas tecnologias: o resgate da didáticaPara discutir alternativas para a estrutura do ensino nas condições de um mundoglobalizado onde é possível o uso de novas tecnologias para a produção e transmissãode conhecimento, vamos colocar em destaque os relacionamentos que existem nocenário educacional.4.1 Tipos de Relacionamentos no Cenário EducacionalEm qualquer cenário educacional podemos evidenciar diversos relacionamentosimportantes acontecendo ao mesmo tempo. Para analisarmos as possíveis relaçõesexistentes distinguimos classes de atores deste cenário: classe dos alunos, classe dosprofessores e classe do próprio saber (dos conteúdos).Em uma situação ideal de aprendizagem, seja presencial ou a distância, cadaclasse está relacionada com ela própria, o que é assinalado na figura acima pelas setascurvas. Desta forma estamos enfatizando:− A interação entre alunos que permite que eles troquem idéias, dúvidas erespostas sobre o conteúdo;− Relacionamentos entre os professores que trocam idéias e partilhamexperiências;− Relacionamentos entre os próprios conteúdos que, hoje em dia, surgem e serenovam em alta velocidade. Isto faz com que num espaço bem curto detempo muitos conhecimentos novos surjam e outros se renovem.


Estas são as relações entre entes da mesma classe. Mas podemos ainda pensarnas 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 asdistâncias envolvidas nestes relacionamentos que estão sendo abordados.4.2 As Novas Tecnologias Alterando os Tipos de RelacionamentosAs mutações contemporâneas nas relações entre os atores humanos do cenárioeducacional – sejam entre alunos, entre professores ou entre alunos e professores – sedevem em grande parte ao uso de ferramentas de comunicação síncronas e assíncronastais como fóruns, chats, e-mail e listas de discussão.Vamos refletir sobre o relacionamento de humanos com o saber, tanto de alunosquanto de professores. A natureza destes relacionamentos vem mudando ao longo dosanos face à utilização das novas tecnologias que disponibilizam, de formas variadas,uma riqueza muito grande de conteúdo. Os recursos multimídia, por exemplo, permitemum envolvimento multissensorial e intelectual dos alunos com os saberes. Usam aaudição, a visão, a fala, o tato e até o olfato, como apontam pesquisas recentes, emalgumas vezes; em oposição à maneira unissensorial de se relacionar com o conteúdooferecida por uma aula expositiva. Tudo isto acaba gerando uma nova forma deperceber o conteúdo, e portanto, uma nova forma de se apropriar dele. Além do uso dedeo, 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 aoconteúdo e ao saber. Tais recursos muitas vezes requerem do aluno tomadas dedecisões, e conseguem transformar o aluno passivo em um participante ativo naconstrução de seu saber. Conseguem-se interações bem mais intensas com o uso dasmídias eletrônicas, como bem é abordado em Pina(1998).4.3 O Resgate da Didática – Novas Concepções e Novas DemandasNeste momento nos remetemos a Borba(2001), que chama atenção para o fatode que a questão contemporânea não é mais se as novas tecnologias devem ou não estarpresentes no ensino. O autor discute, inclusive, o fato de que o lápis e o papel tambémsão tecnologias que empregamos indiscriminadamente no ensino e nem por issoparamos para questionar se o aluno fica ou não dependente dessas mídias. Não deveriaser esta a questão discutida. As novas tecnologias estão cada dia mais presentes na vidadas pessoas (estudantes e professores), e isto é um fato incontestável. Elas são novosatores no cenário educacional. A questão relevante deveria ser: como agregá-las ao diaa-diado professor? Como adequar os métodos de trabalho? Como minimizar asdistâncias relatadas na introdução? Como conciliar as técnicas de EAD com o ensinopresencial? Como viabilizar esta modificação? Como escolher um software que sejaadequado ao conteúdo trabalhado, por exemplo? Que critérios utilizar na escolha? Queferramentas utilizar em cada situação didática? Como fazer um bom uso das novastecnologias disponíveis em prol de um melhor aproveitamento dos alunos? Queambiente computacional usar para melhor alcançar objetivos educacionais? Epoderí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 naprática o que é exaustivamente analisado em Belloni(1999):“Não é possível o uso das NTIC´s sem profundas mudanças nos modos deensinar e na própria concepção e organização dos sistemas educativos, gerandoprofundas modificações na cultura da escola.”Em outras palavras, não é viável o uso de novas tecnologias de informação ecomunicação no ensino sem profundas reformulações na maneira de ensinar, visto quenovas formas de aprender exigem novas formas de ensinar. Neste sentido enxergamos ouso das novas tecnologias no processo educacional como um resgate da didática. Umadidática que aponte alternativas para o ensino inserido neste mundo contemporâneo. Aforça inovadora que a informática na educação traz potencialmente sempre foineutralizada pela força do modelo arcaico da educação nas escolas. Ainda hoje existemescolas que impedem os professores de entrar nos laboratórios de informática. Sequiserem desenvolver algum trabalho com os alunos, o professor deve passar para oprofessor de informática (ou orientador tecnológico) o que deve ser feito.Apesar de concordarmos com a importância do uso das novas tecnologias noensino devemos apontar que, salvo exceções, seu uso é ainda bastante incipiente namaioria das instituições de ensino. Há uma necessidade muito grande de experiênciasde uso das NTIC´s em cursos de graduação para gerar mais questionamentos quepossam alimentar e aprofundar essa reflexão.O uso responsável de novas tecnologias no ensino envolve ainda outra questãofundamental a ser considerada, que é a da segurança da informação. Vivemos numtempo em que navegar na Internet pode ser perigoso, e o aluno deve ser alertado epreparado para isso. O ambiente escolar pode e deve estimular o uso da Internet comoferramenta didática, desde que também ofereça conhecimentos para que os alunos nãofiquem vulneráveis na rede. As redes de transferência peer-to-peer, as redes derelacionamento e as redes de comunicação instantânea são usadas em grande escala porjovens e adolescentes que, em sua maioria, desconhecem os perigos existentes em seuuso. A Internet não é segura para crianças; elas precisam ser orientadas. Entre ospossíveis perigos existe o da pedofilia. Segundo Chappell(2006), uma simulação feitapela Internet Safety for Kids (www.packet-level.com) criou perfis de crianças de até 13anos e entrou em chats e comunicadores instantâneos. Constatou que em 100% doscasos 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 futuroO modelo medieval de transmissão de conhecimento foi profundamente abaladopela revolução que o livro impresso fez. O ensino passou por mudanças estruturais facea esta nova tecnologia. Com o advento da TV e do videocassete, a produção de teleaulase vídeos educativos tornou-se uma “coqueluche educacional”: uma imagem valemais que mil palavras. O programa TV Escola, da SEED/MEC (Secretaria de Educaçãoa Distância) destinado exclusivamente à educação, conta com um grande acervo de


deos educativos de alta qualidade e pode ser usado de forma a melhorar aaprendizagem como apontado em Motta&Lopes(2002). Neste artigo as autoras sugeremainda a utilização de um sistema de recomendação voltado para equipes. A revoluçãodos meios digitais nos pede agora um novo modelo de produção/transmissão deconhecimento. Que novo modelo seria este? Vamos tentar imaginá-lo hipoteticamente egerar a nossa própria utopia, no sentido descrito neste artigo anteriormente.Nosso aluno hipotético, Bruno, nasceu em 1995 e, portanto, está agora com 20anos. Está cursando a graduação em Engenharia de Alimentos, uma carreira já antiga emultidisciplinar. Em 2010, Bruno optou por sua carreira depois de um longo trabalho deorientação vocacional desenvolvido em sua escola. Bruno assistia, na escola,semanalmente, pela TV Digital Interativa, a palestras com profissionais do mundo todode 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 aosprofissionais que estavam on-line e respondiam suas dúvidas. Foi numa destas palestrasque Bruno fez contato com o diretor de uma indústria de produtos alimentícios que oconvidou para conhecer um dia de trabalho efetivo de uma pessoa da área deracionalização e melhoria de processos e fluxos produtivos para incremento daqualidade e produtividade, e para redução dos custos industriais. Empolgado eelucidado 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 seishoras por dia numa escola contendo salas equipadas, cada uma, com dez mesas ecadeiras individuais, duas mesas maiores para trabalhos em grupo, dez computadoressendo um deles ligado permanentemente a um datashow, uma televisão com tela deplasma de 71 polegadas e com decodificador e aparelho de DVD embutidos, isolamentoacústico, prateleiras com livros, prateleira com DVD´s e mapas nas paredes. TantoBruno quanto seus colegas e professores lidam muito bem com todas as tecnologias emquestão. Os conceitos são trabalhados através de temas de interesse da turma eculminam no desenvolvimento de projetos realizados por alunos. As aulas podem teruma parte expositiva para explanação geral do encaminhamento dos trabalhos oumesmo para exposição feita pelos alunos a respeito de seus projetos para localizaralguma dúvida que possa ser compartilhada/discutida pela turma. Os alunos trabalhamincessantemente na busca dos conhecimentos necessários para a realização de suatarefa, mas não precisam estar todos ao mesmo tempo fazendo a mesma atividade. Oprofessor 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órunspropostos pelos professores) e os livros da estante para aprofundar seu conhecimento erealizar sua tarefa. Têm palestras periódicas sobre segurança da informação para seconscientizar dos perigos existentes na rede, aprender a usá-la com responsabilidade econhecimentos para não ficar vulneráveis a situações de risco. A TV digital é usadasempre que necessário. Os alunos são atores ativos na realização da tarefa de construçãode conhecimento. Seus professores têm excelente formação, são bem remunerados e sededicam a sua própria capacitação/atualização constantemente. Trabalham de formainterdisciplinar e não raramente propõem atividades interdisciplinares para a turma. Emespecial, as aulas práticas de língua estrangeira acontecem durante pesquisas na Internete debates entre grupos. Como a tarefa dos professores não se limita à transmissão de


algum conhecimento previamente estabelecido, eles conseguem estimular eproporcionar a pesquisa em sala de aula. Acima de tudo, esta escola consegue formaralunos felizes, com uma formação sólida e não fragmentada, e conscientes de seu papelnuma sociedade de recursos naturais finitos.6. ConclusãoPor mais que as novas tecnologias já estejam presentes em nosso meio há algumtempo, ainda precisamos viver algumas transições nesse longo percurso.• Em primeiro lugar, é preciso que se faça uma análise crítica das possibilidades elimitações no uso das NTIC's tendo como meta a implementação de uma educaçãomais progressista e menos excludente. A política de informática da educação temque passar de elitista a inclusiva.• Sabe-se, todavia, que o uso das NTIC's produzem profundas transformações noambiente educacional, no processo ensino-aprendizagem e exigem por sua veznovas 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 sistemaseducativos 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 estimuladase incrementadas, principalmente no que está relacionado aos cursos de Licenciatura,formadores da consciência cidadã. Não basta assimilar informática, Internet e outrastecnologias do conhecimento; a formação de professores tem que se tornar maisefetiva neste sentido.Considerando as transformações no universo do conhecimento e das ferramentasde trabalho, torna-se evidente que a educação deva repensar o seu paradigma e procurarassimilar a dinâmica desta sociedade mutante. Entretanto, esta transformaçãopedagógica não pode perder de vista a tradição e os valores da humanidade. Comoreflexão deixamos a mensagem de uma testemunha da Segunda Guerra Mundialdirigida 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 seimpõ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 emvalores tradicionais da humanidade, do ser (verbo) humano.ReferênciasBelloni,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 NovasTendências em Educação Matemática, Belo Horizonte, Editora Autêntica.Chappell,L. (2006) Entrevista dada à revista Security Review, a revista do gestor deSegurança da Informação, ano II, nº 8.Dowbor, L. (2001) “Tecnologias do Conhecimento. Os desafios da Educação” Rio deJaneiro: Vozes.Levy, P. (1993), “As Tecnologias da Inteligência. O Futuro do Pensamento na Era daInformática” São Paulo: Editora 34.Levy, P. (1998), “A Inteligência Coletiva. Por uma Antropologia do Ciberespaço” SãoPaulo: Edições Loyola.Machado, N. J. (2000), “Educação: Projetos e Valores” Coleção Ensaios Transversaisvol.5. São Paulo: Escrituras Editora.Motta, C.L.R. da e Lopes,L.M.C. (2002), “Sistema de Recomendação apoiando a TVEscola”. 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 daDiscussão numa Visão Internacional” Trad. Ilson Kayser. São Leopoldo: EditoraUnisinos.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 AmbientesMichele A. Tobaldini 1 , Jacques D. Brancher 21Departamento 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.brResumo. Este artigo descreve o desenvolvimento e utilização de um ambientecom aspectos biogeográficos reais e arquiteturas históricas, para inserção demissões didáticas. Essas, contextualizadas com os cenários, objetivando geraruma maior imersão do usuário em um jogo educacional computadorizadopara alunos de 5ª a 8ª séries do Ensino Fundamental.1. IntroduçãoO 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 apresentasea 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 GameDe 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 Gamesdigitais e determinados aspectos relativos à estes.3. Role-Playing Games DigitaisSegundo 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 FinalFantasy.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 NeverWinterNights.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 MotorO 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 –


eino 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 jogoO outro elemento de jogos computacionais é o motor, também conhecido comoengine. Para isso, foi utilizado o OGRE (2006) (Objectc-oriented Graphics RenderingEngine) 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 ProgrammingInterface) 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 RPGNo 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 referesea 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 JogoNos 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 AlpsDumen, um personagem que vive nas montanhas e é guardião da gema do Reino deAzon (Figura 3).Figura 3. NPC Alps Dumen5. Desenvolvimento do AmbienteO 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 JogoDe 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 Mightem 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 ContextualizadasPara 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óriaNo 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 arquiteturasO 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 CardeaisEm 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ãoDevido 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ênciasAndrade, 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 Visualização de Conteúdos de 5 a à 8 aSéries Utilizando X3DLuis Biondo, André Brandão, Michele Tobaldini 1 , Jacques Brancher 11 Universidade Regional Integrada do Alto Uruguai e das MissõesCampus de Erechim, Brasil{lfbiondo,brandaoihc,matobaldini}@gmail.com, jacques@uri.com.brResumo. Este artigo descreve um ambiente virtual para a web que apresentaconteúdos de 5 a a 8 a séries do Sistema Brasileiro de Ensino Fundamental. Osoftware oferece aos usuários uma maneira para explorar conteúdos didáticosdas disciplinas de Ciências Naturais, Geografia, História, Língua Portuguesa eMatemática, disponibilizados em módulos no ambiente virtual, de acordo comsua complexidade. Para o desenvolvimento deste ambiente, foi utilizada a tecnologiaX3D. Por fim, o sistema oferece uma alternativa para os usuários localizareminformações de uma maneira diferenciada e gráfica, com a utilizaçãode interação não-imersiva.1. IntroduçãoO ensino fundamental brasileiro possibilita aos estudantes uma aprendizagem em salasde aula, com contato direto com professores. Ainda que a criatividade de profissionais daárea pedagógica auxilie no processo de aquisição de conhecimento, por vezes estudantespodem necessitar de um atrativo a mais para buscar conteúdos de uma forma diferenciada.Com o desenvolvimento da computação e aplicação da mesma na educação, tornou-sepossível simular ambientes tridimensionais (3D) virtuais para a navegação de pessoas emlugares de difícil acesso, dependendo do caso.A Realidade Virtual surge como opção para que estudantes tenham uma alternativadiferenciada para a aprendizagem. Através da imersão proporcionada pela realidadevirtual, deseja-se que os estudantes adquiram conhecimento pois a interatividade despertamaior interesse na aprendizagem [Pinho 1996]. Alguns aspectos colaboram para a realidadevirtual ser utilizada na educação entre eles pode-se destacar: maior motivação dosusuários, o poder de ilustração da Realidade Virtual para alguns processos e objetos émuito maior do que outras mídias, permite que o aprendiz desenvolva o trabalho no seupróprio ritmo, não restringe o prosseguimento de experiências ao período da aula regular,permite que haja interação, e desta forma estimula a participação ativa do estudante[Pantelidis 1995].Partindo-se desta premissa, a proposta do presente trabalho é apresentar um ambiente3D, construído em X3D [Resources b] para visualização de conteúdos de 5 a a 8 aséries do Ensino Fundamental. Inicialmente, acadêmicos das áreas específicas, com experiênciapedagógica, selecionaram os conteúdos didáticos das áreas de Ciências Naturais(Biologia, Física e Química), Geografia, História, Língua Portuguesa e Matemática, vistosneste período do aprendizado estudantil. A seguir, identificaram os assuntos abordados,organizando-os desde os mais fáceis até os mais difíceis, considerando o grau de complexidadedesses. É importante ressaltar que, devido à grande quantidade de conteúdos


didáticos, apenas alguns de cada disciplina foram escolhidos, tendo em vista os maisessenciais para os alunos das séries abordadas.Assim, este artigo apresenta um ambiente de visualização de conteúdos de 5 a a8 a séries, dividido em módulos. Para este fim, o texto está dividido da seguinte forma:No item 2, é feita uma breve revisão bibliográfica, na seqüência são apresentados algunstrabalhos relacionados. Na seção 4, é apresentado o sistema de organização da estruturados conteúdos didáticos. A seguir, é abordada a implementação, bem como as telas devisualização de conteúdos do sistema. Por fim, as conclusões e trabalhos futuros serãoapresentados.2. Realidade Virtual e EducaçãoA aplicação de técnicas de RV na educação possibilita a produção de ambientes que podemfacilitar a aprendizagem de alunos, oferecendo uma alternativa complementar paraadquirir o conhecimento oferecido em sala de aula [Nakamoto et al. 2004]. Tambémdeve-se destacar que o uso de RV possibilita que Ambientes Virtuais proporcionem aosusuários uma sensação de imersão pois os mesmos podem navegar e interagir em espaçostridimensionais gerados por processamento computacional [Zottino et al. 2004] tornandoassim a RV relevante no que diz respeito a aplicação na educação.Ainda que a aplicação da Realidade Virtual imersiva torne a interação e envolvimentomais real, soluções não-imersivas são satisfatórias mesmo sem o uso de capacetesou salas de projeção. Oferecer aos usuários sistemas em que os mesmos possam se movimentar,ver, ouvir e manipular objetos torna a aprendizagem mais interessante do queaprender somente em sala de aula.Os alunos têm diferentes maneiras de adquirir conhecimento com maior facilidade,podendo ser por meios visuais, verbais ou auditivos [Braga 2001]. A utilização deambientes computacionais possibilita que sejam exploradas diferentes modos de aprendizagem,oferecendo aos usuários de diversos perfis a utilização 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 abordarconteúdos nas escolas com o professor expondo a disciplina, ainda que muitos professorespossam utilizar de bons métodos e com resultados interessantes até os dias de hoje.A RV induz os estudantes a explorar o ambiente modelado de acordo com o contextodo conteúdo a ser abordado e possibilita que os estudantes possam estar em lugares quedificilmente poderiam estar na vida real.Ambientes Virtuais, através da imersão, interação e envolvimento, tornam-se locaisideais para se buscar vivências múltiplas pois, esse mundo virtual nada mais é do queum trabalho multidisciplinar, desenvolvido por especialistas de diferentes áreas em buscade um objetivo comum. Esses ambientes multidisciplinares permitem aos usuários umaaprendizagem mais ampla e integrada exatamente por ser um ambiente rico de possibilidades[Braga 2001].


3. Trabalhos RelacionadosDiferentes pesquisas sobre este tema são feitos, no entanto, o presente trabalhodestaca dois que tem grande relação com o assunto tratado: o Sistema ConstruiRV[Peruzza and Zuffo 2004] e a aplicação de Humanos Virtuais na Educação[Ieronutti and Chittaro 2005].O Sistema ConstruiRV [Peruzza and Zuffo 2004] utiliza o modelo Construtivistade Educação e foi desenvolvido para a Internet. Trata-se de um ambiente de aprendizagemmultidisciplinar e que está dividido em salas onde diferentes conteúdos são abordadossimultaneamente. O fato de possibilitar a simultaneidade de atividades é graças ao usode Java3D e RMI caracterizando um Ambiente Virtual Distribuído. Neste sistema, oestudante acessa as salas virtuais inicialmente através de uma página em que o mesmoopta por qual ambiente ele deseja explorar. Cada usuário tem sua representação atravésde uma forma humana virtual para ele poder interagir tanto com o ambiente como comoutras pessoas, também, representadas com sua devida forma. Trata-se de um sistemaonde a interação é não-imersiva uma vez que não utiliza dispositivos de interação nãoconvencionais,como luvas, capacetes, etc.O trabalho de aplicação de Humanos Virtuais na Educação[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 razão 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)básicas de modelagem de humanos propostas por [Funge et al. 1999]: geométrica(trata da aparência), cinemática (trata das articulações), física (trata de animações),comportamental (trata de como que o humano virtual responderá às ações do usuário) e,finalmente, cognitiva (trata de como que o conhecimento é adquirido).Foram desenvolvidos três diferentes módulos para o desenvolvimento do sistemapara tratar de cada camada: Módulo Comportamental (Behavioral Engine), Módulo deExecução (Execution Engine) e Módulo de Apresentação (Presentation module). OMódulo Comportamental é referente à camada comportamental, o Módulo de Execuçãotrata das camadas cinemática, física e geométrica já, o Módulo de Apresentação trata daapresentação das mensagens textuais apresentadas ao usuário, ou seja, a camada cognitiva.A relação que os dois trabalhos mencionados tem com o desenvolvido é quetrata-se de um sistema multidisciplinar em que o aluno pode entrar em salas de disciplinasespecíficas. No entanto, o ConstruiRV adota o modelo Construtivista e no presentecaso, é utilizado o modelo Dinâmico. Outro fator diferente é que o sistema de[Peruzza and Zuffo 2004] utiliza a interação não-imersiva de visão em terceira pessoa, ouseja, o usuário pode visualizar o seu avatar que o representa ao explorar o ambiente. Emrelação ao sistema desenvolvido, utiliza a interação não-imersiva de visão em primeirapessoa, o que faz com que os “olhos” do usuário seja a tela.No que diz respeito ao trabalho de [Ieronutti and Chittaro 2005], ambos os sistemasutilizam X3D nas suas implementações mas, o presente trabalho, por utilizar a


visão em primeira pessoa, não aborda a questão de humanos virtuais. Outro fator comumentre os dois trabalhos relacionados e o aqui exposto é que todos são sistemas que podemser acessados pela Internet, possibilitando fácil acesso aos estudantes.4. Organização Estrutural dos Conteúdos DidáticosAusubel [Ausubel 1970] considera primordial tornar a educação individualizada, cadaaluno deve ser tratado num nível adequado às 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 através da variação do tempo, natureza do conteúdo e nível de dificuldadedo conteúdo. Vygotsky [Vygotsky et al. 1988] descreve o desenvolvimento doindivíduo como resultado de um processo sócio-histórico, dando ênfase ao papel da linguageme aprendizagem. A questão central é a aquisição de conhecimentos pela interaçãodo sujeito com o meio.O aplicativo apresentado, possibilita a interação, que se dá através do usuário(sujeito) e o computador (meio), permitindo que este, navegue de acordo com suas potencialidadese 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 eficiênciano processo de ensino-aprendizagem, tornando a construção do conhecimento mais criativae prazerosa. O computador pode transformar-se em um recurso facilitador que, associadoao aspecto lúdico do processo ensino-aprendizagem, passa a ser percebido como umpoderoso recurso pedagógico, com o qual cada aluno constrói sua própria aprendizagem.O sistema de organização da estrutura dos conteúdos didáticos se dá através demódulos, essa escolha está condicionada por sua capacidade para estimular o aluno e porsua pertinência para integrar conteúdos. Segundo Sacristán [Sacristán 2000] o módulofacilita a motivação do aluno, através da coerência entre conteúdos, permite estabelecerrelações entre diversos conteúdos, permite conectar os conteúdos com atividades práticas,habilidades diversas que não costumam depender de conteúdos específicos, favorece aordenação do trabalho em grupos de diferente nível ou ritmo de progresso, marca ciclosde atividade para conteúdos com uma coerência interna, assegura o significado de certosobjetivos e parcelas curriculares.A seleção e estruturação dos conteúdos abordados deu-se através de pesquisasrealizadas por acadêmicos de cada área específica, considerando a área cognitivista ea teoria de Piaget sobre a construção do conhecimento. A área cognitivista abordaquestões sobre a memória de trabalho, atenção, percepção, representação de conhecimento,raciocínio, criatividade e resolução de problemas. A teoria construtivista de Piaget,segundo Becker [Becker 1994], define que ocorre a construção do conhecimentoquando acontecem ações físicas ou mentais sobre objetos, provocando o desequilíbrio,resultam em assimilação (processo cognitivo que consiste na incorporação de elementosdo meio externo a um esquema ou estrutura do sujeito, assim, ampliando seus esquemas)ou, acomodação (modificação de um esquema ou estrutura em função das particularidadesdo objeto a ser assimilado) e assimilação dessas ações e, assim, em construção deesquemas ou conhecimento.Como fontes para a seleção e estruturação dos conteúdos didáticos de 5 a a 8 aséries do Ensino Fundamental, utilizou-se os PCNs, Parâmetros Curriculares Nacionais- Terceiro e Quarto Ciclos e livros didáticos conceituados das disciplinas de Ciências


Naturais, Geografia, História, Língua Portuguesa e Matemática. Os PCNs constituemuma base nacional comum nos currículos e servem de eixo norteador na revisão e/ouelaboração da proposta curricular das escolas [de Educação Básica ].5. ImplementaçãoA implementação do ambiente, está dividida em basicamente dois módulos: 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 visão geral das mesmas.O outro módulo é formado pelas estruturas particulares de cada disciplina, em forma deplataforma, onde os usuários navegam e visualizam os conteúdos de forma resumida, utilizandoum 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 principalmentepara a inserção das propriedades essenciais do padrão X3D e VRML. Dentreas propriedades pode-se destacar a iluminação, a texturização, os aspectos de navegação(altura e velocidade de locomoção pelo ambiente), a detecção de colisão, os pontos devisualização no ambiente e a inserção de alguns nós específicos dos padrões X3D eVRML. Um exemplo dedos padrões mencionados é o nó FOG, responsável peloefeito de neblina nas estruturas. Esse, foi utilizado também para inserção de sensores noambiente e principalmente para modelagem das animações do mesmo.O editor VrmlPad, da empresa Parallel Graphics [(a 3D VRML company) ], foiutilizado para a inserção e configuração do protótipo, ou seja, um nó do tipo PROTOresponsável por abrir o navegador dentro do ambiente, disponível em [v.2 ].A utilização de editores visuais (gráficos) é relevante devido ao fato de proporcionaruma maior agilidade na modelagem dos ambientes. O processo de modelagemvisual, se comparado a uma modelagem com um editor texto, é muito mais intuitivo edinâmico, dispensando um grande número de testes (“compilações”), a fim de verificara posição correta dos objetos no espaço tridimensional. Isso comprova uma tendênciaque a própria WEB 3D indica que, praticamente todas as modelagens 3D serão, em umfuturo bem próximo, feitas através de editores visuais, deixando a parte de codificaçãoda linguagem a cargo desses softwares, permitindo aos modeladores mais liberdade paraexercitar a criatividade [Resources b].A seguir será mostrada uma descrição mais detalhada de cada um dos módulos.5.1. Módulo PrincipalAs disciplinas foram agrupadas em stands, citado na seção anterior. Cada stand possuium micro-ambiente respectivo para cada disciplina, Matemática, Física, Português,Geografia, História, Biologia e Química, como mostra a Figura 1. Cada um dos microambientesfoi modelado tentando representar alguma cena ou objetos que identifiquemcada uma das disciplinas por suas particularidades, ou seja, o stand de Biologia, comanimais e plantas, Matemática com figuras geométricas, 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 váriossites especializados em modelos 3D e Computação Gráfica, como o site [Rocky3d ]. Os


Figura 1. Ambiente principal - agrupamento das disciplinas em standsFigura 2. Particularidades das disciplinasmodelos e a estrutura principal (paredes) em X3D, foram desenvolvidos utilizando o editorVizx3D, que também é responsável pela conversão 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 nó de agrupamento chamado anchor que serve para agrupar objetos e fornecer apropriedade de hiperlink para os mesmos. Assim, em qualquer lugar dentro do ambienteque o usuário clicar, abrirá 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 não precisam de validação para estar em conformidade com o padrão, como oX3D, o que torna a abertura dos arquivos mais rápida, principalmente por serem váriosobjetos dentro de cada ambiente, e (ii) com o formato compactado, os arquivos ficammenores, em torno de 10%.Dentro de cada stand foi colocado um nó Inline, “chamando” os micro-ambientesde cada disciplina, esse nó 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 aglomeração de código em um únicoarquivo [Resources a].


5.2. Módulo SecundárioA modelagem das estruturas dos conteúdos de cada disciplina foi feita em forma deplataformas no formato X3D, seguindo a lógica da classificação dos mesmos, ou seja,respeitando a hierarquia interna de cada disciplina. Cada conteúdo está representado poruma plataforma que tem uma estrutura em forma de quadro negro, modelado em VRML,que contém um nó do tipo sensor, responsável pela chamada do protótipo (PROTO). AFigura 3 mostra um exemplo de quadro negro com um dos conteúdos da disciplina dematemática. Esse protótipo, por sua vez, tem a capacidade de abrir uma extensão do IEdentro do ambiente 3D permitindo a visualização dos conteúdos no mesmo. Dentro doambiente apenas é configurado a chamada externa a esse protótipo e suas propriedadesbásicas, como URL, dimensão e posição do navegador na cena.Figura 3. Exemplo de quadro negro com explicação de um dos conteúdos dematemáticaA escolha por se usar o VRML em conjunto com o X3D se deu pelas seguintesrazões: (i) o protótipo usado para abrir o navegador no ambiente é projetado para o formatoVRML, ou seja, não é preciso reescrever o código para adaptar ao novo padrão e(ii) para evitar o excesso de conteúdo para a validação do padrão X3D, agilizando a aberturado ambiente. Outra razão, (iii) para mostrar que os dois padrões são 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 funções para facilitara navegação do usuário. Entre as funções, pode-se destacar o mapa de localizaçãopara cada disciplina que, em diversos pontos do ambiente, em forma de painéis, auxiliamo usuário a localizar-se no ambiente. A Figura 4 ilustra o mapa de localização, no caso,da disciplina de Física.Entre os objetos modelados, pode-se destacar dois botões, um para o usuário podervoltar ao módulo principal, possibilitando a escolha de uma outra disciplina e, um segundobotão com função de fechar o navegador interno do ambiente. Programou-se esseúltimo botão porque cada quadro negro ativa um novo navegador e, consequentemente,cada navegador aberto precisa de um dispositivo que o feche. Sem isso, o usuário deveriamemorizar onde ele abriu cada navegador para poder fechar e também acarretaria emmais linhas de código para modelar a estrutura necessária para essa função. A Figura 4também expõe tais funcionalidades.


Figura 4. Mapa de localização em forma de painel da disciplina de Física e Funcionalidades,mapa de localização e botões de navegaçãoUma vez que os usuários tem a possibilidade de navegar entre micro-ambientespara explorar os conteúdos programáticos, foram implementados caminhos que seassemelham a corredores em 3D. É através desses que os alunos podem ter uma imersãono sistema e interação pois podem escolher qual dos corredores estes usuários desejampercorrer. A Figura 5 ilustra os corredores em 3D.Figura 5. Corredores em 3DOs conteúdos de cada disciplina, visualizados neste módulo, estão em arquivos noformato XML, que servem como base de dados para o ambiente. Como esses arquivosnão são legíveis, ou melhor, estão sem uma formatação que facilite a leitura do mesmopelo usuário, optou-se em utilizar uma solução simples, uma folha de estilo XSL para formatare transformar as informações no padrão HTML [Kay 2002]. Para a transformaçãoe visualização dos conteúdos através do navegador interno do ambiente, foi utilizado umscript Java que carrega o arquivo XML na memória utilizando o parser XMLDOM. Esseparser faz a formatação do XML em HTML utilizando a folha de estilo XSL, tambémcarregada na memória, e depois reescreve para o usuário somente o conteúdo em um siteHTML. Essa conversão do XML para HTML ocorre inteiramente no usuário (cliente)evitando assim, excessivo tráfego de informações pela internet.


6. Conclusões e Trabalhos FuturosAtravés do desenvolvimento do presente trabalho e estudo de trabalhos relacionados,verifica-se que a possibilidade de utilização da Realidade Virtual na Educação. Os principaisaspectos da RV (imersão, interação e envolvimento) podem ser positivos e expõemalternativas que fogem do cotidiano escolar, motivando os estudantes a adquirir conhecimento,não só dentro da sala de aula, mas em ambientes virtuais. No presente caso,devido a forma de interação dar-se em primeira pessoa, buscou-se uma maior sensação deimersão no ambiente.A organização estrutural dos conteúdos didáticos em módulos motiva o usuário,através da coerência entre os assuntos, a estabelecer relações entre diversos conteúdos.Assim, permitindo que o estudante aborde os conteúdos, do mais simples e, no decorrerda navegação 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 importância do desenvolvimento de sistemas utilizandoX3D, associado com o VRML.A continuação do desenvolvimento do presente sistema, promovendo um ambientemulti-usuário, como no trabalho ConstruiRV [Peruzza and Zuffo 2004] é um possíveltrabalho futuro. Tornando assim, a interação com o sistema, melhor e mais interessante aoponto de vista do estudante, além de possibilitar a idéia do Peer-tutoring. A idéia básicadesse, consiste em fazer com que alunos com conhecimentos mais avançados ensinemoutros com menor domínio sobre determinado conteúdo.Outra alternativa de continuidade, como trabalho futuro, seria utilizar a idéia dotrabalho de [Ieronutti and Chittaro 2005] e desenvolver humanos virtuais, mais precisamente,professores virtuais que poderiam explicar aos alunos o conteúdo 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 verificação da validade do ambiente, pretende-se aplicá-lo em escolas, objetivandodeterminar se há necessidade de alterações para melhorias no sistema e confirmálocomo uma possibilidade alternativa de auxiliar estudantes a buscar conteúdos didáticosde uma maneira interativa através do uso do computador.Finalmente, para validação relativa a utilização do ambiente, é possível arealização de um estudo comportamental de usuários frente ao sistema, com o objetivode verificar se os alunos realmente tiram proveito dos aspectos da RV e se é adequada aorganização estrutural dos conteúdos didáticos.Referências(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 é construtivismo? In FDE, editor, SIGGRAPH99: 26th ConferenceOn Computer Graphics, volume 20 of Idéias, São Paulo.


Braga, M. (2001). Realidade virtual e educação. In Revista de Biologia e Ciências daTerra, volume 1.de Educação Básica, S. I. S. Parâmetros curriculares nacionais.Funge, J., Tu, X., and Terzopoulos, D. (1999). Cognitive modeling: Knowledge, reasoning,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 Referência 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., Guimarães, M., Cardoso, A., Mendes, E., and Takahaschi, E. (2004). Construindoum laboratório virtual de eletrodinâmica baseado no paradigma de mapas conceituais.In Proceedings of VII Symposium on Virtual Reality in the Schools, pages231–242, São 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). Análise da contribuição da realidade virtual para aeducação através do sistema contruirv. In Proceedings of VII Symposium on VirtualReality in the Schools, pages 265–276, São Paulo.Pinho, M. (1996). Realidade virtual como ferramenta de informática na educação. InAnais do Simpósio Brasileiro de Informática na Educação, 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.Sacristán, J. G. (2000). O Currículo: Uma Reflexão sobre a Prática. 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. Ícone/EDUSP, São Paulo.Zottino, R., Calonego, N., Abackerli, A., Kirner, T., and Kirner, C. (2004). Ambientevirtual distribuído web para máquinas de medir coordenadas utilizando shout3d e rmi.In Proceedings of VII Symposium on Virtual Reality in the Schools, pages 255–264,São Paulo.


Zuchi, I. (2000). O desenvolvimento de um protótipo de sistema especialista baseado emtécnicas de rpg para o ensino de matemática. Master’s thesis, Universidade Federal deSanta Catarina.


Uma Experiência de Ensino-Aprendizagem em umadisciplina de ProgramaçãoMauricio Capobianco Lopes 11 Departamento de Sistemas e ComputaçãoUniversidade Regional de Blumenau (FURB) – Campus IVRua Braz Wanka, 238 - 89035-160 - Blumenau– SC – BrazilResumo: Este artigo descreve uma experiência com um método de ensinoaprendizagemem uma disciplina de programação enfatizando os processos deavaliação combinados com este método. A ênfase da experiência aquiapresentada está na diversificação destes métodos e dos instrumentos ecritérios de avaliação visando voltá-los efetivamente para a aprendizagem dosestudantes, além de tentar extrapolar elementos estritamente técnicosconsiderados no ensino de programação.1 IntroduçãoA avaliação da aprendizagem é um processo em permanente discussão entrepesquisadores de Educação e de todas as áreas de conhecimento, os quais estão sempreem busca de seu formato ideal. Entretanto, este é um objetivo difícil de ser alcançadouma 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 muitosquestionamentos.Entre os maiores desafios da avaliação da aprendizagem estão a definição dasestratégias mais coerentes para que o aluno apreenda o conhecimento desejado e dosobjetivos do processo avaliativo. Estes componentes são fundamentais para facilitar aescolha dos instrumentos e critérios mais adequados para avaliação. Além disso, aprópria natureza dinâmica do processo educacional faz com que os avaliadores sempredevem reconsiderar e reavaliar os seus processos de avaliação.A avaliação não pode estar dissociada da metodologia de ensino-aprendizagemempregada pelo professor. Anastasiou e Alves (2004, p.79-98), por exemplo,apresentam diversas “estratégias de ensinagem”, descrevendo cada estratégia, sugerindodinâmicas das atividades e a forma e os critérios de avaliação e buscando fornecerferramentas para diversificar a avaliação.Silva (2006, p.15) também destaca que “a diversidade de instrumentos avaliativosprecisa estar inserida em uma sistemática, atender uma metodologia própria da teoria eda prática da avaliação educacional e adequá-la à natureza do objeto avaliado (...)”, ouseja, os instrumentos de avaliação devem ser diversificados para permitir melhorar acompreensão sobre o sujeito que está sendo avaliado.Particularmente na área de conhecimento de programação de computadores muitassão as discussões sobre as metodologias dos processos de ensinar e aprender e dosprocessos avaliativos mais adequados para os estudantes aprenderem a programarcomputadores. Eventos como o Workshop de Ensino de Informática (WEI) ou o


Simpósio Brasileiro de Informática na Educação (SBIE) apresentam constantementerelatos de experiências nesta linha, a se destacar o trabalho de Santos e Costa (2006) quefaz um interessante apanhado sobre publicações realizadas sobre o assunto. Também otrabalho de Fernandes (2002) que apresenta a unificação de quatro linhas pedagógicasbuscando uma formação mais completa de um estudante de programação. Já Pimentel,França e Omar (2003) apresentam importantes considerações sobre os problemasenfrentados nos processo de ensino-aprendizagem de programação e propõem umaferramenta tutorial inteligente para auxiliar o professor e coordenação noacompanhamento dos estudantes.No entanto, em pesquisas informais com colegas de trabalho de diversasinstituições, percebe-se que, via de regra, o processo de avaliação das disciplinas deprogramação das IES continua centrado na avaliação somativa, ou seja, o professorquantifica o desempenho dos seus alunos baseados nos objetivos definidos em seu planode ensino-aprendizagem, fazendo esta verificação através de provas práticas conceituaise de implementação de trabalhos práticos em uma linguagem de programação, onde oaluno deve demonstrar seu conhecimento em programação. Também o critério deavaliação normalmente é centrado na resposta a uma única pergunta: o aluno aprendeu aprogramar? A partir daí para o processo avaliativo, constrói-se uma estrutura de controleem nível de seleção muito simplificada (e, inclusive, já orientada a objetos!): sealuno.aprendeuProgramar() então sistema.escreva (“Aprovado”) senão sistema.escreva(“Reprovado”). fim seMas 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ívelfazer uma avaliação formativa, apresentada por Hadji (2001, p.20) como a forma defavorecer 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íticano exame de dados, a capacidade da articulação de teoria e prática, as habilidades deorganização das respostas com logicidade, clareza e coerência, os estilos de fala eescrita, o emprego adequado de princípios e normas formam um conjunto deaprendizagens ao qual se pode atribuir a distinção acadêmica”.Desta forma, pretende-se demonstrar neste artigo uma experiência de aplicação dediversas estratégias de ensino-aprendizagem em uma disciplina de programação, comênfase na diversificação dos processos de avaliação, transcendendo apenas um aspectoda formação de um estudante de nível superior em uma disciplina de programação decomputadores, qual seja, a aprendizagem de programação.2 O ContextoA disciplina de que trata o presente objeto de estudo é denominada de Tópicos emProgramação I e ocorre na quarta fase do curso, sendo que nas fases anteriores osestudantes já tiveram conteúdos relacionados a algoritmos e estruturas de dados e àslinguagens C e Java. A disciplina tem por objetivo abordar alguns aspectos e formas deconstrução de programas não abordadas em disciplinas anteriores, tais como: interfacegráfica, programação baseada em eventos, programação concorrente e programaçãodistribuída.


Antes desta nova abordagem, a disciplina enfatizava a ferramenta Delphi, a qual foisubstituída em função do colegiado do curso optar por retirar o ensino da linguagemPascal do currículo, mantendo apenas C e Java. Na época, o processo avaliativo dadisciplina 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 (realizadaindividualmente), o aluno tinha 3 horas/aula para resolver um determinado problemadado em um enunciado. Já no trabalho final (realizado em equipe), tinha que serdesenvolvido um sistema com uma certa complexidade utilizando o ambiente. Por tratarsede tema livre, apareciam os mais variados tipos de implementação, tais como,softwares comerciais, jogos, chats, editores de texto, entre outros, dificultando oestabelecimento de critérios de avaliação que contemplassem os diferentes tipos desistema.Também outros questionamentos eram levantados à época: será que a prova é uminstrumento que mede a real capacidade de um aluno em resolver um problema deprogramação? Será que a ênfase em uma disciplina de programação não deve ser ostrabalhos de implementação? Em uma disciplina de programação deve-se avaliar apenasa habilidade técnica do aluno em resolver um determinado problema?Junto com estas perguntas, outras situações também eram incômodas, tais como, otempo restrito que o estudante tinha para fazer uma prova de programação, fazendo comque a complexidade do problema apresentado pelo professor tivesse que ser reduzida e adificuldade em controlar a autoria dos trabalhos de implementação, sobretudo em épocasde Internet, minimizando-se desta forma a importância do trabalho prático comoinstrumento de avaliação.Assim, a partir do segundo semestre de 2004, quando a disciplina passou a abordaruma nova linguagem de programação, decidiu-se também mudar o seu enfoque passandoa abordar os conteúdos desejados através da implementação de jogos (deentretenimento) na linguagem Java e revendo-se os métodos de ensino-aprendizagem eas 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 UtilizadasAs três principais estratégias de ensino-aprendizagem utilizadas atualmente nadisciplina incluem:a) aulas expositivas dialogadas;b) estudo de textos;c) soluções de problemas.Combinadas com diferentes instrumentos de avaliação estas estratégias permitemampliar 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ãosobre os conceitos abordados ao longo da disciplina. Além disso, o professor constróijunto com os alunos soluções computacionais sobre os problemas abordados, visandoclarificá-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 asimplementações realizadas, articulando teoria e prática. Neste caso, não são aplicadosinstrumentos específicos de avaliação para verificar se os alunos efetivamenteapreenderam os conteúdos abordados, pois não se pretende que o sujeito saibareproduzir conceitos, mas sim o aplique de fato, o que será verificado através detrabalhos de implementação.O estudo de texto também tem por objetivo apresentar conceitos abordados nadisciplina e é combinado com outras estratégias, visando explorar o texto lido, de modoque se desafie o estudante a fazer de fato uma análise sobre o tema proposto. Asestratégias combinadas com o estudo de texto e que são efetivamente utilizadas comoinstrumentos de avaliação são o debate e a resenha.No debate os estudantes lêem um texto em sala de aula tratando dos aspectosteóricos e metodológicos aplicados ao desenvolvimento de jogos. Em seguida, cadaaluno responde a um conjunto de 10 questões propostas pelo professor, para o qual eletem três opções de resposta - concordo totalmente, concordo em parte e discordototalmente – a qual deve ser devidamente justificada. Depois de cada aluno produzir seudocumento individual, os estudantes são reunidos em grupos de 4 a 6 onde devemdiscutir suas respostas e produzir uma única resposta do grupo para as mesmas 10questões. Este instrumento, além de permitir explorar questões conceituais apresentadasno texto, faz com que o aluno faça uma reflexão e emita sua opinião sobre os conceitosabordados 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 oprofessor apresentam suas considerações sobre os temas abordados. Assim, são trêsmomentos diferentes de reflexão sobre o mesmo texto: individual, no pequeno grupo eno 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 realizadaem sala de aula, o professor pode avaliar o estudante sob diversos aspectos, tais como, odomínio conceitual, a qualidade e profundidade de sua argumentação, a participação e ocomportamento do aluno no grupo de discussão, além da qualidade de sua produçãotextual, alcançando o objetivo de se transcender a avaliação apenas sob o aspecto doaprendizado técnico de programação.Especificamente em uma disciplina de programação, existem diversos temasadequados para esta discussão, tais como, métodos de resolução de problemas e práticasde programação, que normalmente suscitam discussões acaloradas entre os estudantes.Na resenha, cada estudante individualmente deve ler e fazer uma resenha crítica deno máximo 2 folhas sobre um artigo relacionado ao contexto da disciplina. A resenhapode ser baseada em um texto indicado pelo professor ou pode ser de um texto de livreescolha do próprio estudante. Neste segundo caso, o professor tem mais trabalho, poistem que ler os textos escolhidos por cada estudante, mas, por outro lado, diversifica maisseu conteúdo bibliográfico, além de perceber os temas de interesse e de relevância paraos estudantes.Com este instrumento, o professor pode avaliar, por exemplo, a capacidade deleitura 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 desconsideradasem um processo avaliativo em disciplinas de programação, onde normalmente se avalia acapacidade do aluno em formular soluções algorítmicas ou em uma linguagem deprogramação para um determinado problema.Outra estratégia de ensino-aprendizagem utilizada na disciplina é a concretizaçãodos objetos de estudo através de soluções de problemas., sendo aplicada do seguintemodo: três jogos desenvolvidos em conjunto entre professor e estudantes, denominadosde trabalhos de unidade e um jogo desenvolvido exclusivamente pelos estudantesdenominado de trabalho final. Estes trabalhos têm o objetivo de aplicar osconhecimentos discutidos e construídos através das outras estratégias já apresentadas.Os trabalhos de unidade são dimensionados para que se possa contemplar oselementos fundamentais do programa da disciplina através de soluções mais amplas ecomplexas, permitindo que se trabalhe com poucos exercícios, mas oportunizando aosestudantes 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 nojogo proposto. Alguns destes requisitos são implementados em sala de aula com aparticipação e orientação do professor, uma vez que muitos deles envolvem conceitos outécnicas não vistas anteriormente pelos estudantes, sendo que outros são implementadosem trabalhos extra-classe. Nem todos os requisitos têm sua base conceitual discutida emsala de aula, de modo a fomentar a autonomia do estudante para a pesquisa e estudo denovos temas.Por serem trabalhos feitos de forma gradativa, o professor pode ir fazendo o seuacompanhamento e fornecendo constantes feedbacks quanto às soluções implementadas,cumprindo um dos principais pilares do processo avaliativo que é permitir ao estudanterever e reforçar o seu aprendizado e ao professor a oportunidade de revisar e replanejarseus 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 acuradasobre 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 naimplementação completa de um jogo de entretenimento na linguagem Java. Nestetrabalho os estudantes devem se impor um desafio sendo este o instrumento central deavaliação na disciplina. A aplicação deste instrumento envolve quatro momentosdiferentes: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 desejamimplementar. 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ãoprecisa 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 serdesenvolvido (nem tão simples – que envolva uma pequena base conceitual ede implementação, nem tão complexo – que não possa ser implementado emfunção do tempo disponível). Esta proposta deve ser entregue na forma


textual, seguindo um modelo proposto pelo professor de modo que seestabeleç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 aavaliaçã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 eprodução de um texto. Além do texto, a equipe também faz uma apresentaçãooral da proposta para os demais colegas. Com isto, permite-se aos demaisestudantes da turma, opinar e dar sugestões sobre o trabalho dos colegas,enriquecendo a proposta e ampliando o conjunto de idéias para outrostrabalhos. Outro objetivo da apresentação oral é a exposição do estudante auma platéia, com caráter formal, onde pode-se observar, avaliar e orientarsobre questões como postura, oratória e articulação, possibilitando ummomento para ajudá-lo a transpor uma barreira que é muito comum para osestudantes de computação e informática: a apresentação pública. Ressalta-seque este contrato é diferenciado de acordo com o que cada grupo estabelececomo desafio para si próprio, ou seja, prevalece a capacidade e a vontade decada grupo a desenvolver um trabalho dentro de seus próprios limites. Cabeao professor apenas provocar o desafio.b) apresentação prévia: 45 dias após o contrato ser negociado, os estudantesdevem apresentar alguma implementação já concluída. Coloca-se como metaque nesta época, pelo menos metade do trabalho já esteja concluído. É omomento em que o professor dedica um maior tempo a cada equipe,observando se as soluções encaminhadas estão adequadas, tirando dúvidas eapontando 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 umaapresentação do sistema implementado ao professor. Neste momento oprofessor não tira mais dúvidas. Ele observa se todos os requisitos constantesno contrato foram atendidos, avalia a jogabilidade do jogo, se o softwarepossui erros, a arquitetura utilizada na implementação e a clareza e concisãodo código fonte implementado. Também olhando o código fonte, o professorquestiona os estudantes, sobretudo no uso de técnicas e soluções nãorealizadas ou discutidas em sala de aula. Esta é uma estratégia importante paraverificar se os estudantes de fato são os autores do software apresentado.Outros aspecto fundamental neste processo é a oportunidade que o estudantetem de se auto-avaliar. Assim, cada um se manifesta sobre sua participação notrabalho 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ópriaequipe, permitindo identificar os autores que mais se dedicaram ao trabalho eproporcionando, inclusive, a atribuição de notas diferentes para os integrantesde cada equipe;d) apresentação pública: na última aula do semestre letivo, cada equipe faz aapresentação pública do seu trabalho para todos os colegas da turma, que oavaliam. O professor entrega um formulário para cada estudante com os


critérios que devem ser observados na avaliação. Os estudantes não atribuemnotas aos trabalhos dos colegas, mas sim fazem um rankeamento na ordem desua preferência. Este é um dos momentos mais interessantes do processo deavaliação da disciplina, pois novamente expõe os estudantes a umaapresentaçã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 deavaliadores tornando-os efetivamente co-autores no processo avaliativo dadisciplina. É muito interessante observar este processo, pois muitas vezes, aofazer a avaliação do colega, o estudante não se prende apenas aos aspectostécnicos do trabalho apresentado, mas também acaba refletindo suaspreferências pessoais, tanto pelo tipo de jogo, quanto pela empatia com aequipe que está apresentando. Assim, nas experiências vivenciadas até omomento com este tipo de avaliação, mesmo um trabalho tecnicamente muitosuperior aos outros, dificilmente obtém unanimidade no rankeamento peloscolegas.4 Os Resultados AlcançadosA experiência adotada até o presente momento com o método aqui apresentadotem demonstrado ganhos de qualidade em diversos aspectos do processo ensinoaprendizagem,comparando-se com o método adotado anteriormente:a) quanto à formação: quando são instados e motivados a construírem seupróprio aprendizado, em desafios complexos, mas factíveis, os estudantes têmdemonstrado grande empenho, levando a uma formação técnica maisduradoura, à medida que é necessário construir algo e, já se sabe, que amelhor 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 deavaliação e auto-avaliação, trabalho em equipe, entre outros, para umadisciplina que aparentemente é extremamente técnica com um objetivo muitoclaro que é o de avaliar a capacidade do estudante em formular programas decomputador. 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 provasde conhecimento através de instrumentos específicos já diminui em muito aanimosidade nesta relação, resultando em cobranças menos estressantes tantopara o professor quanto para os estudantes, permitindo, portanto, uma relaçãomenos tensa e mais aberta, à medida que ois estudantes também participammais do processo;c) quanto à aprendizagem: a participação dos estudantes nas aulas foi ampliadasobretudo pela utilização de metodologias mais participativas e deinstrumentos de avaliação de mais longo prazo, ou seja, que não são aplicadosem um único momento. Isto tem tornado, de fato, os estudantes como sujeitosativos do processo ensino-aprendizagem;d) quanto ao comprometimento: ao avaliarem a si e aos colegas os estudantessã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 autojulgamentodemonstra ser uma “cobrança” muito mais efetiva para o estudantee aumenta o seu comprometimento no sentido de provar a si mesmo suacapacidade e empenho;e) quanto ao conhecimento do professor sobre o sujeito aprendente: uma dasmaiores dificuldades do ensino é lidar com classes numerosas e com sujeitosem diferentes níveis de conhecimento e interesse. Ao possibilitar que oestudante defina a complexidade dos desafios que tem para resolver, oprofessor conhece melhor as diferenças técnicas e motivacionais entre seusdiferentes alunos e pode aplicar instrumentos e estratégias diferenciadas paracada um deles.Obviamente existem ainda desafios e dificuldades a serem superados, sobretudoquando o estudante e a instituição de ensino não conseguem lidar com determinadasmudanças naquilo que vem sendo feito, ou que é o tradicional e exigido pelosregulamentos. Algumas destas dificuldades são:a) o estudante e a instituição perceberem que não é necessário a aula tradicionalonde o professor explica e ele passivamente fica sentado em sua carteiraesperando 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 ministradoconteú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 umadisciplina 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” doscolegas na confecção dos trabalhos, sendo que seus efeitos nefastos sãopercebidos apenas no momento da auto-avaliação, sendo esta uma questãoque tem que ser lembrada constantemente pelo professor ao longo dadisciplina. Mesmo assim, alguns alunos ainda chegam “acomodados” ao finaldo semestre letivo;c) a própria avaliação não faz parte da cultura dos estudantes, pois normalmenteele esta ali para ser avaliado e não para avaliar. A auto-avaliação e a avaliaçãopelos pares ainda precisa de um processo de amadurecimento;d) lidar, também na avaliação, com trabalhos em níveis de complexidadediferentes, uma vez que os estudantes com maior conhecimento anteriornormalmente se impõem maiores desafios que os demais, criando diferentesníveis de trabalho. Assim, a avaliação deve estar centrada no alcance dosobjetivos por parte do estudante, independente de seu nível de dificuldade. Oprofessor pode e deve estar ciente disto em sua avaliação, mas os paresdificilmente estarão.5 Considerações finaisNão há dúvida quanto à complexidade inerente aos processos de ensinoaprendizagem,sobretudo em uma sociedade cada vez mais sobrecarregada de tarefas,onde tudo é urgente e onde o tempo é cada vez mais escasso, tanto para estudantesquanto 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ênciaapresentada neste artigo vai neste sentido.Com o trabalho realizado até o momento verificamos que mesmo em disciplinas deprogramação de computadores, onde historicamente tem se privilegiado o conhecimentotécnico e a avaliação individual, é possível e necessária a diversificação dostodos deensinar e aprender e, sobretudo, dos processos avaliativos, privilegiando a qualidadenecessária de formação técnica para o estudante. Não se espera com isto ter ouapresentar uma fórmula de sucesso completa e acabada, mas sim, enriquecer o debate emtorno da melhoria da qualidade destes processos nas disciplinas de programação, quesem dúvida, são fundamentais na formação dos sujeitos que atuarão em Computação eInformática, além de ampliar o olhar sobre a sala de aula de modo a construir umprocesso de avaliação que passe a ter significado e ser, de fato, formativo.Cabe ressaltar, finalmente, a importância fundamental dos processos de formaçãodocente neste contexto. A participação do autor deste artigo nos programas de formaçãodocente 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çãotécnica predominante em professores da área de Computação e Informática normalmentefaz com que eles repliquem modelos através dos quais foram educados. Assim, osprocessos de formação, além de permitirem o aprofundamento de discussões didáticopedagógicase a troca de experiências com outros docentes, alertam o professor sobre anecessidade de estar atento e em constante reflexão sobre suas práticas educativas, deforma a considerar e analisar outras e novas possibilidades nos processos de ensinoaprendizagem,visando, sobretudo a motivação e o comprometimento, tanto seu, quantodo sujeito aprendente.6 ReferênciasANASTASIOU, Léa das Graças Camargos; Ensinar, aprender, apreender e processos deensinagem. In: ANASTASIOU, Léa das Graças Camargos; ALVES, Leonir Pessate.(org.). Processos de ensinagem na universidade: pressupostos para as estratégias detrabalho em aula. 3. ed. Joinville : UNIVILLE, 2004. 144 p, il.ANASTASOU, Léa das Graças Camargos; ALVES, Leonir Pessate. Processos deensinagem 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 eprogramação: uma abordagem concreta, construtivista, linguística e histórica. In: XWorkshop sobre Educação em Computação, 2002, Florianópolis - SC. XXIICongresso 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´évaluationdémystifiée.


PIMENTEL, Edson Pinheiro; FRANÇA, Vilma Fernandes; OMAR, Nizam. A caminhode um ambiente de avaliação e acompanhamento contínuo da aprendizagem emprogramação de computadores. In: III Workshop de Informática na EducaçãoComputação do Estado de Minas Gerais, 2003, Poços de Caldas - MG. III Workshopde 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 noensino 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 trabalhoem aula. 3. ed. Joinville : UNIVILLE, 2004. 144 p, il.SANTOS, Rodrigo Pereira; COSTA, Heitor Augustus Xavier. Análise de metodologiase ambientes de ensino para algoritmos, estruturas de dados e programação aosiniciantes 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: emdiferentes á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 FioCarlos Henrique Drumm e Paulo Roberto Ferreira Jr.Instituto de Ciências Exatas e Tecnológicas - Centro Universitário FeevaleRS 239, 2755 - Novo Hamburgo – RS – CEP 93352-000{carlos.drumm, paulo.ferreira.jr}@gmail.comResumo. Este trabalho aborda a utilização dos processos cinergéticos,verificados em colônias de insetos sociais, aplicados ao gerenciamento econtrole de Redes de Sensores Sem Fio utilizadas no sensoriamento de regiõesde difícil acesso. Mais especificamente, é verificada a aplicabilidade destaabordagem frente ao controle da densidade mais adequada de uma rede desensores para cobrir eficazmente uma área desejada, com a menor utilizaçãopossí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 hocdifere 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 infraestrutura,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 deder, 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 SociaisOs 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 jque 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. ExperimentosO 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 m 2 (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 dassimulaçõ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.000m 2 );• alcance dos sensores é 15 metros, o que fornece uma cobertura de 706,86m 2(metros quadrados), por sensor;• cada conjunto de dados tem 600 sensores, distribuídos aleatoriamente pela áreaacima descrita, cujos quais permitiriam sensoriar uma área de aproximadamente424.116m 2 , 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 PlanaA 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.d=2( x"−x')+ ( y"− y')2onde: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 . Estadiferençaéaáreadacordabc, 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 SensoresSeqüê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 =(ÁreadoSetor–ÁreadoTriangulo)*24.2 Rede Hierárquica GerenciadaA 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çãodaredesemgerencia-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 SociaisA 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. ResultadosOs 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 PlanaA 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Área (%)120,00%100,00%80,00%60,00%40,00%20,00%0,00%8152229364350576471788592991Periodos (Dias)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 ControleNa 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 Setor120,00%100,00%80,00%60,00%40,00%20,00%0,00%121416181101121141161181201221241261281Area (%)Periodos (Dias)Figura3-ÁreadeCoberturaaolongodoTempodeVidadaRSSF-GH,Sem Queda de Setor de Cobertura.5.3 Rede Hierárquica Gerenciada com Queda de Um Nó de ControleComo 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 SetorArea (%)120,00%100,00%80,00%60,00%40,00%20,00%0,00%12039587796115134153172191210229248267286Periodos (Dias)Figura4-ÁreadeCoberturaaolongodoTempodeVidadaRSSF-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 SociaisSendo 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.2Area (%)120,00%100,00%80,00%60,00%40,00%20,00%0,00%123456789111133155177199221243265287309Periodos (Dias)(a) Limiar de Resposta do Individuo de 0.2.Cobertura Média para de 0.5100,00%80,00%60,00%40,00%20,00%0,00%1265176101126Area (%)151176201226251276301326Periodos (Dias)(b) Limiar de Resposta do Individuo de 0.5.Cobertura Média para de 0.8Area (%)80,00%60,00%40,00%20,00%0,00%1265176101126151176201226251276301326351Periodos (Dias)(c) Limiar de Resposta do Individuo de 0.8.Figura5-ÁreadeCoberturaaolongodoTempodeVidadaRSSF-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 Coberturas120,00%100,00%80,00%60,00%40,00%20,00%0,00%11937557391109127145163181199217235253271289307325Área (%)Período (Dias)Rede PlanaRede Hierárquica Sem QuedaRede Hierárquica Com Queda Rede Distribuída 0.2Rede Distribuída 0.5Figura 6 – Comparativo sobreposto dos resultados obtidosConcomitantemente 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 dostodos 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çõesRede Plana Rede Hierárquica Rede DistribuídaSem QuedaCom Queda θ 0,2 θ 0,5 θ 0,8MédiadeCoberturaentrePeríodo1a90100% 100% 93,84% 95,94% 82,33% 73,35%Tempo Excedente (Dias) 12 203 203 224 252 270MédiadeCoberturadoTempoExcedente67,05% 13,69% 7,76% 23,26% 29,51% 32,43%7. ConclusõesNeste 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 toartificial 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. 2002RUIZ, 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. 2003THERAULAZ, 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éticosMilton Roberto Heinen 1 e Fernando Santos Osório 11 Universidade do Vale do Rio dos Sinos (UNISINOS)Computação Aplicada - PIPCACEP 93022-000 - São Leopoldo - RS - Brasilmiheinen@gmail.com, fosorio@unisinos.brResumo. 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 utilizaçãode 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 AlgoritmosGené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 modelosde 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 pesquisadores,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 desarmamentode 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 ambientespossuem 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 diversosparâ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 dependentesda 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écnicasde 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éticosuma 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 seguinteforma: 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 espaçode 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 pesquisasque 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 razoavelmentesatisfatório. Bongard [Bongard and Pfeifer 2002] evoluiu os parâmetros de umaRede Neural Artificial dinâmica utilizada para controlar diversos tipos de robôs simulados.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-Mechs 1 . Jacob [Jacob et al. 2005] utilizou Aprendizado por Reforço para o controle de1 DynaMechs – 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 parâmetrosde 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éticosOs 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 avaliaçã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, atravésde 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 selecionadaa biblioteca de software GAlib 2 , desenvolvida por Matthew Wall do MIT. A GAlibfoi selecionada por ser uma das mais completas, eficientes conhecidas bibliotecas de softwarepara 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 sobrepostas(overlapping populations) proposto por [De Jong 1975], e foram adotados genomasdo 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ísicaPara 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 de2 GAlib – 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ígidosarticulados 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 articulados,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 estadoé 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 juntaspodem 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:V ij = V r i (α ij − α ij−1 ) (1)onde V ij é 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 r i é 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 em3 ODE – 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 liberdadepor 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 calculadosantecipadamente 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 deslocamentodos endpoints através de alguma função cíclica, como por exemplo uma meiaelipse.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 utilizandoa linguagem de programação C++ e as bibliotecas de software ODE e GAlib,descritas anteriormente. O sistema LegGen recebe como entrada dois arquivos, um descrevendoo formato e as dimensões do robô e o outro descrevendo os parâmetros de simulaçã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,0Os parâmetros crossover, mutation, population size e number of generations sãousados diretamente pela biblioteca GAlib para definir o funcionamento do Algoritmo Gené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 avaliaçãodo 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 = P x 1 − P x 0 (2)onde D é a distância percorrida pelo robô em relação ao eixo x (movimento para frenteem linha reta), P x 0 é a posição inicial e P x 1 é 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]:√ ∑ni=1(x i − x)G =2 + ∑ ni=1 (y i − y) 2 + ∑ ni=1 (z i − z) 2(3)nonde n é o número de amostras coletadas, x i , y i e z i são os dados coletados pelo giroscópiosimulado no instante i, e x x , x y e x z são as médias das leituras realizadas pelo giroscópio,


calculadas através das equações:x =∑ ni=1x i, y =nO fitness F é calculado através da fórmula:∑ ni=1 y in, z =∑ ni=1z in(4)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 melhoressoluçõ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á necessidadede continuar a simulação deste indivíduo até o final do tempo estabelecido.6.1. Robôs ModeladosConforme consta em sua documentação, a biblioteca ODE possui uma complexidadecomputacional de ordem O(n 2 ), 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, elementoscomo 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) Tetra2JFigura 2. Modelos de robôs utilizados nas simulaçõesInicialmente foram modelados e testados diversos tipos de robôs, até que se chegouaos 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:n∑α p = − α i (6)i=1onde α i é o ângulo da junta i e n é o número de juntas em cada perna. Utilizando a Fórmula6, 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 PataRobô 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 frontaisPernas traseirasRobô 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 experimentosforam 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 segmentospor 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 GE Robô Método Passo x S x S x S01 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,07Cada um dos experimentos foi repetido cinco vezes com sementes aleatórias diferentes,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, respectivamente,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 velocidadessem 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 experimentosrealizados 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 experimento.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 EstabilidadeFigura 3. Gráficos de evolução das soluçõesPode-se notar que existe uma certa relação direta entre a velocidade e a instabilidade,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ô Tetra3J 4 e a Figura 4(b) mostra ocaminhar de um robô Hexa2J.(a) Tetra3J(b) Hexa2JFigura 4. Exemplos de caminhar utilizando os robôs Tetra3J e Hexa2J8. 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 superfíciede 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.4 Vá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 irregularese subida de escadas, bem como a construção de um robô físico conforme as especificaçõesde um dos melhores modelos aprendidos, para assim validar o sistema emcondições reais.ReferênciasBatavia, P., Pomerleau, D., and Thorpe, C. (1996). Applying advanced learning algorithmsto 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 fourleggedrobots. 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. CambridgeUniversity Press, Cambridge, UK.Goldberg, D. E. (1989). Genetic Algorithms in Search, Optimization and Machine Learning.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 ComputationalIntelligence (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 physicallybased 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 configuraçãoautomá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 MichiganPress, 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 ComputationalIntelligence 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 InternationalConf. 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, Cambridge,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. Zamberlam1 FEEVALE, PROPTEC, Grupo de Pesquisa em TINovo Hamburgo, RS, Brasil{rodrigo, alexz}@feevale.brResumo. Este artigo relata a investigação e partes da implementaçãorealizadas no projeto AS-MCOE, que tem como objetivo avaliar a utilizaçãode tutores inteligentes no ensino de ecologia, dando continuidade ao trabalhodesenvolvido no ambiente MCOE. O tutor e os agentes dessas propostas estãosendo implementados com a técnica BDI (Belief, Desire and Intention) por meioda linguagem AgentSpeak(L) e do interpretador Jason. Esses agentes estãoinseridos em um jogo, construído através da Golden T Game Engine (GTGE),kit de desenvolvimento em Java para jogos.1. IntroduçãoO projeto AS-MCOE (AgentSpeak(L) MCOE) se caracteriza pela investigação científicados avanços pedagógicos e tecnológicos decorrentes da utilização de técnicas deInteligência Artificial no ensino de crianças, jovens e adultos. O objeto dessa pesquisa sãoos jogos educacionais, os quais destacam-se pela popularidade e inserção na comunidadeinfanto-juvenil, e que até o presente momento não agregam a tutoria artificial comoum diferencial comercial e/ou pedagógico. A finalidade desse projeto é desenvolverum estudo sobre aplicação de uma técnica de IA, intitulada BDI (Believes, Desires andIntentions ou Crenças, Desejos e Intenções), em um jogo educacional e avaliar o processode desenvolvimento e aplicação do mesmo com alunos do ensino fundamental.O tema do jogo, proposto inicialmente por Lúcia Giraffa em [Giraffa 1999], é deecologia e baseia-se na interação entre um personagem, comandado pelo aluno, e a cadeiaalimentar de um lago, composta por personagens artificiais inteligentes. O objetivo émanter o equilíbrio da cadeia por meio de “poderes” ou ferramentas que o personagempossui, e as dificuldades relacionadas ao jogo e/ou ao conteúdo são avaliadas por um TutorArtificial que envia mensagens com dicas e explicações ao aluno.Neste trabalho, a modelagem utilizada por Giraffa, proposta por Móra em[Móra 2000], será substituída pela de [Rao 1996], cuja linguagem, a AgentSpeak(L),foi implementada por [Hübner et al. 2004]. Esses novos recursos viabilizaram areimplementação dos experimentos realizados por Giraffa e a sua posterior avaliação.Além disso, novas recursos foram utilizadas para o desenvolvimento do jogo: a linguagemJava e o engine para jogos GTGE.Finalmente, para uma melhor compreensão do apresentado, este artigo estádividido em 7 seções. A próxima detalha o ambiente MCOE, sua estrutura, seuscomponentes e sua evolução. A seção 3 aborda agentes cognitivos baseados em estadosmentais (BDI), conceitos e o contexto na IA. Na seção 4, é detalhada a linguagemde especificação AgentSpeak(L), bem como o interpretador Jason, ferramentas deoperacionalização da máquina de inferência do comportamento dos agentes no jogo.


A seção 5 apresenta o engine GTGE, responsável pelo o ambiente do jogo, ou seja, ajogabilidade. Na seção 6, é detalhada a arquitetura do jogo com o engine e o interpretadorJason. Finalmente na seção 7, as considerações finais.2. MCOEEste projeto faz parte de um conjunto de pesquisas sobre softwares educacionaisinteligentes realizadas nos últimos dez anos. O eixo principal de todas elas é 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-lógico, que foi um trabalho deconclusão de curso de graduação, construído com ToolBook [ASYMETRIX 1994] e quetrabalhava somente com a apresentação de uma cadeia alimentar, exibindo conceitos ealgumas relações.Em 1998, iniciou-se o projeto MCOE, no qual o jogo apresenta ao jogador (aluno)um ambiente em que aparecem inúmeros problemas. Ao longo de sua interação como programa, o aluno deve solucioná-los, por meio de seu conhecimento prévio e pelouso de ferramentas que combinadas auxiliarão na construção de um estratégia de ação.O jogo, cuja interface é apresentada na Figura 1 é composto por um lago onde existeum ecossistema formado por peixes, plantas, água e microrganismos com um sistemade reprodução em equilíbrio, até a intervenção de poluentes que provocam alterações noseu estado normal. Esses poluentes aparecem de forma aleatória ao longo do jogo e sãocombatidos através de ferramentas do personagem, escolhidas livremente por cada aluno,que pode interagir com um colega para construir uma estratégia comum para resolver oproblema da poluição do lago.O jogo foi concebido para alunos que estejam freqüentando a 3 a e 4 a sériesdo primeiro grau (ensino fundamental). Ele pode, entretanto, ser utilizado tambémpor crianças de outras faixas etárias através da configurações de seus parâmetros e dautilização de uma metodologia que permita a contextualização do ambiente nas atividadesrealizadas pelos alunos. O jogo foi construído em Visual C++ e com o pacote de APIsDirectX.Já 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óra 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 conscientização ecológica com o auxílio de um “tutor” artificial através deum ambiente que utiliza a metáfora de jogos. O problema abordado e as soluçõesapresentadas trouxeram desafios para serem trabalhados.Em seguida foi desenvolvido o RL-MCOE [Callegari 1999]. Nesse trabalho éapresentada uma proposta de ampliação da arquitetura multiagente reativa descrita em[Giraffa 1999], através de uma técnica de aprendizagem por reforço (W-Learning). Essatécnica trouxe resultados que ampliaram a capacidade de exploração do ambiente de jogo,pois os agentes reativos (peixes) aprenderam novos comportamentos.Em 2001, foi apresentado o E-MCOE [Goulart 2002], que propõe a introdução


Figura 1. O jogo MCOE.de um agente mediador no MCOE, mediando as trocas de informações entre o jogo e otutor. Essa funcionalidade também utilizou agentes reativos modelados com a técnica deaprendizagem por reforço proposta em [Callegari 1999]. Porém, os agentes aluno e tutorforam codificados de acordo com o modelo BDI de agentes cognitivos. Nesse trabalho,então, foram levadas em consideração tarefas/processos externos que normalmente sãotratados no módulo tutor. Esses processos externos permitem distribuir a complexidadeda modelagem e supervisão do conjunto de informações entre a interação dos agentes.Finalmente, em 2005, iniciou-se o projeto AS-MCOE, que, conforme já descritoanteriormente, tem como objetivo avaliar a utilização de tutores inteligentes no ensinode ecologia, dando continuidade ao trabalho desenvolvido no ambiente MCOE. Porém,o tutor e os agentes dessas propostas estão sendo implementados por meio da linguagemAgentSpeak(L) e do interpretador Jason. Os agentes desse estudo estão inseridos em umjogo, construído através da Golden T Game Engine (GTGE).Assim, para melhor compreensão da teoria de agentes apresentada, na próximaseção são abordados os conceitos relacionados a agentes cognitivos baseados em estadosmentais BDI.3. Agentes CognitivosO paradigma orientado a agentes permite um nível de abstração que não é usual nasmetodologias tradicionais de modelagem e implementação, isto é, torna explícitas, no


sistema, certas funcionalidades que antes ficavam apenas subentendidas. À medida emque as aplicações tornam-se maiores e mais complexas, é necessário que se utilize níveisde abstração que permitam representar os problemas e suas soluções da forma maisnatural possível. Os agentes, como entidades autônomas com capacidade de planejarsuas ações, reagir e interagir entre si em busca de soluções para problemas, fornecemrecursos para atingir esse nível (mais alto) de abstração [Zamberlam 2001].O que caracteriza o agente numa visão mais ampla, conforme em [Giraffa 1999],são as interações que ele realiza com o ambiente e os processos internos que possibilitama realização dessas interações. A especificação de quais e como são esses processosinternos é chamada de arquitetura do agente. Dentre as arquiteturas existentes, há a deagentes cognitivos (deliberativos). Um agente cognitivo é um agente racional que possuialguma representação 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, há também asarquiteturas baseadas em estados mentais, que adotam uma perspectiva psicológicapara definir a estrutura dos agentes, que são entidades cujo estado é constituído decomponentes mentais tais como crenças, desejos, capacidades, escolhas e compromissos.Dentro das arquiteturas baseadas em estados mentais, encontra-se a abordagemBDI (Belief, Desire and Intention). Conforme Wooldridge [Wooldridge 2000], é ummodelo consolidado, por ser amplamente estudado. A idéia básica desta abordagemé descrever o processamento interno de um agente utilizando um conjunto elementarde estados mentais como crença, desejo, intenção e na definição de uma estruturade controle através da qual o agente seleciona racionalmente o curso de suas ações.Algumas abordagens de arquitetura BDI agregam as noções 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 crenças 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]. É 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 crenças do agente;• ser, simultaneamente, conflitantes com outros desejos;• não causar diretamente as ações, mas podem, potencialmente, gerar suasocorrências, deixando por conta das intenções a realização de tais ações.As intenções referem-se a um conjunto de objetivos que o agente deliberoualcançar e que, para tanto, exigiram um comprometimento do agente para realização dedeterminadas ações ou tarefas [Bratman et al. 1987]. O processo de inferência de umagente BDI inclui, conforme em [Hübner et al. 2004]:• atualizar crenças, a partir de percepções do ambiente;• definir os objetivos possíveis;• deliberar sobre os objetivos que vai tentar alcançar para confirmar as intenções;• agir com base nas intençõs assumidas.


Existem algumas linguagens e ferramentas que possibilitam a modelageme a programação de agentes BDI, neste trabalho são 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], é uma extensão da programaçãológica para a construção de agentes BDI em sistemas de planejamento reativos(reactive planning systems). Sistemas de planejamento reativos são sistemas que estãopermanentemente em execução, reagindo a eventos que ocorrem no ambiente em queestão situados através da execução de planos que se encontram em uma bibliotecade planos parcialmente instanciados [Bordini and Vieira 2003]. Essa linguagempermite realizar verificações formais, validando os modelos especificados/definidos emaplicações.Segundo [Rao 1996], um agente AgentSpeak corresponde a especificação de umconjunto de crenças e um conjunto de planos. As informações sobre os desejos (osestados futuros a serem atingidos), além das alternativas disponíveis ao agente paraativar as intenções (atingir seus objetivos), estão implicitamente representadas nos planos[Hübner et al. 2004].Planos são referências às ações básicas de agentes no ambiente, ou seja, um planodetermina uma forma de atingir um determinado objetivo (cabeça do plano). Formadopor um gatilho de evento (denotando o propósito do plano), seguido pela conjunção decrenças (literais), representando o contexto (conseqüência lógica das crenças correntesdo agente para um plano aplicável). O restante do plano é composto por ações básicas,que o agente deve executar, e/ou subplanos (realizações ou testes de verificação), istoé, objetivos intermediários que deve tentar atingir, para que o plano tenha sucesso. Asatisfação de uma pré-condição e a ocorrência de um evento ativador são as condiçõespara que um plano possa entrar em execução [Hübner et al. 2004].Além disso, para a implementação de um agente AgentSpeak é necessáriaespecificação das funções de seleção de eventos, planos aplicáveis e intenções do mesmo.As mudanças dos ambiente, os objetivos e as intenções do agente podem representarum número significativo de alternativas viáveis de seleção a cada ciclo de execução dosistema, caracterizando um problema de escalonamento. As funções de seleção não sãode responsabilidade da linguagem mas do programador, pois elas podem ser únicas paracada agente. Cabe ao ambiente de execução do programa determinar os critérios paraselecionar, entre os planos habilitados a execução, aquele que será executado a seguir.Para exemplificar a modelagem de planos, o exemplo de código a seguir descreveo comportamento de um peixe em perseguir e comer outro peixe de acordo com posiçãoe o tipo de presa a sua volta.+percebe(peixeP, DIRECAO): fome


atual (fome), seu plano consiste basicamente em se mover na mesma direção de sua presa(mover(DIRECAO)), cuja ação básica será executada no ambiente. Além disso, conforme[Hübner et al. 2004], um agente AgentSpeak é composto por:• +crença e -crença são eventos que acrescentam (+) ou removem (-) crenças doconjungo de crenças do agente;• !objetivo e ?objetivo são objetivos que o agente precisa alcançar (!) atravésda realização de um sub-plano, ou verificar se já consta como alcançado (?),examinando suas crenças;• ação é qualquer ação interna ou externa, disponibilizada pelo interpretador para oagente.4.1. Interpretador JasonO interpretador Jason, proposto por Hübner em [Hübner et al. 2004], é um sistema paramodelagem e execução de agentes AgentSpeak. Nele é possível descrever planos, crençase o ambiente em que os agentes estão inseridos. Ele é distribuído na forma de um pluginda IDE Jedit 1 , que viabiliza mecanismos para facilitar a configuração, codificação eexecução de um Sistema MultiAgente - SMA (MultiAgent System).O Jason pode ser executado em três diferentes modos. O modo normal executa oSMA de forma contínua, ao contrário do modo debug, que executa passo-a-passo a cadaciclo de raciocínio dos agentes. Além 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 comunicação de agentes com sistemaslegados utilizando protocolos de comunicação diferenciados.Conforme Hübner [Hübner et al. 2004], Jason é um interpretador completamentedesenvolvido e consolidado para versões de AgentSpeak(L) com atos de fala (speechact)para a comunicação entre agentes. Através do ambiente SACI (Simple AgentCommunication Infrastructure), o sistema multiagente Jason pode ser utilizado em redesde computadores. Outra importante característica em relação a outros interpretadores deagentes BDI, é que ele foi implementado na linguagem Java, está disponível em códigoaberto (Open Source) e distribuído sobre a licença GNU LGPL.5. GTGESegundo [Studios 2006] o engine GTGE é uma biblioteca/API de programação multiplataformapara o desenvolvimento de jogos escrita na linguagem Java. Ela forneceum conjunto de rotinas de alto nível para programação orientada a jogos, a fim de queo programador tenha fácil acesso a recursos de hardware, como placas aceleradoras dedeo e som, e rotinas de jogos comuns, como detecção de colisões e o comportamentode personagens.6. AS-MCOENesta seção são apresentadas as etapas que compõem a metodologia empregada namodelagem, implementação e avaliação do projeto.1 http://www.jedit.org


6.1. Especificação dos atributos do jogoO desenvolvimento de um jogo implica na especificação detalhada dos personagens,suas ações e percepções, além das leis que regem o ambiente. Neste caso, as açõese percepções são determinadas pelo papel de cada personagem. Um peixe pode, porexemplo, se mover e perseguir outros seres que sejam considerados alimento. Umpersonagem poluidor (que não é inteligente) e as ferramentas ou “poderes” do jogadorinfluenciam a saúde da cadeia alimentar, e todos esses fatores determinam o grau delimpeza do lago, representado no jogo por um objeto chamado ecômetro (medidor),calculado a partir da média da energia dos seres vivos. Parte dessas heurísticas éapresentada na Tabela 1 de acordo com um estudo realizado por especialistas apresentadoem [Giraffa 1999].RetiradaReposiçãoPersonagem vs. Interventor Lixo Urbando Pesca predatória Esgoto doméstico Pescar em área permitida Devolver peixes em reproduçãoPeixe Pequeno -5 -30 -10 +10 +20Peixe Médio -5 -20 -10 +10 +20Peixe Grande -5 -10 -10 +10 +15Plantas -10 - -10 +5 +5Tabela 1. Retirada e reposição de energia [Giraffa 1999].6.2. Modelagem e implementação de uma interface de software entre o engineGTGE e o interpretador JasonA integração do engine GTGE e do interpretador Jason é modelada e implementadapor meio da troca de mensagens entre o Kernel, que representa o ambiente numaimplementação 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 classe Kernel representa o tratamento das ações e percepções dos agentes numambiente AgentSpeak. Ela troca mensagens com a classe Jogo que modifica o estadodo jogo, modelado pelas demais classes (Ambiente, SerVivo, etc). Por outro lado, essasalterações geram, eventualmente, novas percepções que são então transmitidas ao Kernel.Cada personagem inteligente (SerVivo, Tutor ou Aluno), representado graficamente pelaGTGE, infere novas ações a partir das percepções fornecidas pelo engine.6.3. Implementação do jogoO jogo é implementado seguindo as especificações de “jogabilidade”, interface gráfica ehelp online utilizados no projeto MCOE. Apenas o design gráfico foi aprimorado com oauxílio de profissionais da área de comunicação que fazem parte da instituição de ensinoem que a pesquisa é realizada. A Figura 3 ilustra o protótipo desenvolvido.Para esse jogo foram desenvolvidos mecanismos específicos para o tema emquestão. A cadeia alimentar exige que os personagens possuam um “área de percepção”,de tal forma que possam decidir as ações a serem tomadas. Por exemplo, um peixede tamanho “Grande” (vermelho ou a direita na imagem) persegue peixes de tamanho“Médio” (verde ou a esquerda da figura) quando ele está com fome e estes estão dentrode sua áera de percepção. A avaliação da área de percepção de cada personagem é feitadurante o update de cada quadro da animação.


@A©-%)$ B©¢ ¨3©¢ ©¢. ¢:©§CD¢ ©&. -¢!¢¨3)§:C!Q¢¥§/¥©¢$ ©¢.¤S%©¢$ ©¢."¢R:§. T' . ©C&(U%. !T('! . ©§C" & 9¢ $ %P :-& ¤ ¨*§§B©¢$©¢$ & 9¢ $ +P §B-& ¤ ¨*-!$ ©¢$ § 9% $ ¢¨*-¢$ & 9% $ !¢¨3B-¢©%$ ©¢. V¢B-¢©! $ -¢ ¨*8¢ ¤£ 8 Z6[2BC©¢ !O+. ©¢¤ ¢$§ 9+©¢$ \% -"--& ] -§- "§]:. T('! . ©C&(U%. !T('! . ©§C")!C-¢M§-&('!)!C-¢M§-"#¢)& O¢¢) "©¢ ©%U¢-¢. ) C§-¢$§ O¢©¢¤ ©%U¢-¢. )§ C-%$" §©¢^ 9A:$ ©"©¢-! ©%$ U¢©¢$ -¢§©¢ _ Ia 9¢ $ ¢¨*$ ©¢. V¢B-¢© $ -¢ § ¤¨*©¢$ ©!O¢©¢¤ ©%U¢-¢. )§ C-%$ +U§-¢. ) C-¢$§( ¤ ¨*)-% :!©¢$ §-¢§©¢*O%. )-& ¤ P §B-& ¤ ¨§B§-!O%.8¢¦ e2 L¥ d©%©¢$ ¢ C§-¢),. ©" -(,--¢. ©¢":!©¢$ B©¢:!B-& 9A:$ ©"B¤ -¢%V+©¢$ ¢ ¢ f! C ¤ ¨C¢©¢-! ©%V+©¢$ ¢ ¢ f! C& ¤ ¨*$. -©%$§M-§©¢$"©§B¤)¤ ©!O¢B -% & 9¢ $ +P §B -¢* D©%$ ¨©!NY --& ] -- "%*©%M-C§©¢$§ EZ¢©¢M!-C©%$"!>¥%c¤0§/¥ =(¡. :-&,-§-¢. ©¢"Y ¢$ ¨¢) :¢$ ¨*.A/§¡!0. :-&,!--¢. ©¢"Y ¢$ ¨¢) :¢$ ¨*.5¢¥§ 0§/8¢6 7¢8%¦ ©¢ 9;:§$ ©"¡!¥©¢$ $ %©¢¤ &('¤©¢$ $ ¢©¢¤ "!#K ¤L!2 ¦ ¥§ 68¢ £? 0¢68? ?;KJ 05§¥¢¨3$ ©¢!C©¢$ EF$ ¢:G§ BH+I¨ R ©¢$ ©%.b%8¢¦ 8¢¨Y --¨*:©¢$ B©¢:!B§-¢ & 9¢ $ %P(:©¢$ B©¢:!B§-¤U§©¢$ B©¢:B-%P -¢,Y ©! -& 9¢ $ %¨©¢!©¢$ ¢ O§©¢ ©¢ & 9% $ !¢¨ ] -§-¨§:. !T('! . ©C¨!¢)!7+ 0!¨§:. !T('! . ©CA/8¢ ¤£ 8¢7%¥¢ ¡§2 >¥¢¦" %U¢-¢. ) C§-¢$Ẍ§¢$ ©C¢ $ ©¢ -!O%, ©¢ ©¢ ¢¡¤£ ¥§¦¨©¢¤ ¢©¢§©¢ ©¢§©¢ ¨* ©¢$ ©%U¢©¢$ -¢!©¢ _ Ì 9¢ $ +P :-& ¨ # )C§-¢M§-¨*)+'¤©¢$ $ %©¢¤ ¢ # ©¢$ $ ¢©¢ & ¤ ¢,--¢. ©¢132 4§¦ ¥¥§¦ /0¢ 2 5¢6&¥¨BC©% !O+. ©¢¤ ¢$¨*-! ©¢$ 7%8¢2 W¢8 /!0¨*-! ©¢$ C% $ ©§B-& ¤ ¨*-! ©%$ Figura 2. Diagrama de classes.6.4. Modelagem e implementação em AgentSpeak(L) dos personagens agentes dacadeia alimentarOs personagens, que fazem parte da cadeia alimentar, foram modelados e implementadosde diferentes formas ao longo dos projetos apresentados na seção 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 são modelados em AgentSpeak(L)para que estes desempenhem o seu comportamento desde o primeiro instante de jogo,sem comprometer a simulação e o realismo do mesmo. O exemplo de código da seção 4,descreve os planos de um peixe “Grande” para perseguir um peixe “Médio”.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 questões particulares de ambas as linguagem tiveram de ser avaliadas. Na linguagemX-BDI, onde o tutor foi originalmente modelado, os desejos são codificados de formaexplícita e os planos que permitem realizar estes desejos são crenças que se tornamrealidade mediante a um conjunto de condições. O código a seguir exemplifica o desejodo tutor em ajudar os alunos.DES(tutor, ajudar_alunos).BEL(tutor, ajudar_alunos) ifBEL(tutor, envia_mensagem).


Figura 3. O protótipo AS-MCOE.O tutor deseja ajudar os alunos (DES(tutor, ajudar alunos)) e a maneira deconcretizar este desejo é acreditar que ele envia mensagens BEL(tutor, envia mensagem)para os alunos quando for necessário. Para isso, o código a seguir exemplifica um exemploque concretiza a crença do envio de mensagens.BEL(tutor, envia_mensagem) ifBEL(tutor, next(BEL(aluno, receber_ajuda))),BEL(energia_ecomentro (Ee)),Ee >= 70,Mensagem(16).A crença de que o tutor enviou uma mensagem (BEL(tutor, envia mensagem))torna-se verdadeira quando as seguintes condições são satisfeitas: (i) o aluno desejareceber ajuda (BEL(aluno, receber ajuda)), (ii) o nível do ecômetro é bom e está acimaou igual a 70 e (iii) a ação de enviar mensagem número 16 foi realizada. Observa-se que acrença de que o aluno deseja receber ajuda é uma condição futura, colocando um gatilho(trigger) nessa crença.Para modelar os desejos e crenças do tutor e demais agentes em AgentSpeak(L),deve-se considerar que não há uma representação explícita de desejos nessa linguagem.Desejos são, em AgentSpeak(L), objetivos que podem ser realizados por planossubplanos, ou seja, planos que são ativados por eventos internos.+ajuda[source(aluno)] : energia_ecometro(Ee) & Ee >= 70


1. Avaliar os alunos antes do experimento: com o auxilio dos professores debiologia (e/ou disciplinas corespondentes ou relacionadas) desenvolver o conteúdode ecologia abordado na pesquisa e elaborar uma avaliação que identifiquepontualmente o conteúdo;2. Experimento: desenvolver e aplicar um experimento em laboratório com umaturma de alunos (cujo ano colegial será definido). O experimento compreende nasseguintes atividades:(a) Jogar: disponibilizar o jogo produzido por esta pesquisa aos alunos sobcondições controladas de: tempo, coleta de dados sobre a interação; e(b) Avaliacao do jogo: compreende a coleta de informações sobre asdificuldades e qualidades apresentadas pelo jogo, por meio da observaçãoe relato dos alunos durante as atividades.7. Considerações FinaisEste artigo apresenta uma proposta de tradução 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 eletrônicos e se utiliza de um engine de jogos para sua codificação rápida. Oengine GTGE viabilizou, além da prototipação rápida, um incremento da performancee da qualidade de interação, assim como uma melhor integração para com o ambiente deimplementação de agentes BDI.O projeto AS-MCOE está desenvolvendo experimentos em sala de aula paraavaliação do jogo e do sistema multiagente implementado, que no entanto não puderamser relatados neste artigo até finalização do mesmo.ReferênciasASYMETRIX (1994). ToolBook : user manual. Bellevue, WA.Bordini, R. H. and Vieira, R. (2003). Linguagens de programação orientas a agentes:uma instrodução baseada em agentspeak(l). Revista de Informática Teórica 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? In Cohen, 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 resourceboundedagents. Stanford University, Stanford.Callegari, D. A. (1999). Aplicando aprendizagem por reforço a uma arquiteturamultiagente para suporte ao ensino de educação ambiental. Master’s thesis,PPGCC/PUCRS, Porto Alegre.


Cohen, P. and Levesque, H. J. (1987). Intention = choice + commitment. In NATIONALCONFERENCE 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 construção de sistemastutores inteligentes em ambiente inteligente. Master’s thesis, PUCRS, Porto Alegre,Brasil. Defesa em dezembro de 2001.Hübner, J., Bordini, R., and Vieira, R. (2004). Introdução ao desenvolvimento de sistemasmultiagentes com jason. In XII Escola de Informática da SBC, volume 2, pages 51–89,Guarapuava. UNICENTRO.Móra, M. D. C. (2000). Um modelo formal e executavel de agentes BDI. Tese dedoutorado., CPGCC/UFRGS, Porto Alegre.Oliveira, F. (1996). Inteligência artificial distribuída. In IV Escola regional de informática,Canoas, RS. Sociedade Brasileira de Computação.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 direção a uma técnica para a programação orientada abdi. Master’s thesis, PPGCC/PUCRS, Porto Alegre.


AISO-GT: Um Novo Algoritmo Híbrido de Otimização Baseadonos Sistemas Imunológicos Artificiais e na Teoria dos JogosAndré Ferry Barreira 2,3 , Carlos Eduardo de Jesus Guimarães Oliveira 2,3 ,Otavio Noura Teixeira 1,2,3 , Roberto Célio Limão de Oliveira 11 Programa de Pós-Graduação em Engenharia Elétrica (PPGEE), Departamento deEngenharia Elétrica e Computação (DEEC), Universidade Federal do Pará (UFPA)Caixa Postal 8.619 – 66.075-900 – Belém, PA, Brasil2 Á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, Brasil3 Movimento Evolucionário e Cooperativo para a Construção do Artificial – MEC 2 AAv. 16 de Novembro, 881 – 801 – 66.023-220 – Belém, PA, Brasil{afbarreira,ceguimaraes,onoura}@gmail.com, limão@ufpa.brResumo. Este artigo apresenta a proposta de um novo algoritmo de otimizaçãoavançada baseado na técnica de Sistemas Imunológicos Artificiais e nosPrincípios da Teoria dos Jogos, mais especificamente, na inclusão de uma fasedenominada “Interação Social” no algoritmo original. Para isso, sãoapresentados aspectos relativos aos temas de fundamentação teórica, a propostado algoritmo em si, e finalmente, uma simulação para exemplificar o seufuncionamento.1. IntroduçãoA natureza, em sua perfeição, sempre contorna situações difíceis de maneira a se manterviva. Tendo isso em vista alguns pesquisadores vêm desenvolvendo métodos, processos ealgoritmos que, baseados na natureza, simulam computacionalmente o seu comportamentode maneira a resolver problemas matematicamente insolúveis. Assim surgiu a ComputaçãoNatural.Segundo Forrest et al. (1999), um dos mecanismos biológicos mais poderososexistentes é o Sistema Imunológico Humano. Por esse motivo ele tem sido alvo de estudode muitos pesquisadores na tentativa de desenvolver modelos que possuam as maisimportantes de suas características, como por exemplo, a auto-organização.Em meados de 1980, os cientistas: Farmer, Packard and Perelson publicaram oprimeiro estudo sobre as Redes Imunológicas, que daria início ao que hoje é denominadoSistemas 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 juntosfuncionam como um mecanismo de identificação capaz de perceber e combater disfunçõesde suas próprias células e microorganismos invasores. Ele é responsável pela “limpeza” doorganismo, retirando células mortas, renovando determinadas estruturas, entre outrasfunções. Além disso, também age em células alteradas, as quais diariamente surgem nonosso 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 comsua função. Umas são encarregadas de receber ou enviar mensagens de ataque e, em outroscasos, mensagens de inibição. Algumas apresentam o inimigo ao “exército” do Sistemapara que sejam combatidos e outras liberam substâncias que neutralizam o microorganismoinvasor, ou alguma substância liberada por ele. Junto com os outros sistemas, o SI permitea regulação do corpo, garantindo o seu funcionamento estável.Existem dois sistemas que são responsáveis pelo reconhecimento demicroorganismos invasores: Sistema Imunológico Nativo (SIN) e o Sistema ImunológicoAdaptativo (SIAd). O SIN é assim chamado porque tem a habilidade de reconhecer certosmicróbios e imediatamente destruí-los.Um importante componente desse sistema é uma classe de proteínas do sangue quetem como função auxiliar os anticorpos no combate aos microorganismos. O aspecto maisimportante do reconhecimento do SIN é o fato de induzir a geração de sinais coestimulatóriosque irão resultar na ativação das células T, uma das principais células dedefesa, 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 doistipos 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 doslinfó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 sistemasadaptativos 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 deevolução da população de indivíduos.3.1. Teoria da Seleção de ClonesO 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 possaevoluir. A teoria parte da premissa que para evoluir é preciso reproduzir somente as célulasque 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 receptoressimilares;Proliferar e diferenciar o contato das células maduras com os antígenos;A persistência dos clones esquecidos, resistentes à eliminação pelosantígenos, como base das doenças imunológicas;3.2. Reforço de Aprendizado e Memória ImunológicaA Teoria de Seleção de Clones por si só não proporciona um eficiente combate aosmicroorganismos invasores, pois em caso de re-infecção o processo teria que ser iniciadonovamente. Conseqüentemente, passa a ser necessária uma memória auxiliar que armazeneas configurações das células que apresentam maior adaptabilidade.Quando o Sistema Imunológico detecta uma célula estranha é iniciado um processode geração de linfócitos que, de acordo com sua afinidade com o antígeno, é ou nãoclonado. Em caso de alta afinidade, a célula é clonada e os clones se diferenciam emCélulas de Memória - responsáveis por manter as configurações das células com maioradaptabilidade, pois possuem um tempo de vida maior - e Células de Plasma, responsáveispela 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 osprocessos de clonagem e mutação ainda serão realizados para geração das células decombate 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 emcélulas de combate eficientes.3.3. Hipermutação SomáticaDurante a clonagem, é realizado um processo de mutação com o objetivo de otimizar ascélulas. O processo é denominado hipermutação somática, e provê as células com maioradaptabilidade uma taxa de mutação baixa, enquanto que, as células com baixaadaptabilidade, as quais são consideradas pobres, tem taxa de mutação mais elevadas.3.4. Algoritmo AISOO algoritmo AISO foi desenvolvido baseado no modelo e nos princípios do SistemaImunológico Humano sendo voltado especificamente para otimização e inspirado noalgoritmo Opt-AiNet proposto por De Castro (2002) o qual é extensão do algoritmo AiNetvoltado para otimização. O AISO consiste em uma população de células (anticorpos) quesão representados por um vetor com valores reais. Cada célula é uma solução em potencialpara o problema a ser otimizado.A população passa por um processo de clonagem, mutação, seleção. O algoritmoutiliza uma memória de células onde são armazenadas as melhores soluções (células) nomomento. A estrutura da célula é mostrada a seguir:


As principais características deste algoritmo são: (1) ele determina a localização demú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 utilizadosvalores 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çãosomá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çãoavaliação2.2. Gerar N clones para cada célula;2.3. Cada clone sofre hipermutação somática com taxaproporcional 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 eremover os outros;3. Determinar as células com maior fitness e gravá-las namemória;4. Introduzir uma porcentagem X de células geradasrandomicamente.Os clones sofrem mutação de acordo com a adaptabilidade da célula pai. A taxa demutaçã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 valorrandômico que varia entre (–1 e 1). β é um parâmetro que controla a deterioração da funçãoexponencial inversa (valor padrão 10) e f* é o fitness de c normalizado no intervalo de 0 e1. 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 JogosDe acordo com Borges (1996) a teoria dos jogos lida com situações de conflito deinteresses, onde dois ou mais agentes (ou indivíduos) disputam entre si por algum recursolimitado no ambiente.


A teoria dos jogos descreve problemas reais, fornecendo uma visão geral dasituação. Em alguns casos a teoria pode indicar a solução para o problema, entretanto, namaioria 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 serdefinido como um indivíduo que age racionalmente. Isso leva a consideração de todas aspossíveis conseqüências de seus atos e, a partir disso, se realiza uma certa ordem depreferência entre as conseqüências, baseado em seus próprios atos e na ação que gerou oseu melhor resultado.Em alguns casos o resultado não depende unicamente da escolha feita por um únicoindivíduo, mas sim da ação escolhida pelos outros indivíduos, sobre os quais o primeiroindivíduo não possui qualquer controle.É interessante notarmos que um Agente Humano não toma decisões de acordo como que (Rapoport, 1996) define como racional, isso é, com a intenção de maximizar seusganhos. Aqui percebemos a diferença entre Agentes Racionais e Agentes Humanos.Pode-se identificar todos os elementos necessários para a compreensão do objetivoprincipal da teoria dos jogos a seguir:Jogo: um modelo formal, o que significa que a teoria dos jogos envolvedescrições e análises técnicas. É importante notar que os únicos tipos dejogos 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 detomar decisões que afetam outros agentes. O agente no contexto da teoriados jogos é denominado “jogador”;Racionalidade: assumindo que todos os agentes são racionais, significa queeles utilizam o método mais adequado buscando a satisfação dos seusdesejos;Comportamento Estratégico: isso significa que cada jogador leva emconsideração o fato de que todos os jogadores interagem entre si. Dessamaneira, a decisão tomada irá gerar conseqüências aos outros jogadores.Para exemplificar o jogo, temos o Paradigma do Dilema do Prisioneiro, que podeser definido tradicionalmente como uma situação de conflito de interesses, onde doisindiví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 seriaposto na jaula por três meses por sua cooperação e o outro indivíduo ficariapreso por dois anos;II. Se ambos confessarem o crime, então a cooperação individual perde força eambos ficam um ano presos.III. Se não, caso nenhum deles confesse o crime, eles serão presos por apenas seismeses.


A Figura 1 mostra a tabela de pagamentos do dilema do prisioneiro, o mais clássicojogo de duas pessoas de soma não zero e não cooperativo na Teoria dos Jogos, que combinatodos os possíveis pares de estratégias correlacionando todos os valores de pagamentos comcada um dos jogadores.Figura 1Observando a Figura 1, pode-se observar que cada um dos jogadores tem dois tiposde comportamentos: Cooperar(Coperate) e Trair(Defeated). Por trás disso, tem-se quatrovariáveis que significam: (1) R é a recompensa (Reward) para cada jogador caso ambosvenham a cooperar; (2) P é a punição (Punishment) para cada jogador caso ambos venhama 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 seguintesrelações:T > R > P > ST + SR >2T + S2> PEssas especificações caracterizam o ambiente onde os indivíduos de uma populaçãoirão interagir buscando incrementar o seu Ganho.5. AISO-GTComo forma de possibilitar um aumento do controle da variabilidade da população decélulas, a seguir é proposto um novo algoritmo. Este algoritmo inclui uma nova etapadenominada “interação social”, que foi originalmente proposta por TEIXERA (2005), aoutilizar a Teoria dos Jogos como forma de caracterizar fenotipicamente os indivíduos deuma população, que no caso são as células.Assim, é proposto o uso especificamente do Dilema do Prisioneiro que possibilita adefinição de um ambiente de interação social através da formalização de situações deconflito de interesses, onde os indivíduos da população disputam entre si por recursos neledisponíveis.


A alteração da estrutura da célula se faz necessária tendo em vista a necessidade dearmazenamento valor que caracterizará o seu comportamento. A nova estrutura érepresentada pela figura a seguir:Figura 2O campo de Valor e o de Fitness da célula são mantidos segundo a estrutura doalgoritmo AISO. O comportamento representa a atitude da célula de cooperar ou trairdurante o jogo, enquanto no campo Ganho, são armazenados os valores ganhos de acordocom 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 deavaliação;2.2 Gerar N clones para cada célula;2.3 Cada clone sofre hipermutação somática com taxaproporcional 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 aleatoriamente2.5.2 Obter o comportamento de cada uma das células;2.5.3 Alterar o Fitness das células conforme ocomportamento adotado por cada uma e a tabela depagamentos do jogo;2.6 Determinar as células que apresentem os melhoresresultados no jogo e excluir as demais.3. Determinar as células com maior fitness e gravá-las namemória;4. Introduzir uma porcentagem X de células geradasrandomicamente.Com base na fundamentação teórica e na formalização do algoritmo obtém-se asseguintes considerações finais.6. TestesO algoritmo proposto (AISO-GT) foi implementado utilizando a linguagem deprogramação Java para a minimização da função de benchmarking Schaffer. A populaçãoinicial foi gerada aleatoriamente possuindo quarenta indivíduos e utilizada nas cincoexecuções que se seguiram sem alteração alguma.


Comparação de desempenho para a função de Schaffer entre os algoritmos AISO e AISO-GT4,50E-044,00E-043,50E-043,00E-04Fitness2,50E-042,00E-04AISOAISO-GT1,50E-041,00E-045,00E-050,00E+0070017080715972387317739674757554763377127791787079498028810781868265834484238502858186608739881888978976905591349213929293719450952996089687976698459924ÉpocasGráfico 1Observou-se com o teste que em determinadas épocas o algoritmo AISO é superiorao AISO-GT e vice versa. Contudo, quanto mais próximo do final da execução pode-seobservar 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), querepresenta o desempenho dos algoritmos durante as últimas três mil épocas.7. Considerações FinaisCom base na literatura utilizada e os testes decorridos, pôde-se observar que o algoritmoproposto, 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çãosocial implementada caracteriza uma maior variabilidade populacional do algoritmo.Como proposta futura pretende-se implementar funções de benchmarking dediferentes categorias e com isso promover um estudo comparativo no sentido de descobrirem quais categorias de problemas o algoritmo proposto sobressai-se em relação aosutilizados atualmente.8. Bibliografia[Borges 1996] Borges, P. S. S. A Model of Strategy Games Based on The Paradigm ofthe Iterated Prisoner’s Dilemma Employing Fuzzy Sets. 1996. Tese (Doutorado emEngenharia 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 OptimizationProblems Using an Artificial Immune System. CINVESTAV-IPN, Grupo deComputaçã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 – ASruvey of Applications. Tecnical Report – DCA, 2000.[De Castro 2002] De Castro, L. N; Timmis, J. An Artificial Immune Network forMultimodal Function Optimization. In Proceedings of IEEE Congress onEvolutionary 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ólicade Santos (UniSantos).[Forrest] Forrest, S., A. Perelson, Allen, L. & Cherukuri, R. (1999), “Self-NonselfDiscrimination in a Computer”, Proc. of the IEEE Symposium onResearch in Security and Privacy, pp. 202-212.[Rapoport 1980] RAPOPORT, A. Lutas, Jogos e Debates. Editora Universidade deBrasília, 1980.[Teixeira 2005] Teixeira, O. N. Proposta de um novo algoritmo genético baseado nateoria dos jogos. Dissertação de Mestrado (Programa de Pós-graduação em EngenhariaElétrica – Computação Aplicada) - Universidade Federal do Pará, Belém, 2005.


AstroFácil: Sistema Computacional Embarcado paraAutomatização de Telescópios de Pequeno PorteMarcos Roberto Silva, Maicon Carlos Pereira, Caroline Farias Salvador,Rafael Luiz Cancian, Roberto Miguel Torres, Cesar Albenes ZeferinoCentro 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 – Brasilsilva.marcosr@gmail.com, maicon@univali.br, caroline@univali.br,cancian@univali.br, torres@univali.br, zeferino@univali.brAbstract. O uso de telescópios de pequeno porte na observação astronômicaamadora é muitas vezes restringido pela dificuldade que astrônomosamadores enfrentam para localizar um astro desejado e acompanhá-lo no céu.Este artigo apresenta o desenvolvimento de um sistema embarcado a serutilizado na automação de telescópios de pequeno porte visando facilitar aoperação desses equipamentos por amadores. O sistema é baseado em ummicrocontrolador e possui uma interface para o usuário indicar o astrodesejado e configurar a observação a ser realizada.1. IntroduçãoConsiderada a mais antiga de todas as ciências, a astronomia já atraia os seres humanosmais primitivos que observavam o céu e tentavam compreender os fenômenos queocorriam à sua volta, como as variações de luminosidade, de temperatura e de clima, odeslocamento do Sol, os eclipses, as fases da Lua, as passagens de cometas, etc. Com opassar 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, suaconstituição, origem e evolução.A observação dos astros, também chamada de observação astronômica, pode serfeita a olho nu, mas a visão humana é limitada e restringe muito a capacidade dessaobservação. Então, faz-se necessário o uso de equipamentos, como, por exemplo, ostelescópios ópticos, que permitem “aproximar” corpos celestes observados a longadistância.Na última década houve um avanço da astronomia observacional por meio dodesenvolvimento de telescópios de grande porte, como, por exemplo, os telescópios deoito metros de diâmetro [Gemini Observatory, 2006], além de telescópios virtuais eremotos 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 interessepela observação astronômica amadora, viabilizada por telescópios de pequeno porte e demenor custo, como o telescópio ilustrado na Figura 1, cuja estrutura de sustentaçãoutiliza 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 determinadoastro implica em apontar o tubo do equipamento para as coordenadas do astro na esferaceleste que, dependendo de como são especificadas, variam conforme o local, a data e ohorário. Isso ocorre porque o movimento de rotação da Terra causa um deslocamentoaparente (de leste para o oeste) do astro na esfera celeste. Assim, também durante aobservação, esse movimento tira o astro da posição inicial da observação e do foco dotelescópio, tornando necessário que o observador redirecione o telescópioperiodicamente a fim de acompanhar o aparente deslocamento do astro.Para iniciantes na observação astronômica, a simples localização do astro atravésde suas coordenadas dificulta a observação e, muitas vezes, desestimula os usuáriosamadores, levando-os a “aposentar” precocemente o equipamento. No entanto, parafacilitar essas tarefas, pode-se equipar um telescópio com um computador dedicado queautomatize as operações de localização e acompanhamento de um astro. Esse tipo decomputador dedicado, com a aparência de um coletor de dados, é mais conhecido pelotermo “manete” (ou hand controller).Os manetes modernos são baseados em microcontroladores e oferecem umasérie de funcionalidades e facilidades aos usuários. No entanto, como não existemmanetes fabricados no Brasil com tais funcionalidades, o acesso a esse tipo deequipamento é restrito a astrônomos profissionais e aos amadores com maior poderaquisitivo, pois o custo dos manetes importados é razoavelmente alto.Nesse contexto, este trabalho é resultado de um projeto de pesquisa que visadesenvolver e disponibilizar um conjunto de soluções tecnológicas de baixo custo parafacilitar a observação astronômica a um maior número de usuários, estimulando aprática contínua dessa atividade por astrônomos amadores e, em especial, porestudantes. O projeto inclui o desenvolvimento do manete apresentado neste artigo, deum 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 infraestruturabásica de telescópios de pequeno e médio porte adquirida com apoio daPetrobras.


O projeto do manete, foco deste artigo, teve início com um trabalho deconclusão de curso em Ciência Computação [Silva, 2003], e pode ser continuado emuma parceria universidade-empresa fomentada pelo CNPq (Edital RHAE 14/2004).O manete é baseado em um sistema computacional embarcado e é capaz decomandar a operação de um telescópio, posicionando-o e guiando-o para acompanharum astro selecionado, tudo de forma automática, facilitando o trabalho do observador. Osistema é baseado em microcontroladores e utiliza periféricos externos para interaçãocom o usuário, armazenamento de informações sobre astros e movimentação dotelescópio, conforme serão mostrados nas próximas seções.O texto deste artigo é estruturado em sete seções, incluindo a Introdução. NaSeção 2 são resumidos alguns sistemas similares. A Seção 3 apresenta a funcionalidadedo sistema desenvolvido, enquanto que a quarta seção descreve as arquiteturas dehardware e de software do sistema. A Seção 5 apresenta informações técnicas sobre aimplementação e a validação física do sistema e a Seção 6 apresenta uma discussão arespeito do impacto deste trabalho. A Seção 7 conclui com as considerações finais.2. Sistemas SimilaresUm manete moderno é um dispositivo baseado em computação embarcada e possui umteclado para a entrada de dados e um display para apresentação de informações aousuário. Internamente, inclui um ou mais microcontroladores e unidades de memórianão volátil para armazenamento de dados, entre outros componentes eletrônicos. Omanete é 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 decontrole que aciona os motores que movimentam o tubo do telescópio. Alguns modelosmais recentes utilizam conexão sem fio entre o manete e a montagem. A Figura 2apresenta imagens de dois exemplos de manetes, sendo o primeiro da MeadeInstruments Corporation (2006) e segundo da Sky-Watcher (2006).Figura 2. Exemplos de manetes: Autostar da Meade e SkyScan da Sky-WatcherFonte: Meade Instruments Corporation (2006) e Sky-Watcher (2006)


Conforme pode ser observado nos modelos ilustrados na Figura 2, a interface doteclado de um manete possui quatro conjuntos básicos de teclas. O primeiro inclui umatecla para confirmação dos dados de entrada e outras duas teclas cujas funcionalidadesdependem do modelo. O segundo conjunto consiste de quatro teclas de sentido paramovimentação do tubo óptico. Já o teclado numérico (ou alfa-numérico) é usado paradiferentes funções: escolher a velocidade de movimentação do tubo, selecionar avelocidade 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 menusmostrados no display (orientado a caractere) e, no caso do modelo da Meade, uma teclapara acesso a informações sobre o astro selecionado: “ ”. No modelo da Sky-Watch, asteclas numéricas são multifuncionais, servindo de atalho para algumas funções.Um dos manetes mais utilizados é o modelo #497 Autostar da MeadeInstruments Corporation (2006). Ele disponibiliza várias funções ao observador, como:alinhamento automático do tubo, localização do astro na esfera celeste (capacidade GOTO), acompanhamento do seu deslocamento, entre outros. Contudo, o seu preço noBrasil é de cerca de R$ 690,00 [OMNIS LUX, 2006] e seu uso acaba se restringindo aosastrônomos profissionais e aos astrônomos amadores com maior poder aquisitivo.Existem manetes com menor custo, porém com funcionalidade limitada (ex. semas capacidades de localização ou de acompanhamento automáticos), ou com interface deentrada mais restrita. Por exemplo, alguns deles oferecem apenas comandos para guiar otelescópio manualmente, por meio do acionamento dos motores da montagem comdiferentes velocidades e com a possibilidade de interromper a movimentação quando oobjeto-alvo é apontado. Isso auxilia no deslocamento do tubo e oferece um apontamentomais preciso, se comparado com a operação totalmente manual, mas a localizaçãocorreta e o acompanhamento do objeto-alvo são feitos pelo observador e não pelomanete.3. Funcionalidades do Sistema Embarcado para Controle de TelescópiosO manete desenvolvido é denominado AstroFácil e tem a finalidade de realizar algumasfunçõ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 suascoordenadas 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 softwareexecutadas por um microcontrolador embutido no manete (mestre) e ummicrocontrolador de um circuito de controle auxiliar, acoplado na montagem (escravo).Além do microcontrolador mestre o computador do manete inclui um conjunto deperiféricos externos ao microcontrolador. Um teclado oferece uma interface de entradasimilar à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 dereló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 dosistema com informações sobre diversos astros, incluindo, para cada um deles, o códigodo astro, as suas coordenadas (ascensão reta e declinação) e o ano da obtenção dessascoordenadas, a fim de que elas possam ser precessionadas (ou seja, atualizadas para adata corrente da observação). A base de dados também armazena as coordenadasgeográficas (latitude e longitude) de locais de observação. Uma interface serial permitea conexão do manete a um microcomputador de uso geral, permitindo a atualizaçãoautomática das bases de dados.Na operação normal do sistema, o microcontrolador mestre obtém a data e ohorário do sistema (do relógio de tempo real) e as coordenadas geográficas da cidadeonde está instalado o telescópio (mantidas na memória não-volátil). Após, a partir daidentificação do astro, ele determina as coordenadas astronômicas atualizadas efetuandoos cálculos definidos por Meeus (1998). Por fim, ele envia essas coordenadas para omicrocontrolador escravo através de uma interface de comunicação serial para que eleacione os motores de posicionamento do telescópio.Para a realização de algumas funções o usuário pode selecionar a cidade (de umalista de cidades pré-armazenadas) ou informar a latitude e a longitude do local daobservação. Além de posicionar o telescópio para observação de um astro (através deseu código ou das suas coordenadas), o sistema oferece ao usuário a opção deacompanhar o astro por um longo período de tempo, seguindo o movimento de rotaçãoTerra.4. DesenvolvimentoO projeto do AstroFácil foi realizado utilizando a metodologia de desenvolvimentoapresentada por Wayne Wolf (2001), a qual é composta por cinco etapas, sendo elas:análise dos requisitos, especificação, projeto arquitetural, projeto dos componentes eintegração do sistema. Essas etapas foram realizadas em uma abordagem top-down,iniciando com a definição dos requisitos do sistema e terminando com detalhesconcretos do mesmo.4.1 Arquitetura do HardwareA arquitetura de hardware do sistema é representada na estrutura em camadas ilustradana Figura 3. No manete, o microcontrolador mestre conta com um conjunto deperifé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 (ElectricallyErasable 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, conformea necessidade. Quanto maior o número de chips, maior é a capacidade da base de dadospara 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-depassoque movimentam o tubo do telescópio. O microcontrolador escravo atua sobre osmotores, utilizando sensores para o controle de posição em malha fechada.


ManeteSoftwareMicrocontrolador MestreUSARTCircuito de Controle AuxiliarSoftwareUSART MicrocontroladorEscravoTeclado LCD EEPROM RTCMotores de passoFigura 3. Arquitetura de hardware do AstroFácilO modelo de dispositivo escolhido para implementar microcontrolador mestrefoi o PIC18F452 da Microchip (2002). A escolha por um microcontrolador PIC sejustifica pela disponibilidade de ferramentas de desenvolvimento (montador,compilador, simulador e kits de prototipação) e também pela cultura já estabelecida nouso dessa arquitetura no laboratório de pesquisa deste projeto e no próprio mercadonacional. Já escolha do PIC18F452 para o primeiro protótipo é justificada pelacapacidade da suas memórias integradas e pelas características do seu conjunto deinstruções, além da freqüência de operação.Para o microcontrolador escravo, utilizou-se o PIC16F628, também daMicrochip (2003). Esse microcontrolador se justifica pelo seu baixo custo e pequenaquantidade de pinos. Com relação aos periféricos externos utilizados, a Tabela 1apresenta suas características e funcionalidades no projeto AstroFácil.Tabela 1. Características e funcionalidades dos periféricos usados no AstroFácilPeriférico Modelo/Característica FuncionalidadeTeclado 14 teclas Interface de entrada do usuárioLCD4 linhas × 16 colunasInterface de saída visual para o usuáriopadrão HD 44780Motores-de-Passo 2 motores com 1.8º por passo Movimentar o telescópioMemória EEPROM 1 a 7 chips 24LC256 de 32 KBytescom interface I2C (máx. 256 KBytes)Armazenar informações dos astros ecoordenadas geográficasRelógio de tempo-real PCF8563 Armazenar e atualizar a data/horaO hardware do AstroFácil foi modelado no ambiente de simulação Proteus/Isisda Labcenter Electronics (2000a, 2000b). Esse modelo foi utilizado, na primeira fase doprojeto, para suportar a validação do software durante o seu desenvolvimento. AFigura 4, a seguir, apresenta o diagrama esquemático do sistema, composto pelo manete(circuito em destaque) e pelo circuito de controle auxiliar para acionamento dosmotores.


Figura 4. Diagrama esquemático do modelo do sistema embarcado4.2 Arquitetura de SoftwareO 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 identificadosentidades utilizadas na construção do sistema e os fluxos de dados entre o processo denível 0 e essas entidades.LCDRS 232PCTecladoInfTeclaMensagem0InfAtualizacaoEEpromExternainfEstrelaAstrofacil(Manete)+inf_DataHoraInfControleRS 232Circuito deControleAuxiliarRTCFigura 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 dodiagrama 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 naTabela 2, logo a seguir.Figura 6. Diagrama de Fluxo de Dados de nível 0Tabela 2. Detalhamento dos processos do DFD de nível 0ProcessoDescrição1. Verificar Aguarda o comando informado pelo usuário e invoca o processo responsável proComando executa-lo2. 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 astro3. Calcular Posição Calcula a posição do astro para a observaçãodo Astro4. Manipular Armazena e Busca informações dos astros na EEPROMestrelas5. Calcular Atualiza as coordenadas do astro na data atualPrecessão


5. Implementação e Validação FísicaO software do sistema foi codificado em linguagem C, utilizando-se o compilador Cpara 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 escravoconsome 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, emdestaque) e do acionamento do telescópio (à esquerda). Essa prototipação permitiuconfirmar a correção da integração do sistema e bem como da execução de cada uma desuas funcionalidades, ressaltando-se que o foco desse processo foi na validação dosoftware e da montagem do circuito eletrônico.Figura 7. Prototipação do sistema em bancada de testesMANETEA validação da correção dos cálculos astronômicos executadas pelomicrocontrolador foi realizada com o suporte do software Sky Map Pro 9, desenvolvidopor Marriott (2002).A Figura 8.a apresenta a imagem do primeiro protótipo do manete integrado emuma caixa do tipo “coletor de dados”. Como pode ser observado, o LCD de quatrolinhas permite a visualização facilitada de informações, pois é menos restrito que osLCDs de duas linhas tipicamente adotados nos manetes importados. O teclado é do tipomatriz e algumas de suas teclas permitem a entrada de números e de caracteres doalfabeto (para a entrada do nome de um astro), da mesma forma que em um teclado detelefone. Quatro teclas servem também para indicação de direção. Uma característicaimportante do manete AstroFácil é que os menus são disponibilizados em português, oque torna a sua operação ainda mais facilitada a astrônomos amadores sem o domínio doinglês, idioma tipicamente adotado nos manetes importados.


Figura 8. AstroFácil: (a) Protótipo do manete; (b) telescópio Orion EQ3 commontagem equatorial a ser utilizado nos testes de campoO 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 foramrealizados os experimentos necessários à validação completa do sistema, o que será feitona próxima etapa do projeto.6. Análise ComparativaO manete AstroFácil apresenta funcionalidades similares às dos modelos comerciaisimportados disponíveis no mercado, conforme o quadro comparativo da Tabela 3. Alémdisso, ele foi projetado para ser utilizado com telescópios de baixo custo para os quaisesse tipo de manete não é usualmente disponibilizado. Por exemplo, o Meade #497Autostar é direcionado a telescópios de nível intermediário com preço médio acima deR$ 4.000,00. Por exemplo, o preço do telescópio ETX-90PE da Meade, incluindo amontagem e o Autostar, é igual a R$ 4.600,00, sendo este o modelo automatizado demenor custo em um distribuidor nacional [Omnis Lux, 2006]. Uma vantagem evidentedo AstroFácil em relação aos modelos importados está na flexibilidade e napossibilidade de expansão da sua funcionalidade e da sua capacidade. Com oconhecimento estabelecido a respeito da tecnologia e da área de aplicação, é possíveldesenvolver novas soluções que atendam a necessidades ainda não identificadas nesteprojeto.


Tabela 3. Comparativo de características: Autostar x AstroFácilCaracterísticas Meade #497 Autostar AstroFácilPreço R$ 690,00 (1) R$ 350,00 (2)Idioma dos menus Inglês PortuguêsLocalização automática do objeto alvo SIM SIMAcompanhamento automático SIM SIMDisplay orientado a caracteres 2×16 4×16MicrocontroladoresAtmel 89C451PIC 16C57PIC18F452PIC16F628(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 doisaspectos. Primeiramente, o trabalho está sendo desenvolvido em uma parceria entre umauniversidade e uma empresa sediados na mesma cidade, o que fortalece odesenvolvimento da sua região. Em segundo lugar, a experiência na execução desteprojeto, envolvendo alunos de graduação, tem propiciado a capacitação de recursoshumanos qualificados na área de concepção de sistemas embarcados. Recursos este quepoderão ingressar no mercado de trabalho regional com um diferencial em sua formaçãoacadêmica.7. Considerações FinaisEste artigo apresentou o desenvolvimento de um sistema computacional embarcado,baseado em microcontrolador, para operação automática de telescópios de pequenoporte, visando, principalmente, facilitar a observação astronômica por astrônomosamadores. Foi apresentada a descrição da arquitetura de hardware e de software dosistema 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 paraacesso remoto ao telescópio via WWW, já desenvolvido em um trabalho de conclusãode graduação. Essa solução permitirá, por exemplo, que uma escola disponibilize umobservatório de pequeno porte e de baixo custo a seus alunos para que eles possamrealizar observações astronômica de suas próprias residências, ampliando, ainda mais, oacesso a esse tipo de infra-estrutura.AgradecimentosEste trabalho foi apoiado pelo CNPq – Edital 14/2004 (Fomento Tecnológico) e contacom infra-estrutura prévia fomentada pela Petrobrás.


ReferênciasBoczko, 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:. Acesso em: 02 de abril de 2006.CCS (2003) “C Compiler Reference Manual”, July.Gemini, Observatory (2006) “About The Gemini Observatory: exploring the universefrom both hemispheres”. Disponível em: . Acesso em: 02 de abril de 2006.Labcenter Electronics (2000a) “Proteus VSM Virtual System Modelling - UserManual”, June.Labcenter Electronics (2000b) “ISIS Intelligent Schematic Input System - UserManual”, June.Marriot, C.(2002) “Sky Map Pro 9: tutorial”. Disponível em:. Acesso em: 02 de abril de 2006.Meade Instruments Corporation (2006) “Meade Autostars”. Disponível em:. 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:. Acesso em: 02 de abril de 2006.Omnis Lux (2006) “Omnis Lux: astronomia e projetos culturais”. Disponível em:. Acesso em: 02 de abril de 2006.Silva, M. R. (2003) “Instrumentalização Robótica de Telescópio” Trabalho deConclusão de Curso (Graduação em Ciência da Computação)–Universidade do Valedo Itajaí, Itajaí.Sky-Watcher (2006) “SkyScan Kit (EQ6)”. Disponível em: . Acesso em: 02 de abrilde 2006.Werneck, L. S., Nader, R. V. e Campos, J. A. S. (2004) “O Telescópio Remoto doObservatório do Valongo”, In: Boletim da Sociedade Astronômica Brasileira, Rio deJaneiro, UFRJ, 2004. p. 189-189.Wolf, W. (2001) “Computer as Components: Principles of Embedded ComputingSystem Design”, Morgan Kaufmann Publishers. 2001.Zeferino, C. A. et al. (2005) “A Web-based system for management of the access to anastronomical observatory through Internet. In: 4th International Information andTelecomunication Technologies Symposium (I2TS 2005), Florianópolis. p. 130-133.


Aplicativo Controlador de Potência de Pseudo-Satélite e SuasAplicaçõesLuiz Eduardo Guarino deVasconcelos 1 , Durval Zandonadi Jr. 2 , FernandoWalter 2 , Jorge Tadano 11 Tecnologia da Informação – Grupo Especial de Ensaios em Vôo (GEEV-CTA)São José dos Campos – SP - Brasil2 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 à interfacedos ensaios realizados em um protótipo de Pseudo-Satélite (PS). O PSdesenvolvido, no ITA, foi concebido para aplicações aeronáuticas, mas seuemprego em Agricultura de Precisão (AP) é imediato. Juntamente com o PSfoi desenvolvido um aplicativo, pela Seção de TI do GEEV, dedicado paracontrole automático de potência do PS que adquire dados de receptores GPSe provê feedback para um usuário através de uma interface RS-232.Resultados dos testes aeronáuticos realizados e o desenvolvimento doaplicativo 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 BasedAugmentation 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áticosA 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. Conceitos2.1. Aplicações em APA 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 oexemplo didático de perfilprogramado (letra “S”).Figura 4.Exemplo de perfilde aração circularcontínuo onde seráempregado um pivô deirrigaçã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 superiordireita.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 emdesenvolvimento no ITAFigura 7. Malha básica de controle envolvendo pseudosatélitee 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 software3.1. O Controlador de potênciaO 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 UFO 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ênciaEstraté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élitesEm 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. LOGO 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ósensaiopermite 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 CheckSumPara 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 manualDurante 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 Utilizados4.1. MicrocomputadorO 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, placamãeSoyo Dragon Plus com chipset KT-600, placa dedeo 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átilOs 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 PSEquipamento Porta Taxa(bps)Bit de paridade Bits de dados Stop-bitReceptor GPS COM1 38400 Nenhum 8 1PS COM2 9600 Nenhum 8 14.3. Receptores GPSEm 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-12Figura 9. Receptor Ashtech Z-FX4.4. Rádio - ModemO 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ádiomodemXSTREAM-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 obtidasexperimentalmeQWH QD TXDO R WHPSR 77; FRUUHVSRQGH DR WHPSR HP TXH R SDFRWHcomeça a ser enviado pelo canal; o tempo 75;B727$/FRUUHVSRQGHDRWHPSRWRWDOquando 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ção5.1. Algumas instruções utilizadasAs 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çãoA 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 RS232. 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 controladorO 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 dossatélites em vista comrespectivos índicesC/N0.Figura 12. Tela indicativade captura do pseudosatéliteversus últimas20 amostras.Figura 13. Telaindicativa de variaçãoda potência recebidaem dB˜Hz em relação aPREF versus últimas 20amostras, relativa aosinal do PS.Figura 14. Tela comrepresentaçãobidimensional 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


espeito 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çõescapturadas 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ãoparticipantes.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 inProceedings 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 GPSPerformance, 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 andApplications Progress in Aeronautics and Astronautics Vol. 163, AIAA.


Desempenho de Multicast em redes altamenteinterconectadasFernando Teubl Ferreira 1 , Sergio Takeo Kofuji 11 PAD-LSI, Escola Politécnica da USP – Universidade de São PauloSão Paulo – SP – Brasil{ftf, kofuji}@lsi.usp.brResumo. A utilização de redes Multicast proporciona uma significativadiminuição de banda em aplicações que exigem que a mesma informação sejadistribuída para múltiplos usuários. Destarte, a utilização de redes multicastvem sendo estendida para muitos outros cenários, como por exemplo, redesad-hoc. Ambientes que permitem diversas interconexões entre agentes, noentanto, podem tornar o Multicast menos eficiente, e em certos casos odesempenho do Multicast pode ser até inferior ao do Unicast. Este artigocontrasta esta diferença, demonstrando por simulações a relação entretopologias altamente interconectadas com o desempenho Multicast e Unicast1. IntroduçãoO aumento de aplicações multimídia, tais como áudio, vídeo conferência e webTV, levoua um significativo aumento da transmissão de dados sobre a Internet. Aplicativosmultimídia têm como característica a necessidade de uma grande banda, e geralmenteestes dados são simplesmente replicados para diversos usuários de interesse, causandouma redundância no uso da rede.O protocolo Multicast diferencia-se do Unicast por possibilitar o envio deinformações idênticas para um grupo de usuários, sem haver a necessidade de replicarindividualmente as informações endereçadas para cada um. Isto reduz a banda necessáriano servidor, e supõe-se habitualmente que o uso de Multicast é consideravelmente maiseficiente do que Unicast.Em topologias tradicionais (árvore, anel e estrela), o desempenho da utilização deredes Multicast se mostra, em geral, superior ao equivalente grupo de conexõesindividuais Unicast, uma vez que se espera, no caso ideal, que a rede Unicast tenha ocrescimento 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 dosmodelos 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 oestabelecimento de conexões entre os agentes dinamicamente, e a quantidade deconexões entre agentes pode ser variável e configurável conforme demanda,necessidades e capacidades.


Este artigo explora redes altamente interconectadas e estáticas, apresentandouma relação entre a quantidade de nós, número de usuários e número de conexões – oudistância média entre nós –, com o desempenho do aplicativo.2. Revisão bibliográficaA busca de melhor desempenho em transmissão dedeo em tempo real utilizando redesMulticast 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 paraa transmissão de dados e controle para um determinado grupo de usuários tempromovido o uso de redes Unicast, uso de redes Multicast, e até mesmo soluçõeshíbridas [Majumdar et al. 2002].Redes ad hoc, devido à alta mobilidade dos agentes durante a transmissão dedados, geralmente são propícias a ter conexões instáveis, ocasionando súbitasinterrupções ou corrompimento de dados em determinado segmento da rede no qual umagente qualquer se desloca ou desconecta. Este fato pode proporcionar quebras deconexões, forçando um restabelecimento de rotas alternativas, caso possível, paragarantir a continuidade da entrega dos pacotes para todos os usuários pertencentes a umdeterminado grupo Multicast.Algumas propostas têm sido levantadas para contornar a falta de confiabilidadedestes cenários supra-expostos. Uma das técnicas é a realização de múltiplos caminhosMulticast entre o servidor e os seus clientes, utilizando múltiplas conectividades emúltiplas rotas [Wei e Zakhor 2004a; Rajendran et al. 2004; Viswanath, e Obraczka2005; 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. Asaná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últiplasconexões Unicast, visando delinear um perfil extremo de redes onde a utilização deprotocolos Multicast deve ser cuidadosamente analisada.3. Fatores de diminuição de desempenho em MulticastO uso de Multicast contribui para a diminuição de pacotes trafegados em quase todos oscenários onde se exige que múltiplos usuários recebam ou troquem as mesmasinformações entrem si. Porém, em alguns casos particulares, o Multicast pode oferecerum desempenho inferior ao Unicast.Para compreender o conceito de tais características, iremos apresentar dois casosextremos.3.1. Número de usuáriosEm um cenário onde existam poucos usuários (ou apenas um único usuário) no grupo dereceptores, 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 tornainferior ao Unicast em termos de desempenho de rede.3.2. Distância média entre servidor e clientesSe conseguirmos estabelecer conexões entre o servidor e todos os demais usuários, sema necessidade de roteamento em nós intermediários, novamente observaremos que aquantidade de informações necessárias para o Multicast será similar à quantidade deinformações do Unicast, já que não há aproveitamento de canal. De mesma forma, ooverhead proporcionado pelo Multicast, no qual adicionalmente haverá um maiorcontrole por oferecer uma topologia mais complexa do que no caso anterior (apenas umusuá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 experimentoO presente artigo tem como foco avaliar o desempenho de redes Multicast altamenteconectadas. A primeira característica importante é que as redes analisadas neste artigosão estáticas, ou seja, nenhum link é interrompido ou criado em tempo de simulação, enenhum nó se move sobre a rede. Tal característica foi fixada para evitar uma grandevariação do comportamento das simulações para cada ambiente específico, mantendo ofoco especificamente em redes com grande número de conexões.Uma segunda característica do cenário em estudo é o protocolo usado. Dentrediversos 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, foramselecionado os protocolos PIM-DM e DVMRP. A escolha se justifica por serem estes osprotocolos mais difundidos e aplicados em redes estáticas.5. Modelo de simulaçãoTodas as simulações foram realizadas através do simulador NS2 [Ns-2], com um tempototal de simulação de 10 segundos.Nas simulações, não é considerado a perda de pacotes, atribuindo em todas asconexõ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 dosistema, de forma genérica, sem envolver cenários específicos com suas limitações. Odelay 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 umthroughput 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 docomportamento da simulação.


5.1. TopologiaOs cenários de análise são gerados da seguinte forma: Partindo de uma rede tipo tokenring (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ídosentre os nós. Partir de uma rede token ring garante que não há sub-redes isoladas, e aadição de conexões extras leva a uma rede mesh. Levando em conta que o objetivo desteartigo é a simulação de redes altamente interconectadas, há pouca influência da topologiainicial. 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 tokenring, adiciona-se conexões entre nós aleatórios5.2. Entrada e saídas de usuáriosHá dois modelos de join (entrada) e leave (saída) de usuários: aleatório e constante. Nomodelo aleatório, os usuários entram e saem dos grupos Multicast com distribuiçãolinear, sendo que a simulação sempre é iniciada e finalizada sem nenhum membro.No modelo constante, um número pré-estabelecido de usuários permanece nogrupo desde a inicialização até a finalização da simulação, sem variação. Este últimomodelo provê uma simulação mais direcionada ao escopo deste artigo, discriminando oprocesso de join e leave dos usuários, assim como não oferece variação do número deusuários em qualquer instante da simulação, o que permite analisar a rede em regimepermanente.5.3. MétricasAs 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 osnós. Espera-se com estas métricas uma contabilização total dos recursos utilizados darede, servindo como base de comparação e análise durante toda a descrição deste artigo.6. Simulações e Análises6.1. Simulação 1: Grande quantidade de nós com usuários aleatóriosConsiderou-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-sedistribuídos aleatoriamente, adiciona-se N conexões entre dois nós aleatórios, e onúmero de conexões adicionais usado é {10, 200, 500, 1000, 2000 e 4000}. O númerode usuários é de 60, em um total de 600 nós e um servidor. Os usuários entram e saemdo grupo de forma aleatória.


Os gráficos representam a quantidade acumulativa total de dados enviado portodos os nós (dado + controle).Acumulo de dados trafegados (kb)7E+076E+075E+074E+073E+072E+071E+0700,61,21,82,4UnicastDVMRPPim-DM033,64,24,85,4Tempo66,67,27,88,499,6Figura 2. N = 10Para poucas interconexões (figura 2), o desempenho Multicast mostra-sesuperior à múltiplas conexões Unicast. A diferença entre o Multicast DVMRP eMulticast PIM-DM é decorrente das características de seus protocolos, que sãoseveramente afetadas pela topologia.Acumulo de dados trafegados (kb)3E+072E+072E+071E+075E+06UnicastDVMRPPim-DM000,61,21,82,433,64,24,85,466,67,27,88,499,6TempoFigura 3. N = 200Conforme 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.Acumulo de dados trafegados (kb)2E+072E+071E+071E+071E+078E+066E+064E+062E+06000,6UnicastDVMRPPim-DM1,21,82,433,64,24,8Tempo5,466,67,27,88,499,6Figura 4. N = 500


Para N=500 (figura 4), temos o número médio de nós entre dois pontos umpouco abaixo de 5, com a média de 3,6 conexões por nós. A queda do desempenhoMulticast em relação a múltiplas conexões Unicast torna-se evidente.Acumulo de dados trafegados (kb)2E+072E+071E+071E+071E+078E+066E+064E+062E+06000,6UnicastDVMRPPim-DM1,21,82,433,64,24,8Tempo5,466,67,27,88,499,6Figura 5. N = 1000Uma 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 emque se aumenta o número de conexões. Sem entrar em detalhes, fora do escopo desteartigo, este protocolo tem como característica assumir que todos os nós pertencem aogrupo de Multicast até receber uma requisição explícita de exclusão. Desta forma, commúltiplas conexões e inúmeros caminhos possíveis entre os nós, o protocolo PIM-DMtem uma sobrecarga no início da simulação.Acumulo de dados trafegados (kb)2E+071E+071E+071E+078E+066E+064E+062E+06UnicastDVMRPPim-DM000,61,21,82,433,6Tempo4,24,85,466,67,27,88,499,6Figura 6. N = 2000Com 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 é de20, e tais características de desempenho estão restritas à topologia e conexõesestabelecidas.


Acumulo de dados trafegados (kb)3E+072E+072E+071E+075E+06UnicastDVMRPPim-DM000,61,21,82,433,64,24,85,466,67,27,88,499,6TempoFigura 7. N = 4000Quando o número de conexões média atinge um pouco mais de 15 conexões porusuário, com a distância média entre nós de 2,3 hops, o desempenho Multicast supera odesempenho 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 quantidadetotal de dados transmitidos em relação à quantidade de conexões:Quantidade total de informações transferidas (kb)70000000600000005000000040000000300000002000000010000000UNICASTPIM_DMDVMRP00 500 1000 1500 2000 2500 3000 3500 4000 4500Número de conexões adicionaisFigura 8. relação entre conexões e total de informações transferidasNovamente, os dados analisados acima referem-se ao uso total da rede dosistema. Nota-se que o desempenho de múltiplas conexões Unicast tem uma rápidamelhora em relação aos recursos totais da rede. Este fato é independente do comparativocom 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.Dados enviados (Kb)80000700006000050000400003000020000UnicastDVMRPPim-DMDados enviados (Kb)1000009000080000700006000050000400003000020000UnicastDVMRPPim-DM10000000,81,62,43,24Tempo (s)4,85,66,47,288,89,610000000,81,62,43,24Tempo (s)4,85,66,47,288,89,6Figura 9(a)Figura 9(b)1000009000080000UnicastDVMRPPim-DM900008000070000UnicastDVMRPPim-DMDados enviados (Kb)7000060000500004000030000Dados enviados (Kb)60000500004000030000200002000010000000,81,62,43,24Tempo (s)4,85,66,47,288,89,610000000,81,62,43,24Tempo (s)4,85,66,47,288,89,6Figura 9(c)Figura 9(d)Dados enviados (Kb)90000800007000060000500004000030000200001000000UnicastDVMRPPim-DM0,81,62,43,24Tempo (s)Figura 9(e)4,85,66,47,288,89,6Dados enviados (Kb)8000070000600005000040000300002000010000000,81,62,43,24Tempo (s)Figura 9(f)Figura 9. Dados enviados pelo servidor em relação ao tempo4,85,66,47,2UnicastDVMRPPim-DM88,89,6


6.2. Simulação 2: Relação número de usuário e quantidade de conexõesCompletando as simulações anteriores, foram realizadas diversas simulações variando aquantidade média de nós intermediários e números de usuários. Todas as simulações aseguir 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 desimulação de 10 segundos). Porém, o número de usuários é constante, entrando notempo 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 demaisprotocolos Muticast convenientes a este cenário, não será utilizado nesta próximasimulaçã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), deixandodesta 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 portodos os nós.Tabela 1. Total utilização dos recursos em relação às conexões e número de usuários12 usuários 10 usuários 8 usuários 6 usuáriosConexões HOP Unicast DVMRP Unicast DVMRP Unicast DVMRP Unicast DVMRP60 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.600120 8 6.325.000 4.508.040 5.160.000 4.060.660 3.995.000 3.462.820 2.830.000 3.005.000360 3 3.829.500 2.904.040 3.330.000 2.748.560 2.830.500 2.593.080 2.164.500 2.143.260660 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.600960 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.6201260 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.3401660 1,04 2.164.500 2.515.940 1.831.500 2.204.980 1.498.500 1.894.020 999.000 1.583.060Pela tabela acima (tabela 1), gera-se o ganho proporcional (figura 10) doMulticast sobre o Unicast pelo tráfego total da rede em relação ao número de usuários equantidade média de nós intermediários:350%300%250%200%12 usuários10 usuários8 usuários6 usuáriosGanho150%100%50%0%-50%-100%15,5 8 3 1,86364 1,4375 1,21429 1,04217Distância média entre nósFigura 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 ototal de dados enviados pelo servidor.Tabela 2. Utilização do servidor em relação às conexões e número de usuários12 usuários 10 usuários 8 usuários 6 usuáriosConexões HOP Unicast DVMRP Unicast DVMRP Unicast DVMRP Unicast DVMRP60 15,5 1.998.000 333.000 1.665.000 333.000 1.332.000 333.000 999.000 333.000120 8 1.998.000 525.000 1.665.000 525.000 1.332.000 525.000 999.000 525.000360 3 1.998.000 653.000 1.665.000 653.000 1.332.000 653.000 999.000 512.000660 1,863636 1.998.000 1.030.000 1.665.000 1.030.000 1.332.000 881.500 999.000 733.000960 1,4375 1.998.000 1.383.000 1.665.000 1.077.500 1.332.000 920.500 999.000 920.5001260 1,214286 1.998.000 1.802.500 1.665.000 1.645.500 1.332.000 1.331.500 999.000 1.026.0001660 1,042169 1.998.000 2.249.500 1.665.000 1.935.500 1.332.000 1.621.500 999.000 1.464.500Pela tabela acima (tabela 2), novamente é demonstrado o ganho do Multicast emrelação ao Unicast (figura 11):600%500%400%12 usuários10 usuários8 usuários6 usuáriosGanho300%200%100%0%-100%15,5 8 3 1,86364 1,4375 1,21429 1,04217Distância média entre nósFigura 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 seudesempenho reduzido, tanto no aspecto geral da rede, quanto na taxa de envio doservidor (dados + controle), devido ao esforço (overhead) adicional de gerenciamento.7. ConclusõesNeste artigo foram apresentadas algumas características de comportamento deprotocolos Multicast em redes altamente interconectadas. Demonstrou-se comsimulações que nestas redes a banda total de rede usada pelo Multicast pode ser maiordo que usada, nas mesmas condições, por múltiplas conexões Unicast. Isto se deve aoaumento 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 emredes 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çãoentre múltiplas conexões Unicast e protocolos Multicast, mas sim um levantamento dasdificuldades nos quais os protocolos Multicast apresentam em casos específicos eextremos.Trabalhos futuros estenderão também as análises de piores casos em Multicastpara redes dinâmicas, utilizando protocolos Multicast para redes ad-hoc, no quallevantar-se-á novas características de desempenhos em casos extremos.8. ReferênciasDeering, S., Estrin, D., Farinacci, D., Jacobson, D., Liu, C. e Wei, L., “The PIMarchitecture for wide-area multicast routing”, IEEE/ACM Transactions onNetworking, Abril, 1996.Hung, Q. Lu, C. e Roman, G., “Conference On Embedded Networked Sensor Systemsarchive”, In Proceedings of the 1st international conference on Embedded networkedsensor 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 Studyof 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 multihopwireless 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 forUnicast 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 andUnicast Real-Time Video Streaming Over Wireless LANs”, In IEEE Transactions onCircuits 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 SourceandLocalized Recovery to Achieve Reliable Multicast in Multi-Hop Ad HocNetworks”, 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 1997RFC: RFC 3973: Protocol Independent Multicast - Dense Mode (PIM-DM): ProtocolSpecification (Revised). Janeiro, 2005.Viswanath, K., Obraczka, K., Tsudik, G., “Exploring Mesh- and Tree Based MulticastRouting Protocols for MANETs”, Transaction of Mobile Computing (TMC 2004),2004.


Viswanath, V., e Obraczka, K., “Interoperability of Multicast Routing Protocols inWireless Ad hoc networks”, In Journal of Wireless Communications and MobileComputing, 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 overWireless 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 MobileNetworks e Applications, v. 7, Issue 6, pp. 429-439, Dezembro, 2002.


Estratégias de Escalonamento em um Ambiente de Job-shopGilberto Irajá Müller 1 , Arthur Tórgo Gómez 11 Universidade do Vale do Rio dos Sinos – UNISINOSPIPCA - Programa Interdisciplinar de Pós-Graduação em Computação AplicadaAv. Unisinos, 950 – Bairro Cristo Rei – CEP 93022-000 – São Leopoldo – RSirajamuller@terra.com.br, breno@unisinos.brResumo. Neste trabalho são apresentadas estratégias de escalonamento através de um modeloaplicado ao Job-shop Scheduling Problem que considera o tempo total de produção (makespan),o tempo total de atraso e o tempo total de paradas. O modelo é composto por: (i) uma funçãoobjetivo que reflete as estratégias de otimização, e de (ii) uma arquitetura que está divididaem cinco fases. O modelo utilizou o algoritmo Busca Tabu que, através de duas estratégiasde geração de vizinhanças, busca a otimização da função objetivo. A arquitetura do modelobaseia-se na Tecnologia de Grupo, nas Regras de Despacho e no Algoritmo Busca Tabu paratratar os Problemas de Seleção de Partes e do Escalonamento. Os resultados e análises sãoapresentados ao final deste trabalho.1. IntroduçãoO Job-shop Scheduling Problem (JSP) pode ser descrito por: n jobs, onde cada job é composto por joperações que devem ser processadas em m máquinas. Cada operação j utiliza uma das m máquinas comum tempo de processamento fixo. Cada máquina processa uma operação por vez sendo que não ocorreinterrupção. As operações devem ser processadas em ordem através de um roteiro pré-estabelecido. Oproblema consiste em encontrar um escalonamento que obedeça as precedências de operações nas máquinastal que minimize o makespan C max dado o processamento do último job.Seja J = {0, 1, ..., n, n + 1} o conjunto de operações a serem escalonadas e M = {1, ..., m}o conjunto de máquinas. As operações 0 e n + 1 não possuem duração e representam o início e fim daoperação. Para as operações inter-relacionadas possuem dois tipos de restrições: (i) a de precedência emque cada operação j será escalonada depois de todas as operações predecessoras P j forem finalizadas e (ii) aoperação somente será escalonada se a máquina estiver ociosa. Representaremos o tempo de processamentofixo por d j , o tempo final do processamento da operação j por F j . Para o escalonamento, utilizaremosum vetor para os tempos de finalização (F 1 , F m , ..., F m+1 ) e A(t) para o conjunto de operações a seremprocessadas no tempo t; r j,m = 1 se a operação j é processada na máquina m e r j,m = 0, caso contrário. Omodelo do JSP pode ser definido por [Gonçalves et al. 2005]:Minimize F n+1 (C max ) (1)F k ≤ F j − d j , j = 1, ..., n + 1; k ∈ P j , (2)∑j∈A(t)r j,m ≤ 1, m ∈ M; t ≥ 0, (3)F j ≥ 0, j = 1, ..., n + 1. (4)A função objetivo (1) busca minimizar o tempo total de produção (makespan). A restrição (2)assegura a precedência das relações entre operações e a restrição (3) assegura o processamento de umaoperação por vez. Por fim, a restrição (4) garante a não-negatividade. Dessa forma, o artigo possui a seguinteorganização: na Seção 2, são apresentados os problemas abordados para o JSP e o método utilizado;na Seção 3, são apresentadas as características da meta-heurística Busca Tabu; na Seção 4, é conceituadoo modelo proposto e, por fim, na Seção 5 são apresentados os resultados da validação, as estratégias deescalonamento e as conclusões finais.


2. Problemas AbordadosNesta seção são apresentados dois problemas que são abordados na geração do modelo proposto aplicadoao JSP. O primeiro problema está relacionado com a fase pré-operacional e o segundo é abordado na faseoperacional[Stecke 1986], são eles:• seleção de partes: existem diversos métodos para a geração das Famílias de Partes (FP), sendodestacados a Inspeção Visual, Classificação por Codificação e Análise por Fluxo de Produção(formulação matricial, programação matemática e particionamento de grafos) [Jha 1991]. As FPssão formadas através do agrupamento das partes, baseada nas similaridades, tais como: formageométrica, processo, similaridade por um mesmo conjunto de ferramentas entre outros e é consideradoum problema NP-Completo [Jha 1991]. O modelo proposto utilizou o método de Análisepor Fluxo de Produção proposto por Kusiak [Kusiak and Chow 1987] denominado de ClusterIdentification;• escalonamento de partes: o escalonamento das partes num JSP é um problema de difícil solução,ou seja, NP-Hard [Garey et al. 1976]. O objetivo está em seqüenciar os jobs em um conjunto demáquinas através de rotas pré-definidas em função do tempo [Blazewicz et al. 1996]. Inúmerosmétodos de otimização foram propostos para a solução do JSP [Zoghby et al. 2004], sendo destacadoos métodos de otimização e os métodos aproximativos. Para os métodos de otimização sãocitadas a Programação Inteira, a Relaxação Lagrangeana, as Técnicas de Surrogate e o Branchand Bound [Balas et al. 1979]. Nos métodos aproximativos são destacados os algoritmos iterativosBusca Tabu, as Redes Neurais, os Algoritmos Genéticos, a Têmpera Simulada e o GRASP[Blazewicz et al. 1996], [Glover and Laguna 1997] e [Gonçalves et al. 2005]. Para resolver o problemado escalonamento de partes foi utilizado o algoritmo Busca Tabu em virtude da complexidadedo problema e dos diversos trabalhos relacionados.3. Busca TabuA meta-heurística Busca Tabu (BT) teve origem a partir de uma solução para problemas de programaçãointeira; posteriormente foi dada uma descrição do método para uso geral em problemas de otimizaçãocombinatória [Adams et al. 1988].Basicamente, a BT, que foi projetada para encontrar boas aproximações para a solução ótimaglobal de qualquer problema de otimização, possui três princípios fundamentais: (i) uso de uma estruturade dados (lista) para guardar o histórico da evolução do processo de busca, (ii) uso de um mecanismo decontrole para fazer um balanceamento entre a aceitação ou não de uma nova configuração, com base nasinformações registradas na lista tabu referentes às restrições e aspirações desejadas e (iii) incorporação deprocedimentos que alternam as estratégias de diversificação e intensificação [Glover and Laguna 1997].Para a utilização da BT, é fundamental a definição da função objetivo f do problema em questão.Após esta definição, é gerada uma solução inicial viável independente (Regra de Despacho). Sendo que,para a geração da solução inicial, é obrigatório que esta faça parte do conjunto de soluções possíveis doespaço amostral.4. ModeloO modelo proposto apresenta uma formulação que é a função objetivo para a otimização do escalonamentodas partes e de uma arquitetura baseada no modelo de planejamento de produção para o Sistema de ManufaturaFlexível (SMF) proposto por Stecke [Stecke 1986].4.1. FormulaçãoA formulação utilizada para a otimização do escalonamento das partes é mostrada a seguir, onde: m =número de máquinas, n = número de partes, i = índice para a parte, k = índice para a máquina, De i = datade entrega da parte e Dsp ik = data da saída de produção. Onde:Minimizar f(e, p) = p 1.makespan(e, p) + p 2.atraso(e, p) + p 3.parada(e, p) (5)


makespan(e, p) =atraso(e, p) =mXmXk=1 i=1parada(e, p) =nXk=1 i=1nXmakespan ik , tal que makespan ik > 0 (6)(Dsp ik − De i), tal que (Dsp ik − De i) > 0 (7)mXnXk=1 i=1parada ik , tal que parada ik > 0 (8)p 1, p 2, p 3 ≥ 0. (9)A função objetivo (5), que busca a minimização, é definida pela variável “e” (escalonamento), querepresenta a dimensão temporal e a variável “p” (Famílias de Partes), representa a dimensão física para omodelo proposto. É formada por três variáveis de decisão que refletem estratégias de otimização. A variávelde decisão makespan(e,p) representa o tempo total de produção (6), ou seja, é o tempo inicial do primeirojob processado em produção até o tempo final do último job processado. A variável de decisão atraso(e, p)representa o tempo total de atraso (7). O tempo total de paradas de produção é representada pela variávelde decisão parada(e,p) e significa o tempo entre dois lotes de produção (8). Por fim, a restrição (9) asseguraa não-negatividade das variáveis. Conforme apresentado na Seção 2, sobre o Problema do Escalonamento,é apresentado abaixo o algoritmo BT modificado que utiliza a função objetivo supracitada.while (niter - melhiter < nbmax) dofor “m” máquina dof ′ ← fmelhor;niter ← melhiter + 1;p ← p ∗ ;Gerar V ∗e de soluções (e, p ∗ ) i em N e(e, p ∗ ) ou f((e, p ∗ ) i) < A(f(e, p ∗ ));Atualizar Lista T abu L e A(z);if f(e ′ , p ∗ ) < fmelhor thenfmelhor ← f(e ′ , p ∗ );endifGerar V p ∗ de soluções (e, p) i em N p(e, p) ou f((e, p) i) < A(f(e, p));Atualizar Lista T abu L e A(z);if f(e ′ , p ′ ) < fmelhor thenfmelhor ← f(e ′ , p ′ );endifp ← p ′ ;e ← e ′ ;endforif fmelhor < f ′ thenmelhiter ← niter;endifendwAlgoritmo 1: Algoritmo BT modificadoA cada iteração um ótimo local é escolhido e a partir dele é gerada uma nova vizinhança. Paraevitar ciclos e mínimos locais é implementada uma lista de movimentos reversos proibidos chamada de listatabu (L). Caso a iteração obtenha uma melhora na função f, utiliza-se a função critério de aspiração A,que admite o movimento até então proibido. Para as condições de parada do algoritmo, pode-se utilizar umnúmero máximo de iterações (nbmax) sem que ocorra melhoria na função f ou executar até que alcance ovalor mínimo.4.2. ArquiteturaA arquitetura para a Seleção e Escalonamento de Partes está dividida em cinco fases de aplicação conformeé apresentado na Figura 1.


Figura 1. Arquitetura do ModeloA primeira fase é responsável por obter a demanda de produção através das informações contidasno banco de dados, sendo recuperadas as informações técnicas da parte e a data de entrega. Na segunda faseocorre a geração da matriz parte versus máquina aplicando o algoritmo de identificação de agrupamentos.Na terceira fase, é utilizado a Regra de Despacho aplicando o Cluster Identification para a geração doescalonamento inicial. A partir do escalonamento inicial, é possível realizar a quarta fase que consiste naaplicação do algoritmo BT para a otimização do escalonamento. Após a geração do escalonamento finalé gravado este num plano de produção, possibilitando assim observar seus históricos e compará-los com oescalonamento efetivo.5. ResultadosA etapa de validação do modelo proposto é realizada através da comparação com trabalhos clássicos quepropõem a solução do JSP [Blazewicz et al. 1996][Jain and Meeran 1998][Zoghby et al. 2004]. Para testaro desempenho da arquitetura são utilizadas diversas instâncias do JSP de modo a realizar a validação em diversosambientes (número de partes x número de máquinas). Para a validação, foram utilizadas as instânciaspropostas por Muth [Muth and Thompson 1963] denominada de FT06, FT10 e FT20, e as instâncias propostaspor Lawrence [Lawrence 1984] denominadas de LA01, LA06, LA11, LA16, L21, LA29 e LA40.5.1. Instância genéricaA instância genérica para o problema do JSP possui as seguintes definições: (i) a primeira linha define adimensão da matriz (n x m), onde o “n” representa o número de partes para o problema em questão e o“m” representa o número de máquinas, (ii) as demais linhas representam a rota para cada parte, onde: avariável “M” ilustra a máquina e a variável “T” ilustra o tempo de processamento, (iii) as colunas ímparesrepresentam o número da máquina que a parte deverá ser processada e (iv) as colunas pares representam otempo de processamento da parte em cada máquina. A Figura 2 ilustra a instância.Figura 2. Estrutura Genérica de uma Instância do JSP5.2. Trabalhos selecionadosAtravés dos trabalhos que propõem a resolução do JSP [Jain and Meeran 1998][Zoghby et al. 2004], foramselecionados alguns autores em função do tipo de algoritmo utilizado e da sua importância na evolução doestado da arte. A Tabela 1 mostra os autores selecionados e o algoritmo utilizado.


Tabela 1. Autores selecionados para a validação do modeloAutor Algoritmo AnoStorer [Storer et al. 1992] Busca no espaço 1992Aarts [Aarts et al. 1994] Algoritmos genéticos 1994Dorndorf [Dorndorf and Pesch 1995] Algoritmos genéticos 1995Nowicki [Nowicki and Smutnicki 1996] Busca Tabu 1996Wang [Wang and Zheng 2001] Genético híbrido e Têmpera simulada 2001Aiex [Aiex et al. 2003] GRASP 2003Gonçalves [Gonçalves et al. 2005] Algoritmos genéticos híbridos 20055.3. ConfiguraçãoPara a configuração do algoritmo BT modificado foi atribuído o valor de 100 para o número máximo deiterações sem obter melhora na função objetivo (nbmax) e, para o tamanho da lista tabu, foi atribuído 15.Em virtude dos autores selecionados utilizarem o makespan para os seus experimentos, os pesos (p 1 , p 2 ep 3 ) para a função objetivo foram fixados em 100, 1 e 1, respectivamente, de modo a privilegiar a variávelde decisão makespan. É importante ressaltar que o modelo proposto, além de otimizar o makespan, possuiuma arquitetura que tem como objetivo o gerenciamento entre as datas de entrega (minimização do atraso)e a produtividade (minimização das paradas de produção).As demais abordagens supracitadas otimizam somente o makespan, desconsiderando as datas deentrega e a produtividade do sistema. Como as instâncias não possuem as datas de entrega para a parte, e omodelo proposto às utiliza como estratégia de otimização, foram fixadas todas as partes com a mesma datade entrega.O modelo foi implementado em Delphi 7 e seus experimentos executados em um hardware AthlonXP 2500+ 512 RAM com sistema operacional Windows XP Pro.5.4. ValidaçãoOs resultados da validação são mostrados na Tabela 2. Nela é apresentada a instância do problema, adimensão do problema (número de partes x número de máquinas), a solução ótima conhecida (SOC), asolução obtida pelo modelo proposto (MP) e a solução dos autores selecionados.Tabela 2. Estratégia que privilegia a produtividadeInstância NxM SOC MP Gonçalves 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 1258Através da Tabela 2 é possível fazer um comparativo entre o modelo proposto e a solução ótima conhecida.Nota-se que o makespan com a maior diferença em relação à SOC diferencia-se em 7 unidades detempo (LA40), equivalendo a uma diferença de 0,57%. De maneira a validar o modelo, os resultados esperadosatingiram o objetivo, ou seja, em muitos casos alcançando a SOC e, em outros casos, aproximando-se.As instâncias que tiveram diferenças em relação à SOC, sofreram influência da função objetivo domodelo proposto. Ao avaliar a função objetivo, considerou-se para este problema do makespan, um pesosignificativamente maior para a variável de decisão makespan do que as demais variáveis, direcionandoassim a BT para a otimização do makespan.Observa-se também que, após a validação, além de contemplar o makespan, o modelo proposto


ealizou o gerenciamento entre as datas de entrega (atraso) e a produtividade (velocidade de produção) dosistema de produção, mesmo privilegiando a variável de decisão makespan.A capacidade do modelo em gerenciar estratégias diferentes de escalonamento e, não somente omakespan, ocorre em virtude das variáveis de decisão que compõem a função objetivo e que abordam estratégiasde escalonamento, tais como: (i) makespan, (ii) tempo total em atraso e (iii) tempo total paradoem produção. A seguir são apresentadas algumas estratégias na utilização do modelo proposto e que nãosão consideradas nas demais abordagens.5.5. Estratégia que privilegia a otimização das paradas de produçãoDado o privilégio da variável de decisão parada (peso p 3 =100), objetiva-se a produtividade e, conseqüentemente,a velocidade de produção. A Tabela 3 apresenta o resultado dos experimentos.Tabela 3. Estratégia que privilegia a produtividadeInstância SOC MP Diferença % 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 4Através dos experimentos que visam a otimização da produtividade, presencia-se um conflito emrelação às datas de entrega (atraso) e as paradas de produção, ou seja, quanto menor é o tempo de paradasde produção (maior magnitude), menor é a magnitude da variável de decisão atraso no direcionamento daBT. Constatou-se que estas variáveis são independentes e, ao privilegiar uma, causa influência negativa naoutra. Este comportamento ocorre, pois a variável de decisão atraso perde a influência na função objetivo,privilegiando assim a escolha de movimento na vizinhança (algoritmo BT) em função da variável de decisãoparada e o fato também destas variáveis serem independentes.Outro aspecto importante neste experimento consiste na constatação da dependência de duasvariáveis de decisão, ou seja, ao reduzir o tempo parado, ocorreu influência na redução do makespan. A estratégiaque privilegia a redução do tempo parado consistiu com os mesmos valores obtidos pelo makespancalculado na etapa de validação do modelo.5.6. Estratégia que privilegia a otimização das datas de entregaDado o privilégio da variável de decisão atraso (peso p 2 =100), objetiva-se a entrega pontual das partes,desconsiderando assim as demais estratégias de otimização.Tabela 4. Estratégia que privilegia a entrega pontualInstância SOC MP Diferença % 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. Porém, omakespan sofreu aumento significativo, conseqüência do aumento das paradas de produção. Dessa forma,constatou-se o conflito existente entre respeitar as datas de entrega e manter a produtividade.5.7. Estratégia não-tendenciosaA solução não-tendenciosa é aquela em que o peso não privilegie nenhuma das variáveis de decisão dafunção objetivo. É obtida através da proporção das variáveis de decisão dada a execução de 100 experimentosvariando os pesos (p 1 , p 2 , p 3 ), seguindo uma distribuição normal com intervalo (0, 100].Com a estratégia não-tendenciosa, ocorreu a redução do conflito entre as variáveis de decisãomakespan e parada, ou seja, a relação entre a produtividade e as datas de entrega. A Tabela 5 ilustra osresultados obtidos.Tabela 5. Estratégia não-tendenciosaInstância SOC MP Diferença % 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 2Esta estratégia pode ser utilizada como política de escalonamento, dado que obteve uma relaçãoconsistente entre as variáveis de decisão makespan e atraso, sendo observado que o makespan aproximou-seda SOC e poucas partes foram entregues em atraso. Ao ser utilizada uma estratégia não-tendenciosa, foipossível verificar a redução do makespan e não houveram diferenças significativas em relação ao númerode partes em atraso ao ser comparado com a estratégia que privilegia a entrega pontual.5.8. ConclusõesEste trabalho teve como objetivo apresentar estratégias de escalonamento através de um modelo aplicadoao Escalonamento do Job-shop. O modelo implementado está baseado numa função objetivo que reflete,através das variáveis de decisão e seus pesos respectivos, estratégias de escalonamento. A arquitetura domodelo é responsável por tratar os problemas de Seleção e de Escalonamento das Partes. Através dasestratégias de escalonamento, foi possível demonstrar a flexibilidade e versatilidade do modelo. Foramutilizadas na validação, diversas instâncias para o problema do Job-shop e conclui-se que o modelo propostopode ser considerado mais uma abordagem para o escalonamento de produção, devido a sua flexibilidadeem trabalhar com algumas estratégias de escalonamento e em virtude das outras abordagens citadas na etapade validação não gerenciarem o conflito entre as datas de entrega (atraso) e a produtividade do sistema deprodução (velocidade de produção). Como extensão futura deste trabalho, sugere-se a validação do modeloatravés de instâncias de grande escala, o aprimoramento dostodos de geração e escolha de vizinhança e,por fim, propor instâncias para o JSP que considerem as datas de entrega e paradas de produção dado queas instâncias utilizadas foram adaptadas para a validação do modelo.ReferênciasAarts, 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.Gonçalves, 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 ManufacturingSystems, 6(2):117–124.Lawrence, S. (1984). Resource constrained project scheduling: an experimental investigation of heuristicscheduling 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 programação paralela em otimização combinatória. EUFC, page250.Wang, L. and Zheng, D. (2001). An effective hybrid optimization strategy for job-shop scheduling problems.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 umObservatório AstronômicoMaiara Heil Cancian, Cesar Albenes Zeferino, Rafael Luiz Cancian, Roberto Miguel TorresCentro 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.brResumo. Sistemas de informação baseados na Internet estão cada vez maispresentes nos mais diferentes domínios. Uma das áreas de grande aplicaçãoconsiste no acesso remoto a infra-estruturas de alto custo que podem sercompartilhadas através da rede. Neste contexto, este artigo apresenta odesenvolvimento de um sistema Web que será aplicado no acesso remoto a umobservatório astronômico a fim de ampliar o acesso a essa infra-estrutura quepossui alto custo de instalação e manutenção. O sistema permite que osusuários agendem a aquisição de imagens astronômicas através de umainterface Web e recebam essas imagens via e-mail, as quais são capturadasautomaticamente pelo telescópio do observatório.1. IntroduçãoNa última década têm sido desenvolvidos diversos projetos de telescópios virtuais etelescópios remotos que visam permitir o compartilhamento do acesso a imagensastronô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 deimagens já obtidas por telescópios, enquanto que, em telescópios remotos, é oferecida apossibilidade 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 oapoio da Petrobrás, já foi adquirida parte dos equipamentos necessários.O presente trabalho desenvolveu um sistema Web para submissão, gerenciamento eatendimento de requisições de utilização remota do observatório. Esse sistema,doravante denominado Astra, possui uma interface Web, um módulo de cadastro dosusuários e um núcleo responsável pelo escalonamento e atendimento das requisições deacesso ao observatório. Tal núcleo utiliza diferentes critérios de escalonamento a fim deotimizar 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 pesquisadoresda área de astronomia, mas, especialmente, de jovens em fase escolar, estimulando ointeresse 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 aarquitetura do sistema Astra, enquanto que a Seção 4 descreve a sua funcionalidade. ASeção 5 apresenta aspectos relacionados à implementação do sistema e, concluindo, aSeção 6 apresenta as considerações finais.2. Trabalhos RelacionadosAtualmente, existem diversos observatórios remotos e virtuais disponíveis com acessovia Internet. O AST/RO é um telescópio de 1,7 metros de diâmetro em operação emAmundsen-Scott, no pólo sul, desde 1995, e é gerenciado pelo Center for AstrophysicalResourse in Antarctica (CARA). Todo o sistema AST/RO é altamente automatizadopara reduzir ao mínimo a necessidade da intervenção humana e possibilitar suautilizaçã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 estruturae 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çãoastronô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 quevariam 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 Centrode Ciências Matemáticas e da Natureza (CCMN) da Universidade Federal do Rio deJaneiro (UFRJ), que, em 2004, adquiriu, juntamente com outras cinco instituiçõesastronômicas, um conjunto de equipamentos necessários para montagem de umobservatório remoto (telescópio, câmera CCD, conjunto de filtros, etc.). Com a chegadado equipamento, foi feito o projeto da cúpula controlada por computador e hoje esseobservatório já pode ser utilizado. Porém, a completa operação remota ainda não foiimplementada pela ausência de uma interface adequada, impossibilitando que oobservatório seja controlado remotamente.Dos trabalhos descritos acima, nenhum deles contempla simultaneamente as duasprincipais características definidas para o observatório da UNIVALI: acesso remotogratuito pela Internet e sem restrição ao tipo de público-alvo.3. Arquitetura do Sistema AstraA Figura 1 apresenta a arquitetura básica do observatório remoto a ser implementado naUNIVALI (a fotografia é apenas ilustrativa). Através da Internet, os usuários tem acessoao observatório por meio do sistema Astra, em execução em um microcomputadorinstalado no local do observatório. O observatório contará ainda com um sistemacomputacional 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á umasérie de sensores para obtenção do estado das variáveis meteorológicas.


EstaçãoMeteorológicaInternetSistemaEmbarcado‘Figura 1. Arquitetura básica do observatório remotoA Figura 2 mostra uma estrutura em camadas do observatório remoto, com destaque aosmódulos que constituem o sistema Astra (em cinza), desenvolvido em um trabalho deconclusão de curso [Heil, 2005]. Os usuários acessam o sistema através de umainterface Web. O núcleo do sistema é constituído pelos módulos: Gerenciador,Escalonador, Executor, Astrônomo, Temporizador e Meteorologista (cujasfuncionalidades são descritas logo a seguir).UsuárioInterface WebGerenciadorEscalonadorSistemaAstraExecutor Astrônomo Temporizador MeteorologistaDriver do Sistema EmbarcadoInterface da EstaçãoMeteorológicaSistema EmbarcadoEstação MeteorológicaObservatórioFigura 2. Arquitetura do observatório remoto e do sistema AstraA Figura 3 mostra um diagrama de colaboração que ilustra as inter-relações entre osmódulos componentes do sistema Astra, as quais são descritas após a figura.


Interface Web1Gerenciador8MeteorologistaTemporizador452Escalonador367ExecutorAstrônomoFigura 3. Diagrama de colaboração do sistema Astra• Ligação 1: a Interface Web envia os parâmetros da requisição aoGerenciador;• Ligação 2: o Gerenciador invoca o Escalonador para executar oescalonamento da requisição;• Ligação 3: o Escalonador invoca o Astrônomo para que ele verifique aconsistê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 paradespertar o Escalonador na data e na hora de atendimento da próximarequisição;• Ligação 5: o Temporizador invoca o Escalonador quando chegar a data ehora da requisição a ser atendida;• Ligação 6: caso o Escalonador tenha sido despertado para atender umarequisição, ele invoca o Executor, módulo responsável pelo envio decomandos de acionamento do observatório ao driver do sistema embarcado;• Ligação 7: o Executor, ao ser ativado, invoca o Meteorologista para verificarse as condições meteorológicas estão adequadas para a realização daobservação;• Ligação 8: o Gerenciador invoca o Meteorologista quando precisar deinformações meteorológica para alimentar o banco de dados ou quando umusuário requisitar informações meteorológicas atualizadas; eUma vez atendida a requisição, o Gerenciador envia uma mensagem de resposta aousuário, contendo a(s) imagem(ns) associada(s) à requisição. Outros tipos de mensagemtambém podem ser enviadas, como, por exemplo, para informar o não agendamento deuma requisição ou o re-agendamento de uma requisição previamente escalonada, entreoutras.


4. Funcionalidade do Sistema Astra4.1 Submissão e Agendamento de RequisiçõesO sistema possui uma interface Web com um formulário eletrônico com campos deinformações que deverão ser preenchidos pela pessoa/instituição que desejar utilizar oobservatório. O usuário solicitará a submissão das informações desse formulário, queserão armazenadas em um banco de dados e marcadas como “cadastro pendente”. Nomomento adequado, o administrador avaliará os cadastros pendentes e decidirá pela suaaprovação ou rejeição. No primeiro caso, ele irá marcar o cadastro como “ativo” eatribuirá uma prioridade ao usuário, enquanto que, no segundo, ele irá excluir asinformações do banco de dados. Após, o administrador irá notificar o usuário, o qualpoderá acessar o sistema se o seu cadastro tiver sido aprovado.Figura 4. Tela de cadastro de usuárioPara a submissão de requisições, o usuário deve efetuar o login no sistema. Uma vezautenticado, ele deverá preencher um formulário eletrônico com informações da suarequisição (nome e coordenadas do astro, data e hora da observação, filtro, etc.).


Figura 5. Tela de cadastro de requisição astronômicaApós a submissão do formulário, o sistema faz a validação desses campos. Caso todosos campos satisfaçam as condições impostas, a requisição é escalonada e o usuáriorecebe uma mensagem com a data e o horário nos quais a requisição será atendida. Casoexistam problemas de validação, o sistema rejeita a requisição e o usuário recebe umamensagem com o motivo dessa rejeição. As validações feitas pelo sistema no momentoda 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 assuas coordenadas.Se na data e hora especificadas em uma requisição não houver nenhum outroagendamento, a requisição é agendada. Porém, se já houver uma requisição maisprioritária, a requisição é negada. Caso, na data e hora especificadas, houver uma


equisição com prioridade mais baixa, a requisição atual é agendada, e a menosprioritária é re-agendada e sua prioridade incrementada. Porém, se houver umarequisiçã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çõesAs requisições agendadas são escalonadas e a execução delas é disparada pelo móduloTemporizador. Durante a execução do atendimento de uma requisição, as seguintesfunções são realizadas:• Verificação das condições meteorológicas: O módulo Meteorologista faz averificação da umidade, da velocidade do vento e das temperaturas interna eexterna do observatório através de sensores da estação meteorológica oumesmo de páginas Web com informações meteorológicas. Se os valoresmedidos estiverem dentro de limites definidos, dá-se continuidade aoatendimento, caso contrário, a requisição é re-agendada e o usuárionotificado;• Envio do comando de abertura da cúpula: Se as condições meteorológicasestiverem 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 seratendida no dia, o telescópio é ligado e faz uma calibração para identificar ascoordenadas 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 Executorencaminha as coordenadas correntes do astro da requisição que é atendida aodriver do sistema embarcado. Este então aciona os mecanismos deposicionamento do telescópio;• Captura da imagem: O módulo Executor envia ao driver um comando paraque 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âmeraCCD e o módulo Gerenciador gera uma mensagem eletrônica que é enviadaao(s) usuário(s) que submeteu(ram) a requisição atendida.5. ImplementaçãoO sistema foi implementado utilizando as seguintes tecnologias/linguagens: (i) SistemaOperacional 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 SistemaO sistema desenvolvido possui dois processos independentes. O primeiro consiste deum gerador de interface Web para interação com os usuários remotos. O segundoconsiste 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 é feitaatravés de sockets.O acesso ao sistema dá-se através da internet, digitando uma URL (Universal ResourceLocator) como, por exemplo, http://www.observatorio.univali.br/cgibin/astraWeb.exe/index.Através de mecanismos de roteamento da internet, a primeiraparte 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 noport 80 (padrão do protocolo HTTP). O servidor Web (Apache, por exemplo) recebe asolicitação e invoca o programa especificado na segunda parte da URL (/cgibin/astraWeb.exe).Este programa, denominado aqui de AstraWeb, tem sua execuçãoiniciada a cada nova solicitação HTTP e recebe a última parte da URL, denominadacaminho ou path (/index). Com base nesse caminho, esse programa deve tomar as açõesnecessárias e gerar a resposta adequada à solicitação.Como o programa invocado pelo servidor Web terá múltiplas instâncias em execução, esendo isso indesejável ao núcleo do sistema Astra, o programa AstraWeb é apenas uminterceptador de solicitações Web, e sempre que necessário comunica-se com outroprocesso 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 únicainstância do AstraKernel. Outro motivo para ter-se dois programas independentes é queo núcleo “acorda” em instantes específicos para executar as requisições já cadastradasou para armazenar as condições meteorológicas atuais, e não pode depender daexistência de solicitações HTTP para executar.Embora o sistema deva executar de maneira independente das solicitações HTTP, eletambém deve ser capaz de atendê-las rapidamente, uma vez que há um timeout oudeadline 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 dedesempenho. Assim, optou-se pela separação do atendimento às solicitações Web egeração das páginas HTML de resposta (responsabilidade do AstraWeb) doprocessamento 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 (normalmentec:\apache\cgi-bin) e é invocado a cada nova solicitação HTTP. Basicamente, eletransmite a solicitação via socket TCP para o núcleo do Astra que realiza o tratamento eenvia 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. Paraevitar a verificação periódica de requisições TCP, o núcleo do Astra cria um socketservidor (port 5000) que é ativado apenas quando há uma nova solicitação. Se houvermuitos usuários conectados à internet gerando solicitações ao sistema, pode serinaceitável haver um único núcleo atendendo tais requisições. Portanto, assim como emimplementações normais de socket servidores, cada conexão aceita pelo núcleo doAstra cria uma nova thread específica para atendê-la.


5.2 Algoritmos Usados no Escalonamento de RequisiçõesNo sistema Astra, o agendamento das requisições de observações astronômicas faz usode características de diversos algoritmos de escalonamento tipicamente adotados emsistemas computacionais [Silberchatz, 2000] e [Cancian, 2000]. Basicamente, ele temque ser capaz de lidar com múltiplas requisições e agendar corretamente a execuçãodessas requisições com base em critérios específicos. Em especial, destaca-se que cadausuá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árioscom 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 paraatendimento (ex. eclipse solar), é usado o algoritmo EDF (Earliest Deadline First).Também são usados algoritmos específicos para minimizar os movimentos dotelescópio. Como o telescópio movimenta-se de modo semelhante a um cabeçote deleitura/gravação de um acionador de disco rígido, em algum momento que o telescópioestiver fazendo um trajeto para obter uma imagem, ele poderá executar outra requisiçãoque esteja em seu caminho. Esse gerenciamento utiliza características dos algoritmosSSTF (Smallest Seek Time First) e SCAN.6. Testes e ValidaçõesOs 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ísicado observatório também foi simulada, gerando mensagens para informar oadministrador quando a cúpula estivesse aberta ou fechada. Desta forma, a requisiçãoera 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 dotelescó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 deexecução do AstraWeb a partir de um browser e a geração de uma página HTML deresposta; e (ii) comunicação via socket TCP entre os programas AstraWeb e oAstraKernel.Para a realização do primeiro teste, iniciou-se o servidor Apache na máquina quecontinha a aplicação AstraWeb. Com o servidor executando, invocou-se a aplicaçãoatravés de navegadores Internet Explorer, tanto da própria máquina quanto de outrasmáquinas conectadas à internet. Em todos os casos obtinha-se, na janela do navegadorutilizado, as páginas HTML geradas pelo AstraWeb. A Figura 7 apresenta uma parte datela do sistema onde pode-se ver o resultado de uma solicitação no navegador, comdestaque à URL digitada.Figura 7. Acesso ao sistema Astra


Em relação ao segundo teste, foram criadas duas aplicação (cliente e servidor) que secomunicam 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 servidorApós todos os testes comprovando o funcionando isolado de seus módulos, foi realizadaa integração do sistema, que mostrou-se totalmente funcional. Assim, o Astra já podeser utilizado para gerenciar requisições remotas a um observatório e comandar osdispositivos de automação desse observatório para que seu telescópio capture asimagens requisitadas. Para sua disponibilização final, aguarda-se apenas a aquisição dosdemais componentes físicos (cúpula, câmera CCD, sensores, motores, etc) para aconstrução do observatório.7. Considerações FinaisEste artigo apresentou o sistema Astra, que é um sistema Web para gerenciamento deacesso remoto a um observatório astronômico. Foram abordados os principais aspectosdos 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 remotaem tempo real do observatório, tenham sido detectados e devem ser implementados nofuturo.O sistema Astra faz parte de um projeto maior, que visa a construção de umobservatório que possa operar autonomamente. Assim, apesar de concluído, o Astradepende que outros projetos paralelos, como os que implementam o sistema embarcadopara controle da estação meteorológica e da cúpula do observatório sejam tambémconcluídos e que o observatório seja efetivamente construído, para que o sistema sejadisponibilizado.


ReferênciasBoczko, 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 eTempo Real para o Ambiente de Multicomputador CRUX”. 2001. 174 p. Dissertaçãode 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:. Acesso em: 28 de julho de 2005.EOS (2002) “Robotics Observatory Control System: the complete autonomous roboticcontrol system”, Queanbeyan, Electro Optic Systems Pty Limited.Heil, Maiara (2005) “Sistema Web para Gerenciamento de Requisições de umObservatório Remoto”.Mike & Lynn Rice (2005) “New México Skies”. Disponível em:. Acesso em: 28 de julho de 2005.Observatórios Virtuais (2005) “Observatórios Virtuais: Projeto Educacional na área deCiências envolvendo instituições de pesquisa em Astronomia e escolas de ensinomédio e fundamental”. Disponível em: . 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 doObservató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 Aritmética e Números dedelAplicados à CriptografiaVilson Vieira da Silva, Jr. 1 , Claudio Cesar de Sá 1 , Rafael Stubs Parpinelli 1 ,Charles Christian Miers 11 Universidade do Estado de Santa Catarina (Udesc) – Centro de Ciências TecnológicasCampus Universitário Prof. Avelino Marcante s/n – Bairro Bom RetiroCEP 89223-100 – Joinville – SC – Brasilvilson@void.cc, {claudio, parpinelli, charles}@joinville.udesc.brResumo. Através da união do Teorema Fundamental da Aritmética e do conceitoformal de número dedel, proposto pelo mesmo matemático que lhe dánome, busca-se o desenvolvimento de um algorítmo criptográfico e sua posterioranálise. Para isso é criada uma aplicação real, que demonstra os princípiosteóricos nos quais soluções práticas e populares são desenvolvidas, como o algorítmode criptografia para geração de chaves públicas RSA 1 .1. IntroduçãoA criptografia moderna utiliza de diversos métodos para a criação de algorítmos cada vezmais confiáveis na codificação de dados.Em sua maioria, tais métodos estão baseados em propriedades de teoremas matemáticos.Desta forma, propôe-se analisar a aplicação de um destes teoremas, o TeoremaFundamental da Aritmética, que usado como axioma em um conceito formal, criadopelo matemático Kurt Gödel [Hintikka 1999], revela-se como base para algorítmoscriptográficos.Permite-se ainda analisar tal algorítmo na forma de uma aplicação prática, com odesenvolvimento de um software de codificação de dados.O artigo está organizado da seguinte forma: na sessão 2 é apresentado o TeoremaFundamental da Aritmética, a sessão 3 apresenta os números dedel, assim como suadefinição matemática. A sessão 4 une os conceitos dos teoremas apresentados em umaaplicação prática ligada à criptografia e conclui o artigo através de sua análise.2. O Teorema Fundamental da AritméticaO Teorema Fundamental da Aritmética (TFA) [Mollin 1998], inicialmente provado porEuclides 2 enuncia:Para todo número natural n maior que 1, ou este é um número primo, ou podeser escrito como um produto de números primos, de maneira unívoca.1 Iniciais do sobrenome de seus criadores: Ron Rivest, Adi Shamir e Len Adleman2 A prova foi generalizada e tornada correta posteriormente pelo matemático Carl Friederich Gauss


Por exemplo:2100 = 2 2 × 3 1 × 5 2 × 7 1 (1)A ordem dos fatores, pela propriedade comutativa da multiplicação, é irrelevante.O que torna tal teorema interessante é a garantia de obtenção de uma representaçãoúnica para todo e qualquer número natural. Isso abre diversas possibilidades de aplicação,como em criptografia, onde um texto pode ser codificado como uma sequência de númerosprimos.3. Os Números dedelKurt Gödel, em 1931, deu um grande passo para para a evolução da matemática com seuTeorema da Incompletude [Gödel 1931]. Para a prova de tal teorema, Göedel precisou deuma abstração, uma formalização que o possibilitasse trazer ao seu campo de domínio –a teoria dos números [Andrews 1995] – toda e qualquer sistema formal. Desta maneira,poderia “operar” sobre tais sistemas com regras aritméticas, botando-os em prova, analisandosuas características, testando portanto sua completude, o objetivo primordial desua tese.Este propôs então os Números dedel [Hofstadter 1989], um conceito formala partir da teoria dos números.3.1. DefiniçãoOs Números dedel (NG) são definidos por uma função que designa um número naturala cada símbolo ou fórmula de alguma linguagem formal e a potência destes númerosprimos seguindo a posicionalidade na palavra ou texto. A estes números naturais dá-se onome de Números dedel.Portanto, tendo um conjunto contável S, pode-se definir a função de geração deNúmeros dedel (função de numeração dedel) por:f : S → NComo para S pode-se ter qualquer conjunto de elementos contáveis, toda e qualquerlinguagem formal pode ser convertida para uma representação no domínio dosnúmeros naturais.Para exemplificar, deseja-se criar um Número dedel para a palavra abba.Definindo-se o conjunto S por S = { a, b } pode-se ter a seguinte função de mapeamento


aos números naturais:f(a) = 1 (2)f(b) = 2 (3)Agora, como método de concatenação de símbolos, Gödel utilizou a estratégiade usar os símbolos (já convertidos para números naturais) como expoentes de umaseqüência de números primos, onde cada símbolo ocupa o expoente de um único númeroprimo. Portanto, para a palavra abba se tem a representação numérica dada por:NG abba = 2 1 × 3 2 × 5 2 × 7 1 = 3150Define-se assim uma relação entre o alfabeto de S com os números naturais, ondea palavra abba constitui o NG 3150, de forma unívoca.Os NG são portanto únicos e representam numericamente uma palavra de um sistemaformal qualquer. Haja visto que esta representação se faz por produto de númerosprimos, que por si só são de difícil busca por métodos computacionais, têm tal dificuldadeaumentada pelo fato desta representação ter grande complexidade espacial, fazendo crescero tamanho do NG de maneira exponencial, devido ao produto dos números primosdesta sequência.4. TFA e NG Aplicados à Criptografia4.1. CriptografiaSempre foi desejo do homem manter em segurança certas informações. A criptografia[Schneier 1995] é uma das mais importantes disciplinas por trás desta segurança. Esta,através da matemática e da ciência da computação, pode criar métodos muito eficientesde codificação e decodificação, com alto grau de confiabilidade.Um destes métodos baseia-se no aproveitamento de certas características encontradasem teoremas matemáticos. Tal estratégia é usada como base, por exemplo, paraum dos sistemas criptográficos mais populares da atualidade: a criptografia por chavespúblicas [Choudhury and Choudhury 2002].Nesta técnica, são usados números primos e fórmulas matemáticas para a geraçãode uma chave pública e privada, únicas para cada indivíduo. Ao se comunicar, os indivíduostrocam suas chaves públicas. A partir daí, uma mensagem codificada pelo donoda chave pública só poderá ser aberta com a chave privada deste. Assim, se um indivíduodeseja enviar uma mensagem ao destinatário, deverá usar a chave pública do destinatário


para codificar a mensagem, que só poderá ser aberta pelo destinatário e ninguém mais,nem mesmo o próprio emissor.Um exemplo de algorítmo gerador de chaves públicas e privadas é o popularRSA [Rivest et al. 1978], criado em 1978 por Ronald Rivest, Adi Shamir e Len Adleman,e utilizado na codificação em protocolos seguros como SSL 3 [Rescorla 2000] e nacriação de certificados de segurança para serviços de risco como as redes virtuais privadas,VPN 4 [Holden 2003].4.2. FormulaçãoAs características dos Números dedel e do Teorema Fundamental da Aritmética possibilitaa criação de um algorítmo de criptografia baseado em chaves. Dos NG, tal algorítmoherda a função numeradora, que unida com a propriedade da univocacidade garantida peloTFA, proporciona a geração de números naturais únicos para cada símbolo ou combinaçãodestes. Além disso, garante-se também a operação inversa, onde tais números gerados podemser convertidos novamente aos seus símbolos originais, haja visto que a fatoração édada pela sequência 2 i × 3 j × 5 k × 7 l × ....Assim a proposta é fazer uma codificação usando os NG e uma decodificaçãoatravés da fatoração destes. Portanto, define-se o algorítmo que implementa estasoperações:Codificação1. 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 , y i ) da relação definida nachave C;3. Encontra-se o NG pela multiplicação da seqüência de números primos dado porNG = 2 y 1× 3 y 2× 5 y 3× ... × p ynn , onde p é o consecutivo número primo nválido e n o tamanho da palavra w.Decodificação1. Tendo-se como entrada 〈 g, C 〉 sendo g ∈ N (um número dedel) e C a chavecriptográfica usada na codificação;2. Fatora-se g (aqui aplicando o método recursivo):(a) Se g é um primo, retorna-o. Senão, g ′ = g p isendo p i um número primo iconsecutivo;(b) Se a divisão não gerar resto, adiciona p i à lista L g e fatora g ′ . Casocontrário, g ′ = gp i+1e assim sucessivamente, até obter uma divisão semresto.3 Secure Sockets Layer4 Virtual Private Network


3. A lista L g contém g fatorado. Conta-se, para cada elemento j de L g , a quantidadede elementos iguais a j. O valor desta contagem valora k j ;4. Para cada k j encontrado, toma-se seu par ( j, k j ) da relação definida na chave C;5. Encontra-se a palavra w, formada pela concatenação dos k j calculados.4.3. AplicaçãoA partir dos algorítmos de codificação e decodificação por TFA, pôde-se desenvolverum software que implementa tal sistema criptográfico. O aplicativo foi desenvolvidobuscando-se certa eficiência, mesmo que somente para a demonstração do método. Paratal, utilizou-se a linguagem de programação C [Kernighan and Ritchie 1978]. Ainda, paraas operações de fatoração e multiplicação de números naturais, utilizou-se a bibliotecaPARI, componente do sistema de computação algébrica PARI/GP 5 .Optou-se pelo uso desta biblioteca devida à necessidade da computação de grandesvalores numéricos.Para a execução do software necessita-se, para a codificação, de duas entradas: oarquivo texto contendo a chave (chave.txt, neste exemplo) e uma palavra que será codificada(original.txt). Para a decodificação, ainda é necessária a chave e o número naturalque será fatorado (criptografado.txt).O arquivo texto que abriga a chave possui o formato 〈símbolo código〉, ondesímbolo é qualquer caractere ASCII e código um número natural maior ou igual a zero.Como exemplo:a 1b 2As codificações são realizadas pelo parâmetro -c e as decodificações por -d. Umexemplo de execução seria:./goedel -c chave.txt < original.txt > criptografado.txtAinda, o parâmetro -s leva à execução do show mode, que apresenta todos ospassos realizados na codificação e decodificação de uma palavra dada. Por exemplo:5 PARI/GP: http://pari.math.u-bordeaux.fr


./goedel -s chave.txt < original.txt*** CODIFICACAOentrada = aabafatoracao = 2ˆ1 3ˆ1 5ˆ2 7ˆ1codificado = 1050*** DECODIFICACAOsaida = aabaA aplicação está disponível no repositório (http://mov.void.cc/archives/goedel-0.2.tar.bz2) sobre a licença pública GPL 6 . Maiores informações sobre sua instalação euso encontram-se no arquivo README do pacote distribuído.4.4. AnáliseA criptografia moderna considera eficiente os algorítmos de codificação/decodificaçãocujo tempo computacional requerido para sua execução é impraticável por computadorespessoais e até mesmo por super-computadores [Mao 2003].Pensando desta forma, o método utilizado fornece uma demonstração do poderdado pelos números primos no desenvolvimento de algorítmos de criptografia.O software produzido não suporta a codificação de uma palavra de entrada muitogrande, haja visto que para cada elemento desta palavra, é necessário um número primoque o “represente”, tendo-se portanto alta complexidade espacial. Além disso, para umaquantidade grande de símbolos, os expoentes de tais números primos serão compostospor valores de vários dígitos, o que aumentará ainda mais o tempo de processamento, altacomplexidade temporal.Se por um lado isto lembra errôneamente ineficiência, por outro leva àcomprovação de que a quebra de uma chave criptográfica gerada por estratégias semelhantesà empregada, é praticamente impossível, somente conseguida pelo uso de novastécnicas de processamento [Ord 2002], e ainda não comprovadas.6 GNU General Public License:http://www.fsf.org/licensing/licenses/gpl.txt


5. ConclusõesO Teorema Fundamental da Aritmética revelou fatos interessantes. Aplicá-lo como axiomapara os Números dedel, fez propor um método criptográfico, que apesar de poucoeficiente, demonstra a base na qual algorítmos de criptografia massivamente usados atualmentesão desenvolvidos.Ainda, descobriu-se que a propriedade da incompletude dos sistemas formais,descoberta e provada por Kurt Gödel dos Números dedel, não é somente uma característicade ineficiência de algorítmos. Nota-se que se vista de um novo ângulo, oda criptografia moderna, revela-se como um identificador não da ineficiência, mas daeficiência de segurança de algorítmos criptográficos. Quanto mais os computadores sãoincapazes de quebrar as chaves criadas por estes algorítmos, mais tempo estes perdurarãocomo padrões de codificação.O software desenvolvido permitiu analisar de maneira prática a teoria aqui desenvolvida.Comprovou-se a dificuldade da decodificação de uma mensagem criptografada,pela fatoração em termos de números primos de um número natural de milhares de casasdecimais.Enfim, de axioma para aplicação em novos teoremas, à base para o desenvolvimentode soluções práticas, o Teorema Fundamental da Aritmética prova que as teoriaspodem ser usadas para uma gama de aplicações, e não somente destinadas a hipóteses nãoimplementadas.ReferênciasAndrews, G. E. (1995). Number Theory. Dover Publications, 1st edition.Choudhury, S. and Choudhury, S. (2002). Public Key Infrastructure and Implementationand Design. Wiley, 1st edition.Gödel, K. (1931). Uber formal unentscheidbare satze der principia mathematica undverwandter systeme, i. Mathematik und Physik, 38.Hintikka, J. (1999). On Gödel. Wadsworth Publishing, 1st edition.Hofstadter, D. R. (1989). Gödel, 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.

More magazines by this user
Similar magazines